possible astaro v7.005 security issue

Yeah, a number of people have reported that BitTorrent is good at causing v7 to suck up CPU like crazy causing it to go unresponsive.

Like to know why he cant post here...

it's because they have images and smilies highly restricted.  The images from the webadmin didn't come through on the blog post for some reason..another bug i have to hunt down..[:)]

I've got the same problem.  The torrent seems to work, but slowly; everything else dies and take about 15 minutes or a forced reboot to come back up.

Is there any possible way to work around this?  A DMZ of some kind?

Is there any possible way to work around this?  A DMZ of some kind?

i'm not going to advocate nor try putting my pc on a dmz that renders the firewall effectively useless for that machine..no thanks.

I'd rather put my PC on the DMZ for a few hours while I use a torrent than overload my Astaro box and kill all my PC's connections to the world.

that's your choice..but putting any machine unprotected on the internet is asking for it to get owned.  Run a firewall on that machine if you are going to dmz it.

I have now growing short of patience. I have logged and logged and logged support calls and support cases regarding this issue. This bug should be treated as High Risk, because of the potential for a DoS. Astaro's answer to my queries:

"this is a known issue which will be fixed in a upcoming up2date package.
Unfortunately at the moment I can't mention a exact release date when it will be fixed.

Thank you very much for your understanding."

This is a typical answer from Astaro support, not something you want to see from a security company, you have put your trust in to protect your digital assets! [:@] 

Very disappointed in their support and response. Will not be renewing our contract or subscriptions when it comes up for renewal! Anyone out there got any recommendations on alternative corporate level UTM solution?

added the tacit acknowledgment of this issue to my original blog post.

FWIW, this would probably only be a DOS from inside, not from an external attacker.

Barry

FWIW, this would probably only be a DOS from inside, not from an external attacker.

Barry

I just replicated the issue on a lesser scale using BT but throttling hte number of connections.  I didn't bring the machine to a halt(i got the load up to 5 though instead of 9 which is where it died at last time) and pfilter-reporte took hours to sort through it.  I did take a 20% decrease in overall performance while this went on and the number of PPS isn't that high.

The flood from Bt happens when you don't always have the correct ports open for return traffic and DHT and they all look like unrequested packets and the firewall properly drops them.  I can put in my ipcop hard disk and jack up the max global connections to 2k..max that out..leave the DHT and return path firewall ports closed and ipcop never uses more than 2% of the cpu.  Basically somebody could throw a bunch of random data at the machine(and it doesn't take a bunch) from the outside w/o BT initializing and bring the machine to a crawl.  This is a classic DOS scenario in terms of it doesn't take much to have the machine choke.

I'm not saying if you overload the incoming pipe and DOS..there's nothing to do there..but more than a few PPS and the machine falls over..that's a classic DOS vulnerability.

i'll post images from the executive report that shows the systems cpu during my testing.

FWIW, this would probably only be a DOS from inside, not from an external attacker.

Barry

I just replicated the issue on a lesser scale using BT but throttling hte number of connections.  I didn't bring the machine to a halt(i got the load up to 5 though instead of 9 which is where it died at last time) and pfilter-reporte took hours to sort through it.  I did take a 20% decrease in overall performance while this went on and the number of PPS isn't that high.

The flood from Bt happens when you don't always have the correct ports open for return traffic and DHT and they all look like unrequested packets and the firewall properly drops them.  I can put in my ipcop hard disk and jack up the max global connections to 2k..max that out..leave the DHT and return path firewall ports closed and ipcop never uses more than 2% of the cpu.  Basically somebody could throw a bunch of random data at the machine(and it doesn't take a bunch) from the outside w/o BT initializing and bring the machine to a crawl.  This is a classic DOS scenario in terms of it doesn't take much to have the machine choke.

I'm not saying if you overload the incoming pipe and DOS..there's nothing to do there..but more than a few PPS and the machine falls over..that's a classic DOS vulnerability.

i'll post images from the executive report that shows the systems cpu during my testing.

Yep, I concur with your analysis, William. Shouldn't matter whether you are on the inside or outside to trigger this DoS.

Just wondering if any of you guys have opened an official support case with Astaro;  I think this is something that they would need to address, as the DoS potential is definitely there.

Just by chance I went to the Known Issues List for V7, which was updated 24/07/07, and I am yet to find the pfilter-reporte bug or the multi-host DNS bug reported. So either this is still not being identified by Astaro as a known issue and will not be included in the 7.006 update or Astaro does not keep its users informed as to what are REAL issues their non-security gateway has. I am so tired of this, I am ready to scream. I will not be renewing our support contract as I feel I am not getting the service and support I am paying for. I am disappointed in Astaro, which seems to have taken a nose dive on customer relations, and putting out a stable product. V7 should not have been released to the public so soon, as it still appears to have so many Major bugs that can be exploited. And what makes me furious is the fact that Astaro has taken such a blasé attitude to identifying, fixing and keeping their customer's aware of these issues! Astaro's whole service approach is wrong and that will be their downfall.

Hi-con, unfortunately what you say is SOP in most of the industry. If you can find a better solution than Astaro with better support for a similar price, please let us know!

Here's my take on the situation for what it's worth.  By not putting security bugs in the known issue list, Astaro is doing the proper thing.  Those sorts of bugs should only be documented internally for developers to fix.  If they were to put these onto a publicly accessable list, it would be like hanging a giant neon sign saying "Hack our products now, and here's how...".  No reputable, ethical company should do that.

I completely agree that not all security bugs should be publicly disclosed until a fix is publicly available.

But when one is already well known and affecting multiple customers, it's better to let your customers know what the issue is (if known), what you are doing to fix the issue and when you expect to have a fix to the issue available.

Keeping silent only lets the customers assume the worst.

Astaro has taken a few steps to make some things better communicated and they often do have engineers browsing the forum, but I and I'm sure others would appreciate more of an Astaro presence on the forum, especially when they suggest using the forum as one of the first places to look for support.

It would also be helpful to have an easy way to tell who is affiliated with Astaro - For example, it'd be awesome to know who works for Astaro as well as to know who is a reseller by looking at their profile or their "title". Astaro employees could get a "Astaro Engineer" title and resellers could get a "Astaro Reseller" title instead of the generic ones we have now based on how many posts you make.