iptables for linux router/firewall on home lan
William Gill
home lan that accesses the internet via pppoe with dynamic ip.
I run apache (httpd)and sendmail on www1, for local (lan) use only.
so the physical setup looks like:
ADSL
|
modem
|
ppp0 (dynamic ip)
|
www1
eth0 (192.168.1.x)
|
hub
| | | |
winxp_1 win98_1 win98_2 etc....
I know I have errors in my current iptables script (below) because I
misunderstood some things (particularly targets), so some rules pass
things on to ACCEPT too soon. I am trying to redo everything, and
understand as I go, so 1st pass is to come up with a pseudo code or
block of what I what things to do.
ie:
dns request from lan to wan = allow [all | by port | by ip | by dev]
dns reply from wan to lan = allow [all | by port | by ip | by dev]
http request from lan to wan = allow [all | by port | by ip | by dev]
http reply from wan to lan = [all | by port | by ip | by dev]
http request from wan to lan = [all | by port | by ip | by dev]
dns request from wan to lan = [all | by port | by ip | by dev]
... etc.
here is my current script(w/line numbers):
1 #!/bin/sh
2 # Set policies to drop all traffic
3 iptables -P INPUT DROP
4 iptables -P OUTPUT DROP
5 iptables -P FORWARD DROP
6 # Clear all tables so that only the above policies are in effect
7 iptables -t nat -F
8 iptables -t mangle -F
9 iptables -F
10 # Allow machine internal traffic
11 iptables -I INPUT -i lo -j ACCEPT
12 iptables -I OUTPUT -o lo -j ACCEPT
13
14 # Allow internal LAN traffic
15 iptables -I INPUT -i eth1 -j ACCEPT
16 iptables -I OUTPUT -o eth1 -j ACCEPT
17
18 #NAT
19 iptables -F -t nat
20 # I may have to uncomment the following
21 iptables -P FORWARD ACCEPT
22 iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE
23 iptables -I OUTPUT -o ppp0 -j ACCEPT
24
25
26 # using connection states:
27 # General
28 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
29 iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
30 # DNS
31 iptables -A OUTPUT -m state --state NEW -p udp --dport 53 -j ACCEPT
32 iptables -A OUTPUT -m state --state NEW -p tcp --dport 53 --syn -j ACCEPT
33 # HTTP
34 iptables -A OUTPUT -m state --state NEW -p tcp --dport 80 --syn -j ACCEPT
35 # ICMP
36 iptables -A OUTPUT -m state --state NEW -p icmp --icmp-type
echo-request -j ACCEPT
I think lines 1- 12 are probably ok, but 15 & 16 basically bypass almost
everything past them (because they jump to ACCEPT).
Before I create new iptables rules what, generically should a safe home
network firewall allow and deny? For example, I know I will have to
allow all lan machines to originate http, smtp , and dns, but should
that be done by port, originating ip, or interface? Once i have this
figured out in english, I'm sure I'll be back to have someone look at my
actual rules.
Thanks,
Bill
Juha Laiho
>I have a Linux box as my gateway/firewall/router I'll call "www1" for a
>home lan that accesses the internet via pppoe with dynamic ip.
Well, 15 and 16 depend on how safe you consider your internal machines.
As you're masquerading them, and not explicitly NATting any inbound
connection to them, I'd consider them safe if they run a proper antivirus
software (proper: includes automatic updates). Note that line 23 in the
above will allow all outbound traffic from the fw to Internet - so it
shortcuts any restrictions you attempt to create with 29-36.
Then a performance hint: the order of rules matters. Most packets will
be something matching the RELATED,ESTABLISHED rules -- so make sure
you keep those rules close to the start of the chains; the current order
is pretty good (so, first blanket allow by interface, then right next
the R,E rules).
>Before I create new iptables rules what, generically should a safe home
>network firewall allow and deny? For example, I know I will have to
>allow all lan machines to originate http, smtp , and dns, but should
>that be done by port, originating ip, or interface? Once i have this
>figured out in english, I'm sure I'll be back to have someone look at my
>actual rules.
If you don't make any distinction between the different machines within
the LAN (so, equal access to all), I'd make the rules by incoming
interface and destination port. So, f.ex. allow anything inbound from
eth1 which is destined to port 80 somewhere.
For DNS I would consider setting up a caching DNS server on the firewall
and prohibiting any direct access from the LAN to external DNS servers -
and pretty much the same for SMTP. HTTP is not quite so clear-cut, though,
but even that might make sense (to run an HTTP proxy on the fw, and disallow
any direct port connections from LAN to internet).
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
William Gill
That's the type of target mistake I was talking about in my original
post. I want to add specific restrictions to fw output. Is the best
way to accomplish this to change line 23's target to my own chain that
checks imposes closer scrutiny before jumping to accept?
If so, I'm looking at doing similar to lines 15 & 16. i.e. if to/from
lan (eth1) jump to lanrules.
So the result is:
if from wan jump to wanrules
if from localhost jump to lorules
if from lan jump to lanrules
DROP all
# wanrules
if match rule1 jump to ACCEPT
if match rule2 jump to ACCEPT
...
DROP all
# lanrules
if match rule1 jump to ACCEPT
if match rule2 jump to ACCEPT
...
DROP all
# lorules
if match rule1 jump to ACCEPT
if match rule2 jump to ACCEPT
...
DROP all
I think the DROP all at the end of each custom chain is unnecessary,
since fallthrough would eventually hit a drop, but would it improve
performance to explicitly drop at the end of each chain?
Juha Laiho
>So the result is:
>
>if from wan jump to wanrules
>if from localhost jump to lorules
>if from lan jump to lanrules
>DROP all
You could do this -- and it does make things easier in some ways.
New rule chains can be created with "iptables -N chainname".
You'd be well-advised to keep the RELATED,ESTABLISHED rules in
the common section before branching off to the subchains.
There is also some sense in building "utility chain"s - like
- logdrop (log and drop a packet)
- logreject (log and reject a packet)
to be called from each of your per-interface chains as appropriate.
Note though, when you're configured things correctly, and know
what is passing through and what is not, logging becomes less of
a concern.
># wanrules
>if match rule1 jump to ACCEPT
>if match rule2 jump to ACCEPT
>...
>DROP all
>
># lanrules
>if match rule1 jump to ACCEPT
>if match rule2 jump to ACCEPT
>...
>DROP all
>
># lorules
>if match rule1 jump to ACCEPT
>if match rule2 jump to ACCEPT
>...
>DROP all
>
>I think the DROP all at the end of each custom chain is unnecessary,
>since fallthrough would eventually hit a drop, but would it improve
>performance to explicitly drop at the end of each chain?
There's not much difference, if your main chain really only matches on
interface (and you don't have a _ton_ of interfaces). Look at the
comparisions yourself -- if the packet arrived from WAN, but didn't
match any of the rules in wanrules, it will next be checked for
whether it arrived from local interface, and then whether it arrived
from LAN interface. After that it'll be dropped. Most probably the
bulk of the time was anyway spent going through the wanrules chain.
However, if you don't drop at end of each chain, be careful with
your main chain that you don't accidentally accept something which
just fell off the end of one of the called chains. So, if a packet
doesn't match any of the rules in a user-defined chain, it will be
returned to the calling chain, and processig will continue from
the next rule in the calling chain.
Also, tune the performance for accepting and rejecting fast. Dropping
may be delayed a bit - unless you expect to be massively DDoSsed so
badly that dropping unnecessary traffic is your priority#1.
Priorities can be pretty much set by the number of packets ACCEPTed.
The more packets a single ACCEPT rule handles, the more important
the rule is -- which places the RELATED,ESTABLISHED rule very high
indeed. My preference is to first accept from '-i lo', then accept
R,E.
A sidenote about the localrules: I wouldn't limit the traffic within
the machine. Just place a rule allowing anything that arrives in the
'lo' interface - and have this along with the RELATED,ESTABLISHED
rule somewhere in the very beginning of your main chain.
About what to reject; reject in cases where DROPping a packet
delays your own operations. I've seen some SMTP servers sending
'ident' queries, also some IRC and few WWW servers do this. If
you drop the ident packet, there will be a noticeable delay until
the site lets you communicate. Thus, for your own benefit, drop
ident queries. As I prefer to keep my external interface mostly
in drop-all mode, I'm dropping the idents from only those addresses
which do affect my use -- so a random ident portknock is just
dropped.
There is also a minor benefit in splitting different protocols
in different chains, f.ex. you can have the following in INPUT
chain:
-i $EXTIF -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -m state --state NEW -j tcp-ext
So, branch to the chain that handles tcp connections from external
network only if all of the following are true:
- protocol is tcp
- the packet is a SYN packet
- the netfilter state for the connection is NEW
Then, in "tcp-ext" chain your rules become much simpler, as you
already know that all of the above conditions are met; example:
-s X.Y.Z.W -p tcp -m tcp --dport 22 -j ACCEPT
... unfortunately the '-p tcp -m tcp' cannot be omitted, as
it is the key that enables --dport keyword handling.
Whether or not to limit traffic from the machine itself to WAN/LAN is
a different issue. I tend not to do it, but have done it for a couple
of very limited-use rather security-sensitive systems; this was mostly
to avoid any operator goofing on the machine itself from setting off
any alarms on the surrounding networks.
William Gill
may take a while since right now I'm getting the supplies to make
pancakes for 60 on a cub scout weekend camping trip. As soon as I
recover I will get back to this.
Thanks,
Bill
Robert
> I have a Linux box as my gateway/firewall/router I'll call "www1" for a
> home lan that accesses the internet via pppoe with dynamic ip.
OK
> I run apache (httpd)and sendmail on www1, for local (lan) use only.
OK
> Before I create new iptables rules what, generically should a safe home
> network firewall allow and deny? For example, I know I will have to
> allow all lan machines to originate http, smtp , and dns, but should
> that be done by port, originating ip, or interface? Once i have this
> figured out in english, I'm sure I'll be back to have someone look at my
> actual rules.
OK, while the advice you were receiving is good you don't really need the
OUTPUT rules unless you are going to be doing things from the firewall
it's self. You will however require one OUTPUT rule for MASQUERADE.
Not sure about your firewall setup in regards to how you access it. If
you have a keyboard and monitor hooked up then the following rule set will
work. It you have to telnet to it then I would suggest that you add a
rule to allow ssh into your firewall from the LAN side only.
Here is what I configured for you. I like to break things down into
interfaces as it makes keeping things in order a lot easier. Any traffic
you want to pass from the LAN side you will have to edit these rules and
add them to the LAN setup.
You will notice that I only have 2 OUTPUT rule listed. This is because I
don't know what you will need to do from the firewall box itself.
Some would say I really don't need the DROP rules in each chain, but I
feel safer this way. Keeps everything locked down. Better safe then
sorry.
Should you have any questions feel free to ask.
-----cut here-----
#!/bin/sh
# Clear all Firewall Policies
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
# Zero all Firewall Policies
iptables -Z INPUT
iptables -Z OUTPUT
iptables -Z FORWARD
# Set Default Policies
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD ACCEPT
# Load all Modules
#
# Only needed if you are going to allow ftp and irc through the firewall for tracking
#
#/sbin/modprobe ip_conntrack_ftp
#/sbin/modprobe ip_conntrack_irc
# Allow loopback traffic
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Forward setup to jump to correct chain
iptables -A FORWARD -i eth1 -j LAN
iptables -A FORWARD -i ppp0 -j WAN
# WAN Chain: We allow no new outside connections
iptables -A WAN -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A WAN -j DROP
#LAN Chain: WE allow only traffic to pass that we want
iptables -A LAN -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A LAN -p tcp --dport 25 -j ACCEPT
iptables -A LAN -p tcp --dport 110 -j ACCEPT
iptables -A LAN -p tcp --dprot 80 -j ACCEPT
iptables -A LAN -p tcp --dprot 443 -j ACCEPT
iptables -A LAN -p udp --dport 53 -j ACCEPT
iptables -A LAN -p icmp --icmp-type 0 -j ACCEPT
iptables -j DROP
# Post routing Masquerading
iptables -A POSTROUTING -o ppp0 -j MASQUERADE
# OUTPUT Chain to allow replies to the LAN only
iptables -A OUTPUT -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -j DROP
-----End cut-----
--
Regards
Robert
Smile... it increases your face value!
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
William Gill
I assume that if I need to work with the firewall box, I could add:
iptables -A INPUT -i eth1 -j LAN
I'm a little confused about
/sbin/modprobe ip_conntrack_ftp
since my ftp seems to work w/o it?
Thanks,
Bill
Tauno Voipio
> These look good, and are similar to my draft script, but much clearer. I
> assume that if I need to work with the firewall box, I could add:
>
> iptables -A INPUT -i eth1 -j LAN
>
> I'm a little confused about
> /sbin/modprobe ip_conntrack_ftp
> since my ftp seems to work w/o it?
The module enables the FTP server to open a data connection
to your computer.
If your client is using passive mode which opens all connections
from the client, an ESTABLISHED,RELATED pass rule suffices.
HTH
--
Tauno Voipio
tauno voipio (at) iki fi
William Gill
Bill
Robert
> These look good, and are similar to my draft script, but much clearer.
And easier to follow. <g>
> I assume that if I need to work with the firewall box, I could add:
>
> iptables -A INPUT -i eth1 -j LAN
No. You will have to add an INPUT statement. the -j LAN is for FORWARD
only. Forward is only passing the packet to LAN to test is it is OK to
Forward the packet on.
Anything that is going to end at the router will need an INPUT statement
like this:
iptables -A INPUT -i eth1 -j ACCEPT
> I'm a little confused about
> /sbin/modprobe ip_conntrack_ftp
> since my ftp seems to work w/o it?
It all depends on how your client is making FTP connection. If you only
use passive mode then you might not need this.