We're good. I just wanted to start the discussion of how we can protect things more inclusively to foster more cloud-like adoption. I might be a little ahead is all.
~~~~~~~~~~~~~~~~~~ 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! On Aug 18, 2012 8:38 AM, "Michael Picher" <[email protected]> wrote: > 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/ > -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
