[Snort-devel] Strange behavior observed in Viruscan 8 Pro

Bedon Cortazar Charles Edward cbedon at ...2535...
Tue Dec 6 15:04:01 EST 2005

Hello snorters,

We want to report a strange/curious behavior observed while studying the 
response of sfportscan preprocessor.

A host in our network has running MCaffe Viruscan Pro 8.0 Build 8.0.20 
Engine 4.2.6. It tries to update itself by making requests to 
MCaffe web server at through a proxy(yes, we 
know if not configured correctly, this update never could be initiated, 
but that is not the point). Each request the program tries to make, is 
rejected by the proxy (Viruscan update program sends a SYN, and web server(the proxy, in 
fact) seems to answer with a RST_ACK), so far, nuttin' strange. But when VS 
receives that answer it uses another port and other and other ... but the result is always the 
same. In Ethereal, we can see something like this (not the actual 
display format):

/*Three attempts for each port, the other 2 are not listed here*/ (SYN)--> (RST_ACK)--> (SYN)--> (RST_ACK)--> (SYN)--> (RST_ACK)--> (SYN)--> (RST_ACK)-->


What's the effect on Snort? well in "flow" preprocessor(first 
filter for all stateful portscan preprocessors like flowportscan and 
sfportscan), there is a flow 
hash, which key is a combination of srcIP,srcPort,dstIP and dstPort, and 
each time VScan changes the port for the update connection attempt, a new 
flow is risen. sfportscan reports this as a portsweep.

We think that one approach could be removing the srcPort from the key, 
for the good of the portscan detectors, since this is not a relevant 
parameter for the analysis. However, this could be a problem 
for the rest of preprocessors that makes use of flow_spp, if any.

Our questions are:

*Have u ever seen this behavior before?
*What do u think that could be a solution for this issue?


Andrés Arboleda
Charles Bedón

Faculta de Ingeniería Electrónica y Telecomunicaciones
Univeridad del Cauca
Popayán - Colombia

More information about the Snort-devel mailing list