All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Taylor, Grant" <gtaylor@riverviewtech.net>
To: Anders Fugmann <afu@fugmann.net>
Cc: netfilter@lists.netfilter.org
Subject: Re: Possibility to lock iptables rules.
Date: Wed, 20 Apr 2005 11:40:27 -0500	[thread overview]
Message-ID: <426685FB.4040607@riverviewtech.net> (raw)
In-Reply-To: <1113994155.31280.29.camel@localhost.localdomain>

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


  reply	other threads:[~2005-04-20 16:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-20 10:49 Possibility to lock iptables rules Anders Fugmann
2005-04-20 16:40 ` Taylor, Grant [this message]
2005-04-20 20:56   ` Anders Peter Fugmann
2005-04-20 22:13     ` Taylor, Grant
2005-04-21 13:53     ` Jozsef Kadlecsik
2005-04-20 18:47 ` Jason Opperisano
2005-04-20 22:01   ` Jason Opperisano
2005-04-20 22:16     ` Taylor, Grant
2005-04-20 21:02 ` R. DuFresne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=426685FB.4040607@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --cc=afu@fugmann.net \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.