Re: [cobalt-security] Re:Securing RAQs - gShield adaption project proposal

[Michael Stauber <cobalt@xxxxxxxxxxxxxx>]

Hi Jeff,

> Will you share your rules, Michael <smile>?  Pretty please <smile,
> again>?????

At the moment I dont consider my present ipchains rules to be good enough for 
that. Chances are that people might use them in good faith and get a wrong 
sense of security which I feel is not warranted at the moment.

Maybe you (or someone else reading this list) has some experience which I 
need and which I lack at the moment. I have no objections to share anything 
that derives from sticking our collective heads together and to throw out a 
good set of firewall rules for the RaQs that anyone can use if he likes.

Sure, I wouldn't mind to be hired for installing it for those people who are 
afraid of doing it themselves, but that's another matter.

While this list is security related (like this proposed project is) it might 
be that we should take this discussion to email.

Here is what I've got by now: The problem with my present firewall rules are 
that they lack the important DENY ALL rule at the end. You know how that 
goes: If you just got productive machines sitting around you can't afford to 
mess with stuff that has the likelyhood of interrupting services when you 
screw up. Customers don't appreciate service interruptions. ;o)

However, since Friday I've got a refurbished RaQ3i sitting right here next to 
me that I can use for developement of stuff like that. Sure thing, the 
developement of a decent firewall has first priority. 2.4-series of Kernel, 
glibc-upgrade and CPU-upgrade are next items in pipe. 


What I'm presently looking at is a way to adapt the old ipchains oriented 
gShield (http://linuxmafia.org/~godot/) to run on a RaQ3/4 with multiple IP 
addresses. I already made additions to the code to open up the Cobalt GUI, 
ASP-admin and the other Cobalt specific services from the main configuration 
file.

The unpleasant problem (even with having the machine sitting next to me) is 
that I still have to connect through Telnet/SSH for testing and can't just 
attach a keyboard and a monitor. Therefore any major screwup in the ruleset 
requires a frontpanel reboot to flush the firewall rules. Not being able to 
work through a local connection (through the NIC is not local) is pretty 
unproductive in cases where the firewall locked you out. 

The standard serial port connection just dead ends in the (useless) menu 
where you can configure the RaQs basic network settings. Does anyone know how 
to bind a root-shell to a serial port? I haven't managed to dig up that 
information yet (and I feel stupid about it).

Ideas anyone?


Speaking of CPU upgrade (before someone asks): It's almost (but only almost) 
a piece of cake if you locate the proper (and ancient) CPU type and model: An 
AMD K6/2+ with 550 MHz or AMD K6/III+ with 500 MHz will do just fine. The 
voltage doesn't match exactly (0.2 Volt difference), but these CPUs are kinda 
forgiving and inexpensive (45 bucks or so).

However, both replacement CPUs will then still run at the default 300MHz 
(RaQ3) or 450MHz (RaQ4). The fine thing about the sucessors of the K6/2s 
presently used in the RaQs is that you can increase the clocking with a 
software command (k6mult) which is not an option for the older models.

Usage of k6mult requires the insertion of a kernel module not present on the 
Cobalts and generating it is no trivial matter at all without having access 
to the same kernel sources that Cobalt uses. 

Once you've got it running you could even think about increasing the clocking 
dynamically in cases where you need more horse power and clock down to slower 
pacing when the machine just sits there idling along. That way you also avoid 
overheating which can be an issue with this type of upgrade and the rather 
flimsy heatsinks used in the RaQs.

-- 

With best regards,

Michael Stauber
mstauber@xxxxxxxxxxxxxx
Unix/Linux Support Engineer