[prev in list] [next in list] [prev in thread] [next in thread] 

List:       snort-sigs
Subject:    RE: [Snort-sigs] SMTP RCPT TO overflow
From:       Ian Macdonald <secsnortsigs () dirk ! demon ! co ! uk>
Date:       2002-07-20 19:39:10
[Download RAW message or body]


I don't know the orgins of this rule. Anyone else?

Ian

On Fri, 19 Jul 2002, Paulo Filipe Mira wrote:

> Would it be wise to discard the 'SMTP HELO overflow attempt' rule
> as well, since i'm not running a Domino server either?
> I'm getting a whole lot of false positives on this rule, caused,
> methinks, not by the HELO in the initial SMTP handshake, but by
> a HELO in the SMTP headers, put in there by another SMTP server
> further down the line (qmail?).
>
> Here's the rule:
>
> alert tcp $EXTERNAL_NET any -> $SMTP 25 (msg:"SMTP HELO overflow attempt";
> flags:A+; dsize:>500; content:"HELO "; offset:0; depth:5;
> reference:cve,CVE-2000-0042; classtype:attempted-admin; sid:1549;  rev:5;)
>
> Here's a sample log, adresses changed to protect the inocent:
>
> HELO host.making.final.delivery
> MAIL FROM:<user@somehost.com>
> RCPT TO:<my.user@my.host.com>
> DATA
> Received: (qmail 30987 invoked from network); 18 Jul 2002 12:58:41 -0000
> Received: from unknown (HELO somehost.com.) (10.0.0.1)	<------------
>   by host.making.final.delivery with SMTP; 18 Jul 2002 12:58:41 -0000
>
> <---snip--->
>
> Am i correct in assuming that it is the second HELO that's triggering the
> alert?
> Should i just hose this rule?
>
>
>
>
>
>
> Paulo Filipe Mira
> SA
> Soquimica
> paulo.mira@soquimica.pt
> Tel: +351 21 716 51 60
> Fax: +351 21 716 51 69
>
>
> > -----Original Message-----
> > From: snort-sigs-admin@lists.sourceforge.net
> > [mailto:snort-sigs-admin@lists.sourceforge.net]On Behalf Of Ian
> > Macdonald
> > Sent: sexta-feira, 19 de Julho de 2002 2:13
> > To: Matt Kettler
> > Cc: simsjs; Snort-Sigs
> > Subject: Re: [Snort-sigs] SMTP RCPT TO overflow
> >
> >
> >
> > As said on snort users recently this rule is for people with
> > lotus notes.
> >
> > Ian
> >
> > On Thu, 18 Jul 2002, Matt Kettler wrote:
> >
> > > This rule is prone to false alerts if your server supports
> > SMTP command
> > > pipelining, which sendmail supports.
> > >
> > > My guess is most of the email setting this off is mailing
> > list traffic
> > > coming to your sendmail server.
> > >
> > > I'd remove the rule entirely, and am of the opinion it has
> > no place in the
> > > snort ruleset at all. Until snort can do "linelength" type
> > rules instead of
> > > segment length, this rule is almost completely pointless.
> > >
> > >
> > > At 11:38 AM 7/18/2002 -0700, simsjs wrote:
> > > >I am new to snort and have a question that may be basic.
> > My snort logs are
> > > >reporting the following SMTP RCPT TO overflow entry.
> > > >
> > > >[**] [1:654:5] SMTP RCPT TO overflow [**]
> > > >[Classification: Attempted Administrator Privilege Gain]
> > [Priority: 1]
> > > >07/12-16:19:04.646682 192.168.1.1:61665 -> 192.168.1.2:25
> > > >TCP TTL:240 TOS:0x10 ID:0 IpLen:20 DgmLen:4668
> > > >***AP*** Seq: 0x689D41CC  Ack: 0x15826C2E  Win: 0x8000  TcpLen: 20
> > > >[Xref =>
> > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0260]
> > > >[Xref => http://www.securityfocus.com/bid/2283]
> > > >
> > > >After looking at what this means it appears that it is
> > only for LOTUS
> > > >Domino mail servers. So why would a sendmail operated
> > network be receiving
> > > >this alert? Is there something in the rule I should modify
> > to stop all the
> > > >false positives or just remove the rule entirely? Thanks
> > for any help you
> > > >can give.
> > > >
> > > >I have sanitized the log entry by giving it nonroutable IP
> > addresses but
> > > >192.168.1.1 is our nat server (all internal hosts go
> > through this machine
> > > >and 192.168.1.2 is the sendmail mail server running sendmail 8.11)
> > > >
> > > >Jeff
> > > >
> > > >
> > > >
> > > >
> > > >-------------------------------------------------------
> > > >This sf.net email is sponsored by:ThinkGeek
> > > >Welcome to geek heaven.
> > > >http://thinkgeek.com/sf
> > > >_______________________________________________
> > > >Snort-sigs mailing list
> > > >Snort-sigs@lists.sourceforge.net
> > > >https://lists.sourceforge.net/lists/listinfo/snort-sigs
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Snort-sigs mailing list
> > > Snort-sigs@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Snort-sigs mailing list
> > Snort-sigs@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
[prev in list] [next in list] [prev in thread] [next in thread]