[Emerging-Sigs] Blocks based on IP alone

Martin Holste mcholste at gmail.com
Sun Oct 17 20:07:14 EDT 2010


> I prefer the inline drop method as opposed to the "race condition" method of flexresp.

For security, certainly, but that means it becomes a point of failure,
which is not palatable to our organization, so it's RST or nothing.
And I really am impressed with Websense's performance for RST.  We see
it hit a lot of malware sites and it always succeeds in killing the
connection.  On the other hand, with the RST method, POST's that
contain sensitive data are gone for good, so it's far from a data loss
prevention solution.  Actually, I'd be interested in knowing if the
RST screws up the malware POST enough for it not to get logged by
nginx or whatever the malware web server is running on top of.  I
doubt that most of the malware folks are running daemonlogger on their
end, and even if they are, sifting through it and matching packets up
to responses would be a full-time job.

>
> 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
>>> 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
>>> 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
>


More information about the Emerging-sigs mailing list