[Snort-sigs] Problem with pop3.rules and ftp.rules
fknobbe at ...1264...
Tue Feb 11 11:56:05 EST 2003
On Tue, 2003-02-11 at 13:09, Russell Fulton wrote:
> On Wed, 2003-02-12 at 04:28, Kenneth G. Arnold wrote:
> > I updated my rules yesterday and I am getting similar results from pop3
> > and ftp rules. I have had to disable just about all of the rules because
> > they were firing on what certainly appeared to be legitimate traffic.
> There is a bug in the 1.9.0 stream4 preprocessor which sometimes drops
> the last character of the packet. In these cases it drops the '0a'
> causing the rule to fire. If you are logging packets you can check this
> by looking at the dumps.
> Has this bug been fixed in the 1.9.0 CVS? I had been waiting until
> there was a new release of 1.9 to upgrade but it has now been months
> since I reported this.
it doesn't appear to be fixed in CVS yet. My guess is we won't see that
fix until 1.9.1 is released (or Snort 2.0, which ever comes first ;)
Speaking of broken clients though: Aren't broken clients just sending a
CR (0d) instead of CR/LF? Perhaps the rules should use that.
In addition, several similar rules in the ftp section (checking for
overly long filenames) could in my opinion be changed so that they allow
for a larger file name. A 0a within 100 doesn't seem to be long enough
for some FTP archives (like *cough*snortsam*cough*).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 187 bytes
Desc: This is a digitally signed message part
More information about the Snort-sigs