Possibility to lock iptables rules.

Possibility to lock iptables rules.

[Anders Fugmann]

Hi,

I would like to request a very simple feature: The possibility to lock
all iptable rules in the kernel, making them immutable.

This would be usefull on machines which act both as a firewall and as a
server. The problem today if an unwanted guest manages to break into the
machine running the firewall and becomes root, the person can easilly
change the rules, compromising the network guarded by the hacked
firewall.

If it was somehow possible to lock the rules once setup, the attacker
would be unable to modify the rules, the network guarded by the firewall
would not (pending on how the firewall was setup) not be compromised,
even if an attacker gained access to the firewall itself.

I was thinking something in the lines of:

iptables --lock [--action <PANIC|LOG>],

where 'action' would specify how the machine should react if anyone was
to try and modify the rules. PANIC would cause the system to panic. LOG
would simple make the kernel log the attempt and then ignore the
request.

The only way to unlock the tables would be to reboot the machine. I know
that this system if not 100% foolproof, as the attacker could install a
custom kernel, and then reboot the machine, but it would cirtanly make
at lot harder for most attackers

I really hope that this feature could be implemented. I know that is is
not excatly trivial to implement as the address of the bit signifying
that the tables are lock would need to be hidden to avoid the attacker
to simply write a zero the the specific address to unlock the tables.

Regards
Anders Fugmann

P.s.
Please CC me on replys, as I'm not on the list.

Re: Possibility to lock iptables rules.

[Taylor, Grant]

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.

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.

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.

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.



Grant. . . .

Re: Possibility to lock iptables rules.

[Anders Peter Fugmann]

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 
> thing.
Agreed.

> 
> 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?

Regards
Anders Fugmann

Re: Possibility to lock iptables rules.

[Taylor, Grant]

> 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. . . .

Re: Possibility to lock iptables rules.

[Jozsef Kadlecsik]

On Wed, 20 Apr 2005, Anders Peter Fugmann wrote:

> 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.)

You can use any of the MAC systems of Linux and (when properly configured)
then even root won't be able to change the firewall/network settings of
your machine. Some of such systems in no particular order: SELinux, LIDS,
grsecurity, RSBAC.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Possibility to lock iptables rules.

[Jason Opperisano]

On Wed, Apr 20, 2005 at 12:49:15PM +0200, Anders Fugmann wrote:
> Hi,
> 
> I would like to request a very simple feature: The possibility to lock
> all iptable rules in the kernel, making them immutable.
> 
> This would be usefull on machines which act both as a firewall and as a
> server. The problem today if an unwanted guest manages to break into the
> machine running the firewall and becomes root, the person can easilly
> change the rules, compromising the network guarded by the hacked
> firewall.
> 
> If it was somehow possible to lock the rules once setup, the attacker
> would be unable to modify the rules, the network guarded by the firewall
> would not (pending on how the firewall was setup) not be compromised,
> even if an attacker gained access to the firewall itself.

i'm guessing you're thinking about how the *BSD's have a concept of
kern.securelevel, and certain things (like firewall rules) become
immutable; even by root, at certain levels.

i'm not a kernel programmer, but i can tell you that the linux kernel
doesn't have anything like kern.securelevel; and without it, i don't
believe what you're asking for is possible.  i'd also figure that
implementing kern.securelevel in the linux kernel would be beyond the
scope of what the netfilter developers are responsible for.

-j

--
"Stewie: Careful! You're washing a baby's scalp, not scrubbing
 the vomit out of a Christmas dress, you stupid holiday drunk."
        --Family Guy

Re: Possibility to lock iptables rules.

[Jason Opperisano]

On Wed, Apr 20, 2005 at 02:47:53PM -0400, Jason Opperisano wrote:
> i'm guessing you're thinking about how the *BSD's have a concept of
> kern.securelevel, and certain things (like firewall rules) become
> immutable; even by root, at certain levels.
> 
> i'm not a kernel programmer, but i can tell you that the linux kernel
> doesn't have anything like kern.securelevel; and without it, i don't
> believe what you're asking for is possible.  i'd also figure that
> implementing kern.securelevel in the linux kernel would be beyond the
> scope of what the netfilter developers are responsible for.

after pondering this further (post-post, natch)...i had a thought 
(yes--it hurt).  you could probably use SELinux to achieve this.  the
minimal benefits that others have pointed out, and the overly complex
nature of SELinux probably yields a pretty low benefit/cost ratio,
though.

just a thought...

-j

--
"Peter: Wow, is that really the blood of Christ?
 Preacher: Yes, it is.
 Peter: Holy crap, that guy must've been wasted 24 hours a day."
        --Family Guy

Re: Possibility to lock iptables rules.

[Taylor, Grant]

> after pondering this further (post-post, natch)...i had a thought 
> (yes--it hurt).  you could probably use SELinux to achieve this.  the
> minimal benefits that others have pointed out, and the overly complex
> nature of SELinux probably yields a pretty low benefit/cost ratio,
> though.

<smart a$$ comment>Want some ice?</smart a$$ comment>

Eh, the benefit / cost ratio might be low, but we are hackers and we do what we do for the challenge / fun / bragging rights of it.



Grant. . . .

Re: Possibility to lock iptables rules.

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Which is the number  one reason that a network's firewall should serve no 
other purpose then that, firewalling the network, and not allow outside 
nor most inside systems/users to connect to it, only those managing it.

Even immutable flgs can be undone on a server that is hacked and root 
gained.  And what you are requesting requires their be no modules on the 
system, everything has to be compiled directly into the kernel, including 
all the modules that iptables now deppends upon and uses.  You'd be much 
better off and safer to just not let the average user beable to connect to 
and enter the firewall.

Thanks,

Ron DuFresne

On Wed, 20 Apr 2005, Anders Fugmann wrote:

> Hi,
>
> I would like to request a very simple feature: The possibility to lock
> all iptable rules in the kernel, making them immutable.
>
> This would be usefull on machines which act both as a firewall and as a
> server. The problem today if an unwanted guest manages to break into the
> machine running the firewall and becomes root, the person can easilly
> change the rules, compromising the network guarded by the hacked
> firewall.
>
> If it was somehow possible to lock the rules once setup, the attacker
> would be unable to modify the rules, the network guarded by the firewall
> would not (pending on how the firewall was setup) not be compromised,
> even if an attacker gained access to the firewall itself.
>
> I was thinking something in the lines of:
>
> iptables --lock [--action <PANIC|LOG>],
>
> where 'action' would specify how the machine should react if anyone was
> to try and modify the rules. PANIC would cause the system to panic. LOG
> would simple make the kernel log the attempt and then ignore the
> request.
>
> The only way to unlock the tables would be to reboot the machine. I know
> that this system if not 100% foolproof, as the attacker could install a
> custom kernel, and then reboot the machine, but it would cirtanly make
> at lot harder for most attackers
>
> I really hope that this feature could be implemented. I know that is is
> not excatly trivial to implement as the address of the bit signifying
> that the tables are lock would need to be hidden to avoid the attacker
> to simply write a zero the the specific address to unlock the tables.
>
> Regards
> Anders Fugmann
>
> P.s.
> Please CC me on replys, as I'm not on the list.
>
>
>
>
>
>
>
>
>

- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCZsN3st+vzJSwZikRAkGTAJ4v81r7y2w63YXg1vpgaoD1rOdRsACcCtbs
OWz5cGs/6Uonm6GAIdccz1k=
=B9FP
-----END PGP SIGNATURE-----