[VoiceOps] Growing attack pains

anorexicpoodle anorexicpoodle at gmail.com
Mon Jan 10 19:40:05 EST 2011


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20110110/388c70e3/attachment.html>


More information about the VoiceOps mailing list