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 [EMAIL PROTECTED] Unix/Linux Support Engineer _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
