portscan2 ignore hosts

[Phil Wood <cpw () lanl gov>]

Folks, there is a little known preprocessor called:

   portscan2-ignorehosts: host1 host2 ...

The purpose of which is to not consider (host1 host2 ...) in 
portscan analysis.  In otherwords, do not report any "port scans" for
host1, host2, or any other hosts in the list (up to about 30).

I added some code that would log the arguments so it would be recorded
in the verbose information at snort startup.  (If portscan2 is going to
be included in future releases, it should probably get that boiler
plate included)

Conversation Config:
   KeepStats: 0
   Conv Count: 32000
   Timeout   : 15
   Alert Odd?: 0
   Allowed IP Protocols:  All

Portscan2 ignoring 4 hosts:
    10.10.4.4
    10.10.11.88
    192.168.3.1
    192.168.6.1
Portscan2 config:
    log: /some/place/scan.log
    scanners_max: 3200
    targets_max: 5000
    target_limit: 30
    port_limit: 30
    timeout: 5

Portscan2 still reports the 4 hosts as culprits.

Can you guess what is wrong with my configuration?  I'm sure you can, but
I'll answer it.  The ignore hosts configuration line must occur after the
portscant2 config.  If not, then the host list is ignored.  I don't believe
this is covered in the FAQ.  Also, the imperitive "portscan2-ignorehosts:"
is not expostulated in the ... etc/snort.conf file.

Now assuming you have got it right and have eliminated all the fast talkers
from contention, like nameservers and such, you get to look at the massive
quantities of data being spewed into the various logs (log.scan and alerts).

What I have found is that portscan2 cannot determine which is the culprit.
Example summary alert line:
11/05-12:03:33.081841  [**] [117:1:1] (spp_portscan2) Portscan detected from 10.10.254.1: 3 targets 31 ports in 4 
seconds [**] {TCP} 10.10.254.1:80 -> 66.13.39.134:4664

In reality the culprit is 66.13.39.134 not 10.10.254.1.  He tried 31 times 
to get information from a web server (10.10.254.1) in 4 seconds.  If you
look at the "scan.log", you will find the tcp flags from the server to the
client are SYN and ACK (2nd-way of 3-way handshake) .  Which is the way it
is with all client / server tcp based relationships.  (unless there is no
stimulus [SYN], ahh, but then there is no relationship)

So, bottom line, be cautious in your interpretation of the reports.  And be
ready for hundreds of thousands of them in less than an hour.  Fine tuning
is required.  And, possibly multiple sensors with different parameters for
different types of protocols.  Nameservers are zip/zap.  File transfers usually
take longer.  Email is somewhere in between.  Etc, etc ... etc.

Hope you don't mind my ramblings.

Later,

Phil


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users