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

["E.B. Dreger" <eddy+public+spam@xxxxxxxxxxxxxxxxx>]

> Date: Tue, 22 Jan 2002 20:38:57 +0100
> From: Michael Stauber <cobalt@xxxxxxxxxxxxxx>

> Five minutes of no firewall protection in 3-6 months should be a small risk 
> compared to the risk of being unable to repair improper firewall rules.

Maybe.  It helps if one has kept up-to-date with packages such
as, say, BIND... but if one waits for Cobalt packages, that five
minutes can be enough to get probed and owned.

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.

> > Don't close the session.
> 
> Oh, I won't and I wouldn't. But if the firewall blocks your SSH session 
> thanks to a screwed up ruleset, then your firewall reset script dies with the 
> session as well and it will simply not fulfill its purpose. We're not talking 
> BSD here, but Cobalt OS. I tried this half a year ago and it didn't work. 

One can also use 'at' or create a cron job; I usually go for a
cron job to reset firewall rules.  I was keeping my original post
short.

> We're not talking about the usage of a serial console, but about a working 
> mechanism to fix a bad firewall without serial console. And if the firewall 
> rules are so bad that they lock you out, then there won't be the possibility 
> to login with a second SSH login. The machine is then dead in the water and 
> all you can do is to reboot. At that point you need a mechanism in place 
> which ...
> 
> 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).

> We defenitely want the firewall to start automatically after a reboot, so 
> that's the point where a delay mechanism to start it X minutes after a reboot 
> sounds reasonable. However, whether that's 5 minutes or 5 seconds is 

Or using "last known good" rules.  I don't commit rules to
startup script unless I _know_ that they work.

> debatable. For people with only remote access to their machines 2-5 minutes 
> will most likely be a life saver, while those with physical access to their 
> machines most likely can do with a shorter period of time or can use the 
> serial console instead of a delay mechanism. It pretty much depends on the 
> environment (and how much you want to spend on security in a monetary sense).

One could argue that it's just part of running a hosting service.

> I love stateful firewall rules and stateful packet inspection. However, 
> ipchains has its limits, unless you talk about a heart transplantation and 
> switch over to iptables. 
> 
> Personally I prefer the SlotServer approach which I'm working on in my lab: 
> Put an Omnicluster SlotServer into the PCI slot of an RaQ3i or RaQ4i and run 
> a Debian, BSD or radically trimmed down SuSE Linux 7.3 on it with forwarding 

(Hey, don't ignore Slackware!)

> Squid, forwarding Postfix and an iptables firewall on it. Communication 
> between SlotServer and RaQ is then handled via private network IP addresses 
> through the gigabit ethernet interface implemented over the PCI bus, while 
> the SlotServer is connected to the Internet through it's 100MBit interface.

Yes.  A SPOF, but easier to effect policy changes.

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.

> That way you isolate the ancient RaQs OS but putting an additional layer of 
                           ^^^^^^^^^^^^^^^
> security in front of it. 

Yup.  I'm a BSD person myself.


Eddy

---------------------------------------------------------------------------
Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
---------------------------------------------------------------------------

Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.  Do NOT
send mail to <blacklist@xxxxxxxxx>, or you are likely to be blocked.