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
next prev parent 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.