[Snort-users] Viewing detail logs causes secondary false posi tive.

Graham, Randy (RAW) RAW at ...4721...
Tue Jul 2 09:44:29 EDT 2002


I don't know how others handle this, but I can tell you what I use where I
work.  My Snort central database and ACID console are on one machine which
is only accessible via SSH.  On that machine, I run Apache listening only on
localhost (127.0.0.1).  To view the ACID console, authorized users must 'ssh
-X username at ...6225...' and run konqueror on the ACID host.  This transports
the entire web session over an encrypted SSH tunnel.  Works great, no one
can get to my ACID data unless they break in through SSH (which I've updated
to avoid the latest OpenSSH vulnerabilty), and I don't have to do anything
for my users beyond loading cygwin and creating an account on the machine
hosting ACID.

RagManX

> -----Original Message-----
> From: R. Anthony Kolstee [mailto:tkolstee at ...6207...]
> Sent: Monday, July 01, 2002 0:23 AM
> To: snort-users at lists.sourceforge.net
> Subject: [Snort-users] Viewing detail logs causes secondary false
> positive.
> 
> 
> I run both SnortReport and ACID on my snort logs, and have experienced
> an interesting phenomena with both. Pardon me if this is in TFM
> somewhere...
> 
> When viewing the detailed logs including payload data on an 
> alert, I've
> found that the content revealed in the payload usually causes a
> secondary alert to occur. Obviously the content of the payload being
> viewed is going to contain the original string that caused the IDS to
> alert in the first place, but has anyone found a reliable way around
> this? My only thought at the moment is to use SSL on the web browser
> when viewing these reports; does anyone else have a better way around
> this that isn't immediately apparent to me? Note that I can't make the
> console immune or invisible to alerts on port 80, because the box in
> question is a collocated web server and as such is self-contained.
> 




More information about the Snort-users mailing list