[Emerging-Sigs] Blocks based on IP alone

Jeff Kell jeff-kell at utc.edu
Sun Oct 17 17:52:18 EDT 2010


 For certain cases (especially HTTP traffic to bad IPs or DNS names), we
have done blocking via our [traffic management blackbox].  The filter
rules can be setup to reject traffic with verbose logging... if the
filter is HTTP based, you get [most of] the client headers (URI,
User-agent, Referrer, Host, etc).

We also have "another IPS thing" that can capture the packet in context
where needed.

The "null-route/blackhole" routing is also in use, but typically for
"decidedly bad actors" (e.g., Spamhaus DROP list) where there is no
question (in proven practice) about the action.  Logging data is most
useful to determine validity of the signature or the actors involved,
and/or for after-the-fact forensic value (Why are you blocking
badsite.ru?  Why can't I reach badsite.ru? etc).

Jeff

On 10/17/2010 5:32 PM, Packet Hack wrote:
> [ Sorry for the dup, Martin - not used to gmail's default respond to
> sender only...grr]
>
> We have exactly the same problem. We currently use null routes to
> blackhole
> bad IPs, but then are in a bind when we see connection attempts
> without being able
> to see the payload. 
>
> Our plan is to try using snort active response (flexresp3 in 2.9.0).
> That way we can 
> hopefully see enough of the payload to determine if it was an attack
> or just a stray 
> connection before the connection is reset. We're going to try it both
> with IP lists and 
> certain sigs as well (Phoenix exploits - oy!). 
>
> I actually had everything set to go in our lab on Thursday but had to
> leave early
> (had Friday off), so hopefully I can get some decent testing done
> starting tomorrow. 
>
> I'll be glad to report back on what I find - anyone else gone this route?
>
> -- pckthck
>
> On Sun, Oct 17, 2010 at 2:06 PM, Martin Holste <mcholste at gmail.com
> <mailto:mcholste at gmail.com>> wrote:
>
>     There are a lot of great minds on this list, so I'd like your input on
>     an on-going dilemma:  If you put IP-level blocks using firewall rules
>     and router ACL's for malware C&C, you can hinder the malware and
>     possibly prevent check-ins, but because the TCP handshake is never
>     completed, you only get firewall deny log messages to identify
>     infected hosts.  Without a full reporting URL, it's difficult to
>     identify whether it was a malware check-in that was blocked or
>     something less serious like adware also being served from the blocked
>     IP.
>
>     We currently auto-create incident tickets for various malware check-in
>     sigs, which really helps streamline our SIRT process.  It isn't
>     possible to do this based on ACL deny messages because there's less
>     fidelity in an IP deny message than an URL-based check-in message.  On
>     the other hand, it would be nice to cut off as much communication with
>     the malware servers as possible.  Web proxy filters are the obvious
>     solution to this problem, but we can't implement that across the
>     board, so consider that out of scope for the purposes of the
>     discussion.  We do implement IP-level blocks for sites we know to be
>     distributing malware binaries, just not the check-in servers.
>
>     I'm interested in what, if anything, other organizations are doing to
>     address this dilemma.
>
>     Thanks,
>
>     Martin
>
>     _______________________________________________
>     Emerging-sigs mailing list
>     Emerging-sigs at emergingthreats.net
>     <mailto:Emerging-sigs at emergingthreats.net>
>     http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
>     Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs
>     and Lanyards
>     http://www.emergingthreats.net/index.php/support-et-and-buy-et-schwag.html
>
>
>
>
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
> Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs and Lanyards
> http://www.emergingthreats.net/index.php/support-et-and-buy-et-schwag.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.emergingthreats.net/pipermail/emerging-sigs/attachments/20101017/d7c7fcc2/attachment-0001.html


More information about the Emerging-sigs mailing list