All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Newkirk <netfilter@newkirk.us>
To: Remus <rmocius@auste.elnet.lt>, netfilter@lists.netfilter.org
Subject: Re: router protection with iptables
Date: Tue, 26 Nov 2002 03:04:53 -0500	[thread overview]
Message-ID: <200211260304.53774.netfilter@newkirk.us> (raw)
In-Reply-To: <01bd01c2946f$c8498fa0$6e69690a@rimas>

On Monday 25 November 2002 05:45 am, Remus wrote:
> Hi folks,
>
> I have small router on Linux box.
> It has two NICs and I use it to route real IP addresses (basicly I use it
> to replace CISCO router, it is cheaper :-) )
> I have a command echo 1 > /proc/sys/net/ipv4/ip_forward and everything
> works just fine.
>
> I'm wondering about iptables rules which I can use to protect my router
> from hackers.
> I want all IP/UDP/ICMP packets to go trought my router in both ways, just
> to protect my router.
> Behind the router I have Firewalls and they do a protection job for my www,
> mail and local network.
>
> What you can recomend for me?

/sbin/iptables -p INPUT DROP
/sbin/iptables -p OUTPUT DROP

Is a damned good start.  If nothing gets in, and nothing gets out, it's almost 
not there.  As long as ip_forward is enabled, and you have rules in the 
FORWARD chain to allow desired traffic to be forwarded, you're set.  You will 
only be able to access the firewall machine itself locally.  If you really 
want/need remote admin ability, add ACCEPT rules to INPUT chain for the 
connections you want to allow, being as specific as possible, (IE, only allow 
very limited protocol/port access from local network, or specific select 
IP's, etc) but if you can deal with local logon only then just DROP 
everything at INPUT and be done.

As an example, my config allows webmin access (on a non-standard port) and a 
few others, but ONLY from certain specified IP's, all others are silently 
DROPped.  And all accesses, whether dropped or accepted, are logged.  As 
further security, only localhost or one local IP are normally granted access 
(still requiring authentication), the others are invoked/revoked manually 
(locally) when I anticipate needing them, by passing parameters to my 
firewall script.  (currently recognizing 17 commands)  If I desperately need 
remote access when away and haven't anticipated it, I'm screwed, but I accept 
that.

I'd recommend -p FORWARD DROP as well, then ACCEPT rules for the traffic you 
actually want it to forward.  As long as they're configured properly, an 
extra firewall never hurts...

j



  reply	other threads:[~2002-11-26  8:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-25 10:24 Marking and Mangling for QoS COUSIN Marc
2002-11-25 10:29 ` Unknown, Raymond Leach
2002-11-25 10:45 ` router protection with iptables Remus
2002-11-26  8:04   ` Joel Newkirk [this message]
2002-11-25 13:50 ` Marking and Mangling for QoS Joel Newkirk

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=200211260304.53774.netfilter@newkirk.us \
    --to=netfilter@newkirk.us \
    --cc=netfilter@lists.netfilter.org \
    --cc=rmocius@auste.elnet.lt \
    /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.