[Snort-users] preprocessor sfportscan does not generate alerts

waldo kitty wkitty42 at ...14940...
Mon Feb 25 14:42:55 EST 2013

On 2/25/2013 09:55, johnny.venter wrote:
> I need clarification on preprocessors and rules.  In the example, below, the preprocessor for sfportscan is "enabled" and it writes an output log to a certain directory when I detects a portscan.  But Snort will *NOT* generate an event unless there is a rule enabled for a portscan???
> I have a similar situation where sfportscan is enabled and writes to a log directory.  It successfully detects various Nmap/Scapy port scans.  But Snort never generates an alert in the u2 file.
> Is there way to generate an alert without creating specific port scan rule?  If not, this would seem redundant because sfportscan already successfully detects portscans.

as i tried to note, below, sfportscan does NOT detect /all/ port scans... for 
those that it does not detect, rules may be necessary to catch them if they are 
that important to your network's detection/protection policies...

> Thanks.
> On Feb 18, 2013, at 4:24 PM, waldo kitty  wrote:
> On 2/18/2013 12:16, Marc Belanger wrote:
> Thanks for your reply...
> Q: "do you have those specific rules enabled?"
> A: My understanding is that by removing the # character the preprocessor is
> activated.
> I am not aware of a sfportscan.rule file.
> scan.rules is not commented out (no # in front of it)
> Q: "do your scans follow the specific portscan rules that snort has in the
> preprocessor?"
> A: preprocessor sfportscan: proto { tcp } scan_type { all } (...)
> or preprocessor sfportscan: proto { all } scan_type { all } (...)
> does not generate alerts for nmap -sS
> right... some scans are not detected by the portscanner... there are specific
> rules written for them... in this particular case, the EmergingThreats rule
> 1:2000537 or 1:2000545 covers "nmap -sS"... i count at least twenty-five (25)
> nmap related rules in both the VRT and the ET rules sets...

More information about the Snort-users mailing list