[Snort-sigs] Bleeding addition

Adrian Marsden amarsden at ...2045...
Mon Jun 28 14:25:01 EDT 2004


I'd be inclined to say that if you have undocumented SMTP servers within your network then you have a bigger problem. By documented I mean that they would be delineated in the SMTP_SERVERS variable for the rule we are discussing. If it isn't in that variable then it probably shouldn't be on the production network. Even then the domains pointed to in the usual user's address book shouldn't be able to be found without the appropriate MX records for the undocumented internal mail server. If it is and the server is rogue/undocumented then you are in big trouble.

	-----Original Message----- 
	From: James Ashton [mailto:James at ...2424...] 
	Sent: Mon 6/28/2004 4:43 PM 
	To: Adrian Marsden; Matthew Jonkman 
	Cc: snort-sigs mailinglist 
	Subject: RE: [Snort-sigs] Bleeding addition
	
	

	I would say that, depending on your network layout, you could also be
	worried about internal machines sending mail to other internal machines.
	This can be as bad as traffic coming and going to the net at large.
	
	There are SO many network layouts that this rule makes sense in many and
	not in some of the more standard ones...  But when was the last time you
	had trouble with perimeter security in a standard network layout.......
	
	
	James Ashton
	http://bleedingsnort.com
	http://www.gitflorida.com
	
	-----Original Message-----
	From: snort-sigs-admin at lists.sourceforge.net
	[mailto:snort-sigs-admin at lists.sourceforge.net] On Behalf Of Adrian
	Marsden
	Sent: Monday, June 28, 2004 3:29 PM
	To: Matthew Jonkman
	Cc: snort-sigs mailinglist
	Subject: RE: [Snort-sigs] Bleeding addition
	
	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
	
	--
	--------------------------------------------
	Matthew Jonkman, CISSP
	Senior Security Engineer
	Infotex
	765-429-0398 Direct Anytime
	765-448-6847 Office
	866-679-5177 24x7 NOC
	my.infotex.com
	www.offsitefilter.com
	--------------------------------------------
	
	
	NOTICE: The information contained in this email is confidential
	and intended solely for the intended recipient. Any use,
	distribution, transmittal or retransmittal of information
	contained in this email by persons who are not intended
	recipients may be a violation of law and is strictly prohibited.
	If you are not the intended recipient, please contact the sender
	and delete all copies.
	
	
	-------------------------------------------------------
	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
	
	
	-------------------------------------------------------
	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