This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Portscan Bug

Hi,

I've upgraded to Astaro V5 and my system is up-to-date (5.023).

I don't want to be annoying since I already saw some posts on the issue, but...

Portscan warning doesn't work.
Portscan rejection doesn't work.

PS: Keep up the good work, and keep it free for home users. This is an excellent product.


This thread was automatically locked due to age.
Parents
  • 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.
Reply
  • 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.
Children
No Data