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.
One thing that could be done even in the situation where an attacker could reboot the system would be to netboot (or boot the router off of a CD-ROM) the router in question (though this implies that you have something to netboot it off of) where the attacker would not have any access to the medium where the actual firewall script is stored. Though if they did breach security on the firewall chances are decent that they could breach the system that was netbooted off of. But again this is just something else to slow down the attacker.
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.
Something devious that you could do would be to not call the iptables binary directly, but rather another binary that looks as much like iptables as possible that is really a farce that would panic the system. You would end up wanting to call a script that aliased iptables to the real command, run your firewall script (as a child process to inherit the alias?) and then unalias the iptables command. This would certainly slow down a lot of script kiddies.
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.
Quite true. Red tape seems to be everywhere these days. I'll tend to disagree with you on hardware that will run 24/7. I have turned MANY an old discarded workstation in to an extremely robust firewall. Granted this might not be politically acceptable but it does work. How many people here on this mail list use an old system at their house for a firewall that has been up for a number of days that is 3 digits long? (my hand goes up in the air now (multiple times for a lot of my clients))
The question is not to make an unbreakable system, but to make a system that is harder to break than your neighbours.
This might be the normal case, but not for some of my clients. I have a client that is one of the major prescription drugstores here in town. I think they might be a bit more of a target than the average cable modem. But yes the point of your statement is very correct.
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.
Is this so much the script kiddies or more the owned / infected systems running bots (controlled by said script kiddies). <rant>I REALLY wish that ISPs would start doing egress filtering, at least as far as to make sure that traffic leaving their network was valid, i.e. not spoofed or malformed.</rant>
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?
I personally do not see much of a point in doing this as I tend to do other things for this security. However that being said I'd be interested in seeing how such a feature would be implemented and put it on the shelf of known things that I could possibly used at some of my clients. So don't go to too much effort, but I'd be interested in hearing your thought process on how to implement this (on or off the mail list does not matter to me).
Grant. . . .
