Guest User!

You are not Sophos Staff.

[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.
  • P.S. I have no idea if the packet filter log is the problem (growing to fast?  Doesn't make much sense...).  Is there a way to turn off the packet filter log, or at least turn it down a bit?  I looked in the web interface and none of the extra logging options were enabled for the packet filter.
  • It sounds like you are running a commercially licensed version; I highly recommend that you start a support case with Astaro so they can investigate it.  They do roam these forums occasionally, but starting a case is your best bet to get it high in the priority queue.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • It sounds like you are running a commercially licensed version; I highly recommend that you start a support case with Astaro so they can investigate it.  They do roam these forums occasionally, but starting a case is your best bet to get it high in the priority queue.


    Sadly we have no support contract with them otherwise I would.
  • What is using all the cpu cycles? Run a terminal window before running nmap to see what is taking astaro down. Logging wouldn't make it freeze like that specially from the WAN side with limited bandwidth.

    EDIT: It would be interesting to see if you can reproduce it from within the LAN.
  • We are not using the home version of Astaro.  Maybe I don't understand the purpose of the "Essential Firewall - Free for business" edition of Astaro, but it (and the sales rep I talked to) seems to indicate that it is free for business use.  Again, perhaps I missed something, but I also don't think it comes with any sort of support beyond the forums.  Further, we are a non-profit with little funding, but if it turns out we are using this beyond the allowed purposes we will find the money to purchase a different edition.  We were, in fact, going to purchase a different edition, but they wanted to charge us per interface and, though we have very few servers, there are many interfaces (redundancy) which pushed Astaro out of our price range. 
    Anyways, back on topic, does anyone else experience this type DOS when doing a simple nmap of their address space?
  • I am assuming you are running the essential edition without IPS?
     See my previous post.

    What is using all the cpu cycles? Run a terminal window before running nmap to see what is taking astaro down. Logging wouldn't make it freeze like that.
    I plan to do this here soon, I didn't want to bring the firewall down a fourth time while people were working (all tech people so they were ok with a short outage), but that shortly won't be an issue.  Last time I was looking at log output in hopes that something would be logged about why things failed, this time I'll watch processes.
  • EDIT: It would be interesting to see if you can reproduce it from within the LAN.
    Haha, man you sure edit your posts fast.  I'll also try to do this here in a few.
  • Hehe, I was going on the home user license rant till I noticed that you had posted in the essential free edition.[:D]
  • I ran the test with TOP sorting by CPU use and this is what I found:
    1. ulogd began to eat up more and more CPU until things finally froze (it ended with ~40%, but it jumped higher at times).  This is especially a problem as ulogd runs at a nice of -1...
    2. postgres would pop in every so often and consume quite a bit of CPU.
    3. pfilter-reporte was also high up there, keeping around 15% of the CPU until ulogd grew too large and took up its share of the CPU as well (postgres is a nice of 0 so ulogd was able to eat its CPU allocation).
    Next up, attempting to crash things from the internal network.
  • Hi,
    have a look at your packet filter rule to se if logging is enabled on it.

    Ian M
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?