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 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

As a feature request I would like to see the port scan detection be able to detect packets dropped from the firewall and in turn be able to act on that and drop traffic from that source for a configurable amount of time.  As I have it set in a lab environment, I have 10 public IPs on one box, and each has two ports open.  In addition, in my production environment, I only have three ports open and regularly receive reports in logs of hundreds of dropped packets from a single source per minute for ten minutes or more and that is not detected. 

 A full port scan can be done from an outside IP of all public IPs simultaneously and the port scan detector is unable to 'see' this and take action on it.  If it indeed has to wait for attempts on 10 different ports for an IP then it will never be triggered if there are less than 10 ports open to the public.  If I remember correctly, there was more control on the port scan detection in past versions and I would like to see that control passed back to the users along with the additions mentioned above.

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?