[Emerging-Sigs] Blocks based on IP alone
joel.esler at me.com
Sun Oct 17 18:08:38 EDT 2010
I think it depends on how web sense is installed.
I prefer the inline drop method as opposed to the "race condition" method of flexresp.
Also check out rate-based rules (under the new rate_filter readme) if you are in inline mode.
Sent from my iPad
On Oct 17, 2010, at 6:00 PM, Martin Holste <mcholste at gmail.com> wrote:
> Very cool--I hope you have more success than we did with flexresp in
> the 2.6 branch, which failed miserably (Snort's RST lost the race in
> the few times it was actually successfully generated). Websense never
> seems to have any problems winning the RST race, so I don't know why
> libNIDS does.
> On Sunday, October 17, 2010, Packet Hack <pckthck at gmail.com> 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 blackholebad 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> 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
>> 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.
>> Emerging-sigs mailing list
>> Emerging-sigs at emergingthreats.net
>> Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs and Lanyards
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net
> Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs and Lanyards
More information about the Emerging-sigs