[BUG][8.001] NMAP DOS of Astaro

Let me explain our setup really quick before I launch into what is going on.  We have Astaro, running on VMWare, serving as the gateway for a very small (~8 machines) internal network and very, very low network traffic (almost none).  The few of us outside the network that need access into the network use a very simple PPTP setup where we login and get an internal IP.  All pretty standard.
Anyways, up until yesterday, we were running the Astaro v8 beta software, but we decided to upgrade all the way up to 8.001.  Today, I needed to do a port scan on the internal network while I was outside of it, so I fired up the VPN, and ran the following nmap:
> nmap -sS -p1-65535 192.168.0.0/24

To my surprise, about halfway through my NMAP I got a notice that my connection to the VPN had been dropped.  I assumed that either I had triggered some security feature or this had been a coincidence, so I asked a coworker to attempt to VPN to the machine; no connection.  About this time Nagios (sitting outside the VPN) started freaking out about all of the machines inside the VPN (NRPE - using simple port forwarding).  I went to vSphere and hit Astaro's console only to find that it wouldn't respond to any key presses at all (it was at the Astaro splash screen).  I finally had to reboot it in vSphere.
I believed, at the time, that the problem was just coincidental to my scan, after all we had done the same exact scan many times in the past, but a second attempt caused the same behavior.  On a third attempt, I tail -f'd all of my log files and, other than a rapidly exploding packet filter log, nothing unusual was reported up to the very moment that everything just froze up.  
I used vSphere's Performance tab and noticed a few things.  First, around the time my nmap started, the CPU usage on Astaro jumped to 100% and stayed there even after the machine froze.  Now, the server that this is on has two 2ghz quadcore CPUs and Astaro has full access to all of those resources as it needs it, so I doubt the box's performance is an issue.  Disk space is not large at all (~62% of the allocated space).
I'm not ready to rule out VMWare as the culprit here, but I do want to remind anyone reading this that we never had this problem with the v8 beta versions even when we were running much higher network traffic.
Parents Reply Children
  • Essential firewall is a recent offering by astaro so I haven't seen the available tabs on webadmin. The problem is that most of us have SYN protection with limited logging/ logging disabled altogether available with our subscriptions. Even with the IPS system off, you can easily manage the simple SYN attack that you are simulating by limiting logging and dropping packets beyond a certain threshold. Those options are not available in essential edition[:(]  

    Are you using the same version of nmap that you tested against beta versions. I can't figure out what has changed that is causing a production release to act worse than a beta release. 

    I will still be interested to see your I/O results along with what you actually observe with your hard drives.
  • Even with the IPS system off, you can easily manage the simple SYN attack that you are simulating by limiting logging and dropping packets beyond a certain threshold. Those options are not available in essential edition[:(]
    I understand that there needs to be feature differences, but I really wish customized logging was in all version.

    Are you using the same version of nmap that you tested against beta versions. I can't figure out what has changed that is causing a production release to act worse than a beta release.
    Same version.  Only change was from the beta to 8.001

    I will still be interested to see your I/O results along with what you actually observe with your hard drives.
    Yeah, so the Disk Write Rate jumps from an average of less than 50kbps to about 1,500 kbps until things froze up and it drops to zero.  

    Turns out there was already only one virtual CPU assigned to the machine, so no luck with that solution.  I wish that we had the resources to put Astaro on its own machine instead of on a virtual machine, but, as of right now, I'm going to say that the problem has something to do with CPU usage and disk write speeds.  I don't really know why I can't replicate the problem on the internal network, perhaps the load of the VPN traffic is bad enough to cause the difference.

  • Tons and tons of dropped packets


    Are they packets you EXPECTED to be dropped? Why or why not?

    What ranges are you scanning?

    Barry
  • He is doing a nmap syn scan on 192.168.0.0. With default settings, I believe he is coming in as default 10.x.x.x for vpn and then hammering asg with all those packets.

    Internally he probably is on 192.168.x.x subnet so not all the traffic is passing through astaro therefore it doesn't go down.

    Really nothing out of the ordinary here, without any kind of protection the firewall is only as good as the hardware its running on and on virtual environment troubleshooting is even harder. Whats troublesome is that the logging daemon is taking the whole thing down which shouldn't happen on a UTM even without any DOS protection. 

    I can see both sides here. Is is better to take the firewall down if the logging daemon can't keep up or the packets should keep flowing even if the logging daemon is completely overwhelmed.

    Probably the free version should have a limit logging function available to let the admin make the choice instead of the firewall.