don't get me wrong, i wasn't suggesting 'a firewall', i meant 'the firewall'... i.e., iptables.
thanks, mike On Sat, Aug 18, 2012 at 8:00 AM, Tony Graziano <[email protected] > wrote: > 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 <[email protected]> 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 <[email protected]>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 < >>> [email protected]> 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 < >>>> [email protected]> 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 >>>>> [email protected] >>>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >>>>> >>>> >>>> >>>> >>>> -- >>>> ~~~~~~~~~~~~~~~~~~ >>>> Tony Graziano, Manager >>>> Telephone: 434.984.8430 >>>> sip: [email protected] >>>> 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: [email protected].**net<[email protected]> >>>> >>>> Helpdesk Customers: >>>> http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net> >>>> Blog: http://blog.myitdepartment.net >>>> >>>> _______________________________________________ >>>> sipx-dev mailing list >>>> [email protected] >>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >>>> >>> >>> >>> _______________________________________________ >>> sipx-dev mailing list >>> [email protected] >>> 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 >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >> > > > > -- > ~~~~~~~~~~~~~~~~~~ > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected] > 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: [email protected].**net<[email protected]> > > Helpdesk Customers: > http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net> > Blog: http://blog.myitdepartment.net > > _______________________________________________ > sipx-dev mailing list > [email protected] > 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 [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
