Possibility to lock iptables rules.
Anders Peter Fugmann
afu at fugmann.net
Wed Apr 20 22:56:07 CEST 2005
Well written, and your arguments are truly valid. I still see a
practical usage though, as it will hold back the big mass of novice
script kiddies. The lock bit would harden the system, but not make it
unbreakable (there is no such thing as an unbreakable system, that is
connected on the net.)
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 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.
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.
> 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.
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.
> 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
> 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.
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.
> 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.
The question is not to make an unbreakable system, but to make a system
that is harder to break than your neighbours.
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?
More information about the netfilter