Then one would have to deploy multiple I stances I. A cloud environment. I could do this with karoo or other packages. This approach, however, pretty much doubles the monthly costs in a cloud environment. This is really a "looking ahead" approach to how to both manage security and keep the management tasks to a sane level I stead of doubling them. Thanks though, I get where you are coming from. On Aug 18, 2012 9:17 AM, "Dave May" <dave....@patlive.com> wrote:
> > You could use an external proxy like OpenSIPS to handle all of these > things and more. The firewall approach is great for brute-force, but since > it doesn't understand SIP there is a limit to its usefulness. > > Sent from my HTC smartphone on the Now Network from Sprint! > > ----- Reply message ----- > From: "Tony Graziano" <tgrazi...@myitdepartment.net> > To: "sipXecs developer discussions" <sipx-dev@list.sipfoundry.org> > Subject: [sipx-dev] ACL lists in Proxy (4.6) > Date: Sat, Aug 18, 2012 8:01 am > > > 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/ > -- 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/
