Portscan Bug

I thought the same thing; the portscan IPS component is not working. However, I then realized that the IPS processes packets AFTER they have passed by the firewall and things like the Syn Rate Limiter. If you set up a honeypot or IP in your network, nat a bunch of services to it, open on the services on the furewall, disable the Syn Rate Limiter, and run nmap (or Nessus as I did) you will see the portscan detection and other IPS ruls kick into high gear. For the portscan to work it must see 10 unique ports hit from the same source IP within one minute. At least this is my understanding of the mentioned components of Astaro – I have only been using it for a week.

I do agree that this is an excellent product and truly appreciate that Astaro provides a robust home version for free. 

Personal office version 5.026

I'd still contest that the Portscan component is not functioning as described.

ASL Manual Page 325:
 [ QUOTE ]
Portscan Detection: The Portscan Detection system watches for and blocks  portscans and sends e-mail messages to the administrator.  

[/ QUOTE ] 

With my standard configuration, when I run a portscan from GRC.com it identifies a handfull of open ports and lots of stealth ports.  If I understand your reasoning, the portscan isn't identified because the packet filter drops the majority of the trafic before it ever gets to the portscan IPS component and the IPS doesn't see enough traffic to detect a portscan.    Fine.  I don't like it but I can see the reasoning.

Test #2:  Setup a packet filter rule allowing traffic from shieldsup.grc.com to my internal server.  Rerun portscan.  GRC reports  lots  of closed ports (no longer stealthed), and the same handful of open ports.  The firewall sends me a notice that it detected a portscan (good), but obviously it did not  block  the portscan (bad) otherwise GRC wouldn't have identified the higher numbered open ports.  

Why is it that the portscan detection feature cannot identify AND blackhole traffic as it did in ASL 4?  FWIW, wouldn't ASL 4 detect and block portscans regardless of the packet filter rules?

Cheers,
JD

Note: Tests run on ASL 5.100.

I'd still contest that the Portscan component is not functioning as described.

ASL Manual Page 325:
 [ QUOTE ]
Portscan Detection: The Portscan Detection system watches for and blocks  portscans and sends e-mail messages to the administrator.  

[/ QUOTE ] 

With my standard configuration, when I run a portscan from GRC.com it identifies a handfull of open ports and lots of stealth ports.  If I understand your reasoning, the portscan isn't identified because the packet filter drops the majority of the trafic before it ever gets to the portscan IPS component and the IPS doesn't see enough traffic to detect a portscan.    Fine.  I don't like it but I can see the reasoning.

Test #2:  Setup a packet filter rule allowing traffic from shieldsup.grc.com to my internal server.  Rerun portscan.  GRC reports  lots  of closed ports (no longer stealthed), and the same handful of open ports.  The firewall sends me a notice that it detected a portscan (good), but obviously it did not  block  the portscan (bad) otherwise GRC wouldn't have identified the higher numbered open ports.  

Why is it that the portscan detection feature cannot identify AND blackhole traffic as it did in ASL 4?  FWIW, wouldn't ASL 4 detect and block portscans regardless of the packet filter rules?

Cheers,
JD

Note: Tests run on ASL 5.100.

If I remember correctly, ASL 4 did catch and block regardless of the rules.  What is the point of having a port scan detector if it does not detect and react as stated?