I have commented on (most) you points below.
Taylor, Grant wrote:
I don't know of a way to lock IPTables rules in the kernel, but this is my take on what you wrote.If the system cannot reboot (by bios), then this is avoided. But indeed, root have total control, and can bypass even the most complex trip wires if experienced enough.
If you did lock IPTables rules in to the kernel the only way to work with them would be to modify the firewall script and reboot the box (which is trivial if you gain root to a box). This does little more than make it a pain and could easily be scripted.
True. Software cannot give what extra hardware gives in terms of security - And I'm not suggesting that. What Iøm looking for is some way to trip the attacker, by causing the system to panic it the attacker tries to modify the rules. If the attacker tries to reboot the system (after modifying the startup scripts), monitoring systems will usually detect this, and can generate an alert. This is what I'm looking for.
This is really the reason that firewalls / routers are suppose to be standalone boxen. The idea behind this is to not run any service(s) on a firewall / router that could be exploitable. If you do want to have your firewall / router offer services to the world port forward any requests that you want to serve to a system behind the firewll / router in the DMZ which is in and of it's self firewalled from the rest of the network, this prevents this system from having access to the internal LAN if it is breached its self. By doing this the firewall / router it's self is not offering any exploitable services to the world and thus can not be hacked in to via standard methods.
One solution that sort of applies, in such that it is impossible to modify a running firewall / router, is to run the firewall / router in runlevel 0. Granted you could not use such a system as a standard server if you did this but it would allow the firewall to be running in production in such a way that it could not be modified or even accessed in any way shape or form remotely. You would end up havening to reboot the box and send it in to Single user mode to work with things. I personally have never done this as I have never felt the need to be that paranoid about my firewalls. Typicaly I will run a firewall with no services listening on the internet side of the box and just SSH listening on the internal side. If I am even more paranoid I will put the firewall / router physically close to another server and run a serial cable from the server that does have remote access (SSH) to the firewall / router and do everything via serial console. By using a serial console on
the router and no services listening on any interface it is virtually impossibly (as far as I'm aware of) to connect to the box and modify any thing.
Agreed.
This is not always an option to install extra hardware. For one you need to administer the system, and I guess that it would be hard to find hardware that can run 24/7 for 50 bucks. Also in some companies it will not be possible to setup an extra machine for firewalling (by policy, not rationale). I actually thought of running all services in user mode Linux first, but then got the idea to lock the rules - which is less secure, but a whole lot simpler.
Honestly in my (humble) opinion go spend $50 on a used system (if you don't have one) drop a couple of NICs in it and set it up as your firewall and port forward the traffic that you want to serve to the world to it.
The question is not to make an unbreakable system, but to make a system that is harder to break than your neighbours.
As far as a way to lock rules in to the kernel I don't know that there is a way to do so nor do I think there should be a way as it would do nothing but slightly (2 - 10 minutes) slow down a good cracker. Sure it might stop some script kiddies, but if a cracker can do it they can script it too, hens the latter problem.
Also, clueless script-kiddies usually offers the greatest security risk. They, in contrast to professionals, usually just want to exploit the system. Professional crackers most oftenly crack systems to challenge themselves - not to destroy or exploit data on the systems found.
Thinking more about how to implement the system, I don't thank that it is nessesary to hide the address of the bit locking the rules in the kernel, as I guess that it would be just as simple to find the head of the lists containing the rules, and zero them out (putting a null in place of the list head). If anyone is interested, I can make the patch, and post it on the devel list. Any comments on this?
Regards Anders Fugmann
