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

  • 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.
  • I hate to say it, but I don't think there is much more to say on this topic.  Unless the devs are going to add in a 'sane' packet filtering option for those of us stuck in the free version, I guess I have to accept the "Doing this hurts.  Don't do that then." solution.  Thanks for the help guys.
  • You could create a rule to DROP the desired traffic without logging it.

    Barry
  • Sorry for responding a bit late.

    I tried to reproduce your issue first on real hardware, then with ASG V8 running on Vmware ESX4, with both I was unable to reproduce the issue you see.  However, we have one of the larger Vmware ESX installation with plenty of CPU and storage available and fast interconnects.  I  used a 100 Mbit/s connection with exactly the nmap command line you used.  I'll try Gigabit speed also, but I think the bandwidth may not be relevant here.

    The PPTP tunnels didn't go down then.

    During my tests ulogd, syslog-ng and pfilter-reporter were the programs consuming more CPU cycles, but this is kind of expected, as those are the programs participating when writing packetfilter.log.  During peek times packetfilter.log grew at about 2000 lines/s.  I'm not finished yet with my tests and will continue with some more PPTP tests.

    You are right with your observation that ulogd is reniced to -1, if looping somewhere it would hog your machine somewhat.  You should be able to debug ulogd by changing ulogd logevel in /etc/ulogd.conf (and /etc/ulogd.conf-default) to 'debug', then do a restart of ulogd (/etc/init.d/ulogd restart).  It will then do increased logging to system.log.  However, please not that if performance is your problem it'll get even worse when enabling the debug swtich.
  • I just wanted to mention this thread that I finally found: https://community.sophos.com/products/unified-threat-management/astaroorg/f/52/t/26137
    I don't love the idea of turning the packet filter reporter off, but we've got to do what we've got to do I guess.
  • I don't love the idea of turning the packet filter reporter off, but we've got to do what we've got to do I guess.
    Yeah, disabling that line just really pisses the syslog utility off, I don't recommend it.