I keep hearing what I have been saying for a long time, put the security in the firewall. My only point is this: When you start to move the infrastructure into the cloud, it becomes more important to build the security behaviors into the service and not on the underlying platform. So I am searching for ways to do this "internal" to sipx.
When deploying in an environment like Amazon EC2, you cannot rate limit. Using their firewall blocking or allowing only certain regions takes thousands of manual entries. It's just not as easy as uploading a script which you can do on your service (sipx). Why? Because cloud security is not where it needs to be yet (IMO). I believe rate limiting is a good fallback position to have built into the proxy since it will limit both call and registration attempts. I never thought the Blacklist would do much other than to thwart something that already got started, and that's OK. I think the least performance hit to sipx would be to use iptables as the place to use more extensive blacklists when the firewall capabilities are too lacking. On Sat, Aug 18, 2012 at 7:22 AM, Michael Picher <mpic...@ezuce.com> wrote: > FWIW the solution that is implemented now was implemented to not only help > with DoS from the 'outside world' but also to combat poorly behaving > devices and prevent issues with such devices possibly causing issues with > the system. > > The firewall is probably a better location for whitelist / blacklist. > Rate-limiting also for that matter. > > The penalty-box approach may also still have merit for other reasons. > > Thanks, > Mike > > > On Fri, Aug 17, 2012 at 10:15 AM, Douglas Hubler <dhub...@ezuce.com>wrote: > >> I don't have a lot of time to respond atm, but I'll leave you all with >> this, we can have multiple implementations, based on needs, ease of use, >> preferences, requirements. Each implementation may not be compatible with >> each other and folks will need to decide which works for them. What I'm >> interested is in creating project for folks with something they're >> comfortable maintaining on their own once I get them started. You all >> would have commit access to your own repo and can allow anyone else access >> and control your release schedule. >> >> A project can be as simple as simple shell script with the proper hook >> into the system. >> >> Chasing a full featured firewall feature that competes with the best >> firewall product is obviously not a reality, having different optimized >> solutions is next best thing, some might argue better. >> >> On Fri, Aug 17, 2012 at 9:30 AM, Tony Graziano < >> tgrazi...@myitdepartment.net> wrote: >> >>> I am just trying to offer a way for admins to be selective in what they >>> block, and to get it to auto update and ultimately into sipxconfig. This >>> way they can pick and choose what to block. If they have remote workers and >>> they decide to deploy from a cloud infrastructure (i.e. EC2, etc.), this >>> will be a quick and easy way to protect the server from a lot of stuff. >>> Since 4.6 has a DOS mechanism built into it (proxy) to rate limit things, >>> this is simply ONE method to prevent that from being triggered by a lot of >>> scripts by reducing the footprint opportunity for a lot of nonsense the >>> admin does not want to consider dealing with. Ideally the capabilities to >>> only alter the rules if the zone has changed will make it much more >>> efficient too, and I see no performance hit with this in the limited tests >>> I have run. >>> >>> This also assumes the admin needs to allow both remote workers and/or >>> native sip connections from other systems (sipx or other sip servers) but >>> has the ability to exclude traffic originating from a country they do not >>> want the traffic originating from. It also updates its own country zone >>> file automatically. This only adds rules, it does not supplant the ones >>> sipx institutes in 4.6. >>> >>> Unless someone is not already running iptables in 4.4, I would not >>> recommend using it. >>> >>> OK, here is the script I was working from. Right now the ISO codes block >>> all countries except US and CA and do block BOGONS, which all can be >>> altered by edition the ISO line in the script. >>> >>> put in /usr/bin >>> >>> chown root:root /usr/bin/blockcountry.sh >>> chown 0755 /usr/bin/blockcountry.sh >>> >>> Then execute (requires wget be installed, which needs to be added since >>> ISO does not include it) >>> >>> /usr/bin/blockcountry.sh >>> >>> After it completes looking at iptables status will show these IP blocks >>> are now denied. >>> >>> >>> On Fri, Aug 17, 2012 at 9:18 AM, Gerald Drouillard < >>> gerryl...@drouillard.ca> wrote: >>> >>>> On 8/17/2012 8:54 AM, Tony Graziano wrote: >>>> > The question I had was is this better implemented in iptables (my >>>> > preference is there) or in the proxy? >>>> > >>>> > In the normal realm of dealing with people who desire to block most or >>>> > all countries from accessing their system to limit exposure. I >>>> > compiled a CIDR list (no space, separated by commas) of all countries >>>> > excpet USA and saw that it is around 130,000 characters in length (83k >>>> > CIDR entries). So the question begs "what would be the proxy impact of >>>> > this"? >>>> > >>>> > Since it might be easier to implement as a blacklist in the proxy I >>>> > found it impractical to use because of the 1000 character limit >>>> > imposed. So if we send this to the proxy as a blacklist, I wonder >>>> > about performance. >>>> > >>>> > I have an iptables script that can be run to block this via iptables, >>>> > but it takes at least 10 minutes to turn it on and make it add each >>>> > country zone by script.I am thinking a plugin might be more elegant >>>> > and am looking at cfengine as well. I just need to see how I can marry >>>> > the script to run via a cron job to auto update the zone files and use >>>> > the iptables argument within cfengine. >>>> > >>>> > Ideally we could extend this to sipxconfig and have it manage a script >>>> > and allow the admin the check the countries to be blocked. It really >>>> > makes it simpler to deploy in a virtual center somewhere this way, >>>> > which is where everyone is headed. >>>> > >>>> 10 mins seems long. This is what I do: >>>> >>>> /sbin/iptables -N whitelist >>>> /sbin/iptables -I INPUT -j whitelist >>>> /sbin/iptables -A whitelist -s 192.168.0.0/16 -j ACCEPT >>>> #voipinnovations >>>> /sbin/iptables -A whitelist -s 64.136.174.30 -j ACCEPT >>>> #newyork.voip.ms >>>> /sbin/iptables -A whitelist -s 74.63.41.218 -j ACCEPT >>>> #chicago.voip.ms >>>> /sbin/iptables -A whitelist -s 64.120.22.242 -j ACCEPT >>>> >>>> /sbin/iptables -A INPUT -p udp --dport 5060 -i eth0 -m state --state NEW >>>> -m recent --set >>>> /sbin/iptables -A INPUT -p udp --dport 5060 -i eth0 -m state --state NEW >>>> -m recent --rcheck --seconds 300 --hitcount 20 -j REJECT >>>> /sbin/iptables -A INPUT -p udp --dport 5060 -i eth0 -m state --state NEW >>>> -m recent --rcheck --seconds 180 --hitcount 10 -j REJECT >>>> /sbin/iptables -A INPUT -p udp --dport 5060 -i eth0 -m state --state NEW >>>> -m recent --rcheck --seconds 60 --hitcount 6 -j REJECT >>>> #/sbin/iptables -A INPUT -p udp --dport 5060 -m limit --limit 5/s >>>> --limit-burst 5 -i eth0 -j REJECT >>>> #/sbin/iptables -A INPUT -p udp --dport 5080 -m limit --limit 5/s >>>> --limit-burst 5 -i eth0 -j REJECT >>>> >>>> >>>> BASE_FILE=/etc/voipabuse.txt >>>> for line in `cat $BASE_FILE`; do >>>> /sbin/iptables -A INPUT -s "$line" -j DROP >>>> done >>>> >>>> >>>> -- >>>> Regards >>>> -------------------------------------- >>>> Gerald Drouillard >>>> Technology Architect >>>> Drouillard & Associates, Inc. >>>> http://www.Drouillard.biz >>>> >>>> _______________________________________________ >>>> sipx-dev mailing list >>>> sipx-dev@list.sipfoundry.org >>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >>>> >>> >>> >>> >>> -- >>> ~~~~~~~~~~~~~~~~~~ >>> Tony Graziano, Manager >>> Telephone: 434.984.8430 >>> sip: tgrazi...@voice.myitdepartment.net >>> Fax: 434.465.6833 >>> ~~~~~~~~~~~~~~~~~~ >>> Linked-In Profile: >>> http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>> Ask about our Internet Fax services! >>> ~~~~~~~~~~~~~~~~~~ >>> >>> Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab >>> 2013! >>> <http://sipxcolab2013.eventbrite.com/?discount=tony2013> >>> >>> >>> LAN/Telephony/Security and Control Systems Helpdesk: >>> Telephone: 434.984.8426 >>> sip: helpdesk@voice.myitdepartment.**net<helpd...@voice.myitdepartment.net> >>> >>> Helpdesk Customers: >>> http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net> >>> Blog: http://blog.myitdepartment.net >>> >>> _______________________________________________ >>> sipx-dev mailing list >>> sipx-dev@list.sipfoundry.org >>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >>> >> >> >> _______________________________________________ >> sipx-dev mailing list >> sipx-dev@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >> > > > > -- > Michael Picher, Director of Technical Services > eZuce, Inc. > > 300 Brickstone Square**** > > Suite 201**** > > Andover, MA. 01810 > O.978-296-1005 X2015 > M.207-956-0262 > @mpicher <http://twitter.com/mpicher> > linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro> > www.ezuce.com > > > ------------------------------------------------------------------------------------------------------------ > There are 10 kinds of people in the world, those who understand binary and > those who don't. > > > _______________________________________________ > sipx-dev mailing list > sipx-dev@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > -- ~~~~~~~~~~~~~~~~~~ Tony Graziano, Manager Telephone: 434.984.8430 sip: tgrazi...@voice.myitdepartment.net Fax: 434.465.6833 ~~~~~~~~~~~~~~~~~~ Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet Fax services! ~~~~~~~~~~~~~~~~~~ Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013! <http://sipxcolab2013.eventbrite.com/?discount=tony2013> -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-dev mailing list sipx-dev@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-dev/
