[Snort-sigs] Bleeding addition

Matthew Jonkman matt at ...2436...
Mon Jun 28 13:38:00 EDT 2004


By slip through I mean the spambot that slips in, not the spam that 
slips out.

The cd burned at home on an infected system that's brought in to work to 
a pc with outdated virus dat's, etc. We've found a couple people that 
actually thought they could send spam from their corporate networks. 
Their dsl line at home just wasn't cutting it anymore so they took a 
shot at doing it from work. An incident like that actually originally 
drove us to writing that rule.

And whatever new way in the spammers dream up to circumvent things.

Matt

Adrian Marsden wrote:

> It makes sense up to the point you say that you are looking to detect
> what slips through. If the firewall is configured to deny out SMTP then
> nothing should be slipping through. My firewalls block all outbound
> except from my mail servers and drops an alert to my desktop if any
> machine tries. I can see the point of a Snort rule if your firewall
> can't alert the admin, other than that the Snort rule would be somewhat
> redundant other than for logging purposes since the firewall will have
> already logged it for you when it alerted you. Or am I missing something
> here?
> 
> 
> 
> -----Original Message-----
> From: Matthew Jonkman [mailto:matt at ...2436...] 
> Sent: Monday, June 28, 2004 2:47 PM
> To: Adrian Marsden
> Cc: snort-sigs mailinglist
> Subject: Re: [Snort-sigs] Bleeding addition
> 
> I agree that prevention is the best case, and we recommend our clients 
> do so, and help them do it.
> 
> But security is about layers. I'm looking to detect what slips through. 
> In most nets it'd be stopped at the firewall, but we'd still see the 
> infected host try to initiate a connection.
> 
> That make sense?
> 
> Matt
> 
> Adrian Marsden wrote:
> 
> 
>>If you are looking for outbound SMTP then the probability is high that
>>you only want your mail servers sending out email.
>>
>>The easy way to do that is to prevent all outbound access on port 25
> 
> at
> 
>>the firewall except for the mail servers themselves. In that way the
>>virus does not get propagated and you get warned by the firewall logs
> 
> of
> 
>>which machines have a virus with it's own SMTP engine, (which is
> 
> almost
> 
>>every one).
>>
>>Much easier and more efficient than writing rules to catch
> 
> unauthorized
> 
>>traffic then have to go chasing it down after the fact. If it's
>>unauthorized and you can prevent it, prevent it first if at all
>>possible.
>>
>>-----Original Message-----
>>From: Brian [mailto:bmc at ...95...] 
>>Sent: Monday, June 28, 2004 1:21 PM
>>To: Matthew Jonkman
>>Cc: snort-sigs mailinglist
>>Subject: Re: [Snort-sigs] Bleeding addition
>>
>>On Mon, Jun 28, 2004 at 11:38:54AM -0500, Matthew Jonkman wrote:
>>
>>
>>>What they'll do is help you find infected hosts. It's been working
>>
>>very 
>>
>>
>>>well for us for some time. You can generally narrow down the hosts
>>
>>that 
>>
>>
>>>should be sending mail to 5 or 10, these sigs will tell you where they
>>
>>
>>>are quickly, then add them to the SMTP_SERVERS var. Lots of good info 
>>>will come from these. We've also caught a few vendors sending 
>>>'anonymous' system information without our awareness. :)
>>>
>>>pass tcp $SMTP_SERVERS any -> any 25 ( sid:2000324; rev: 1; 
>>>msg:"BLEEDING-EDGE Ignore Authorized SMTP Traffic";)
>>>pass tcp any any -> $SMTP_SERVERS 25 ( sid:2000325; rev: 1; 
>>>msg:"BLEEDING-EDGE Ignore Authorized SMTP Traffic";)
>>>alert tcp !$SMTP_SERVERS any -> any 25 ( sid:2000326; rev: 1; 
>>>msg:"BLEEDING-EDGE Possible UnAuthorized SMTP Traffic"; content:"RCPT 
>>>TO"; nocase;)
>>>
>>>Again, these are in stable-side for now, they'll go into the 
>>>bleeding.rules in a few days.
>>
>>
>>In the process of doing this detection, you have invalidated ALL of
>>the SMTP rules currently in the system.  Hopefully nobody running
>>these rules care about attacks on their real mail servers.
>>
>>Brian
>>
>>
>>-------------------------------------------------------
>>This SF.Net email sponsored by Black Hat Briefings & Training.
>>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
>>digital self defense, top technical experts, no vendor pitches, 
>>unmatched networking opportunities. Visit www.blackhat.com
>>_______________________________________________
>>Snort-sigs mailing list
>>Snort-sigs at lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/snort-sigs
>>
>>
>>-------------------------------------------------------
>>This SF.Net email sponsored by Black Hat Briefings & Training.
>>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
>>digital self defense, top technical experts, no vendor pitches, 
>>unmatched networking opportunities. Visit www.blackhat.com
>>_______________________________________________
>>Snort-sigs mailing list
>>Snort-sigs at lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/snort-sigs
> 
> 




More information about the Snort-sigs mailing list