Re: [cobalt-security] Portsentry, ipchains and pmfirewall

[Michael Stauber <cobalt@xxxxxxxxxxxxxx>]

Hi Eddy,

> The danger is even worse when a UDP-based service has a remote
> exploit, as one needn't complete a TCP handshake to accept and
> process packets.

Ooooh yeah <double-sigh>. Webmin is a nice example (and ripe target) for the 
dangers of falling prey to an UDP attack. As much as I love(d) Webmin, it's a 
dire security risk these days.

> > a) Either resets the firewall to the last set of good rules
> > ... or ...
> > b) Prevents the firewall from starting with the bad rules.
>
> If one lacks serial console, I agree.  The approach that I
> describe is for (a), which I prefer over (b).

Correct. It requires slightly more scripting efforts and some 
logic to put that into action, but it's sure the better choice.

> (Hey, don't ignore Slackware!)

That's one I haven't tested yet, so I can't relate. 

> People should run a separate 802.1q-capable router/firewall,
> anyway, if providing colo service.  Sniffing can make for a bad
> day.  An external router/firewall really is just part of doing
> business.

I see it the same way, but it's hard to educate people towards that ideal 
unless they get hit hard enough by bad luck and property damage. It starts 
much lower than that actually. Just today I worked for an "ISP" who had not 
even bothered to backup his primary webserver. Well, who's to blame? I don't 
want to point fingers, but selling these things as "Server Appliance" 
(therefore suggesting: Plug and Play, Ready to Run, No Extras Needed) doesn't 
really prepare most of the start-ups to deal with a environment as hostile as 
the internet. This even hurts SUN/Cobalt itself, as they apparently can't 
even sell their own Firewall (the Velociraptor) with success. 

Speaking of it ... see URL below for an interesting (half way related) 
article: http://www.theregister.co.uk/content/6/23770.html

-- 

With best regards,

Michael Stauber
mstauber@xxxxxxxxxxxxxx
Unix/Linux Support Engineer