[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
  • 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.
Reply
  • 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.
Children
No Data