I think Mark is on the right path here, but I figure ill throw in my experience and some ideas. We got bitten by a scanning attack once, and then quickly crafted some HMR and access side policies on our session border controllers to quickly and elegantly deal with these kinds of events. We have implemented policies in our edge border controllers to demote an endpoint to the blocklist if it cannot become authenticated in X re-tries. This allows us to account for the endpoint sending incorrect credentials as well as a registrar overload situation where the registrar doesn't respond to traffic it cannot service. In either case, the endpoint becomes blocked for several minutes, which is not long enough to significantly impact convergence times in a flood, but is long enough to make any kind of brute force attack statistically impossible. To assist this we also use some custom reporting against a database with the syslog output from the border controllers which allows us to get clever with SQL and chart blacklist offenders by IP, region etc for trend tracking, and draw our attention to serial offenders so we can either do traffic analysis against possible new attacks or just block them in a more permanent way. If you aren't running an acme or anything with that kind of horsepower, what I have done in the past is used clever scripts to add/remove entries from the local firewall on *NIX machines. I have not used this for any SIP applications but I cannot think of any reason it will not work exactly the same. This will effectively just kill the bad traffic with much less CPU impact than attempting to stop it at layer 5. In the past I have used this method to dynamically protect distributed applications from brute force attacks from APNIC scanners, botnets etc without needing to micromanage each node. All app servers just sent logs to a central location, that central location broke the logs out and generated a list of offending addresses, and on regular intervals, all servers would purge their drop lists and refresh them from the central servers updated list. This allowed me block attacks that distributed their footprint across dozens of nodes geographically in minutes. If the deny list entries become so enormous they threaten to overflow the CAM in the SBC or managing it in a local firewall takes on more overhead than it prevents, or the network link itself then a more extreme solution using a uRPF style approach might be more appropriate, where centrally collected logs from border elements are analyzed to generate a list of offenders, and those offenders are added to the route table of a router that exchanges BGP routes with your edge. Traffic to those IP's recieved into that router is just then discarded. Again, great care must be taken with this approach to avoid creating an entirely new class of problem (attackers forcing valid networks into your blackhole or worse yet pumping your blackhole route table up to such proportions that your edge routers crash). As always, you know your network best. On Mon, 2011-01-10 at 12:19 -0500, Mark R Lindsey wrote:

How large would this product have to scale? And I'm not sure I completely understand your syntax, "Block on N" or "Block N".

I have a hunch the CAM/Network Processor DoS features in the Acme Packet OS-C SD platforms could come close. Once traffic is matched as bad, the source of the bad traffic (based on an IP address and port number) can be demoted to the black-list. This blocks traffic before it enters the SD CPU.

When a demotion occurs, the SD sends a trap. There's your alert.

By default, when designing a network with OS-C, we expect the SIP registrar or proxy to be smart enough to reject failed attempts. In this case, the registrar/proxy rejects the transactions (returning SIP 4xx messages). If the failing source continues to make failing requests, the SD can automatically blacklist the source.

For example, if the SIP registrar refuses five REGISTERs in a row, then the SD can detect that and automatically demote without having to understand why. This is a standard feature on OS-C and wouldn't require any creative mangling.

However, if you wanted to use the SD's own CPU to determine whether the SIP request is bad, there may be a way. Perhaps you could use a SIP Manipulation Rule to (a) match SIP that you find offensive, then (b) mangle it to make it invalid, unparseable SIP. The invalid SIP could hit the invalid-signal-threshold, causing a blacklist of the source. I'd want to do a proof-of-concept before I was certain this is workable, though. And you can be sure this processing would consume significant SD CPU time.

If any other vendors have a similar feature they'd like us to evaluate, contact me offline.

mark at ecg.co | +1-229-316-0013 | http://ecg.co/lindsey

On Jan 10, 2011, at 11:53 AM, J. Oquendo wrote:

...

I'm in the market for something to place in front of an SBC (modules would be nice, e.g., Asterisk module, Avaya module, etc.) The device will need to do the following:

Block on N ... Block N amount bad attempts indefinitely and alert Block on Prefix ... If PREFIX is anywhere in SIPURI/ANI/CID, block (country specific would be nice)

We are having a hard time keeping up with the attack vectors here. We recently saw a compromise from Egypt where the password was 15 characters mixed numbers, letters and symbols. So obviously longer passwords aren't even an issue anymore.

--

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT

"It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett

227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

Have your router handle the dropping of bad packets. If you configured 'ip verify unicast reverse-path' on your inbound interface you can then auto-drop packets from a hacker by injecting a null route for the offending /32. You would set up a Snort box on a span port to monitor your VoIP traffic. When it sees something it doesn't like it injects a /32 route into BGP via quagga. Your router is configured to route all BGP announcements from quagga to Null0. uRPF will then drop the packet on the inbound interface of your border router. If you have an Acme Packet you could have it watch for 'bad stuff' and throw a trap to your Snort/Quagga box to inject the route. You need to be very careful that the hacker doesn't figure out what you are doing and send you forged SIP packets from fun IPs like a.root-servers.net, blackholing DNS wouldn't be good. Snort: http://www.snort.org/ Quagga: http://www.quagga.net/ Cisco: http://www.cisco.com/en/US/docs/ios/11_1/feature/guide/uni_rpf.html#wp102286... ----- Original Message -----

From: "Stefan Sayer" <stefan.sayer at googlemail.com> To: "J. Oquendo" <sil at infiltrated.net> Cc: VoiceOps at voiceops.org Sent: Monday, January 10, 2011 4:55:28 PM Subject: Re: [VoiceOps] Growing attack pains o J. Oquendo on 01/10/2011 05:53 PM:

...

I'm in the market for something to place in front of an SBC (modules would be nice, e.g., Asterisk module, Avaya module, etc.) The device will need to do the following:

Block on N ... Block N amount bad attempts indefinitely and alert Block on Prefix ... If PREFIX is anywhere in SIPURI/ANI/CID, block (country specific would be nice)

We are having a hard time keeping up with the attack vectors here. We recently saw a compromise from Egypt where the password was 15 characters mixed numbers, letters and symbols. So obviously longer passwords aren't even an issue anymore.

Palladion from IPTEGO can detect attacks and SPIT on a variety of configurable triggers (even scriptable) and also control firewalls and IPS like e.g. radware defensepro.

if you want to build your own, you may find some hints at http://asipto.com/u/i

Stefan _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

-- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com P: 413-746-2760