Dear Sergey,
normally TCP_Port_Scan Events are only triggered when the source IP-Adress
tries to open a multitude of different ports on one of your destination
IP's.
This is mostly not triggered by valid Webtraffic.
To analyse what's going on you should filter your event in the following
matter:
First take a source IP which triggered the TCP_Port_Scan event and look what
other events are triggered by this IP.
Probably you are now able to identify what's going on.
Are there multiple TCP_Port_Scans to other destination IP's?
Or only to one?
What destination Ports are scanned?
Second take one of your destination IP's which is attacked
(TCP_Port_scanned) and look wheter there are other events from you to the
outside.
What I've seen so far are the following two false positives which triggered
TCP_Port_Scan events a lot:
1: Some user tries to upload via ftp multiple files to his private
webserver.
Mostly they use tools to fasten the upload, by opening one connection per
file transmitted.
The back channel of ftp then opens for every file a new connection to
your uploading ip.
This triggers TCP_Port_Scan Events.
The IP outside your network seems to be the source, but it isn't
2: Some user have skype installed and used at home. The return back with
their laptop in your company and are booting.
Skype starts automatically and tries to connect to the last known good
peers.
Mostly the destination port is 80 and a whide port range between 20000
and 5xxxx.
This also triggers TCP_Port_Scan events, and the IP in your network is
definitly the source.
I tried to get ISS to help me customizing the TCP_Port_Scan trashhold, but
what they advised me to do didn't help.
Well by knowing that TCP_Port_Scans might indicate a forthcomming attack i
didn't want to ignore these events. So we decided to customize this
treshhold by ourselves.
And finally here is what we did:
We configured SP to send out emails for the TCP_Port_Scan event to a local
email server with a special e-mail account.
Then we coded in perl a little script which reads the e-mail queue for
TCP_Port_Scan Events and let it count for every source IP until 20. Then by
reaching this treshhold a new mail was generated to inform the incident
handlers (me and others) that there is a serious TCP_Port_Scan event.
How high your treshhold is, or should be, must be decided by you. I analyzed
all events on my sensor and saw that this is a good count to get rid of all
the false positives and to detect the real threads.
In 2004 I suggested ISS to correct or add a treshold handling for this
TCP_Port_Scan event, but well apparently they didn't.
I hope I was able to help you.
With kind regards
Holger Reichert
Owner Manager
Holysword GbR
IT-Security Consulting
Germany
_______________________________________________
ISSForum mailing list
ISSForum@iss.net
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo/issforum
To contact the ISSForum Moderator, send email to mod-issforum@iss.net
The ISSForum mailing list is hosted and managed by Internet Security Systems,
6303 Barfield Road, Atlanta, Georgia, USA 30328.
