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 [email protected] TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo/issforum To contact the ISSForum Moderator, send email to [EMAIL PROTECTED] The ISSForum mailing list is hosted and managed by Internet Security Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
