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

[Michael Stauber <cobalt@xxxxxxxxxxxxxx>]

Hi Eddy,

> When I perform a hardware or kernel upgrade, or (on a BSD machine
> with high securelevel) when I need to overwrite immutable files.
> Anywhere from every three months to once every a year and a half.

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.

> > I might be wrong here, but scripts are bound to the user
> > session, right?   That's most likely an incorrect term and what
> > I want to say is this: You start a script from SSH (or
> > Telnet) and when you close the connection the script will be
> > termintated, too. Unless you daemonized it, which requires
>
> 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. 

> If the script is good (one can test over
> serial console or via second SSH login), kill it while it's
> sleeping.  You're now running with new rules.

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.

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 
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).

> Yes.  Multiport serial cards are also handy... even more so when
> running stateful rules whose state is erased when reloading
> rules.

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 
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.

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

-- 

With best regards,

Michael Stauber
mstauber@xxxxxxxxxxxxxx
Unix/Linux Support Engineer