Re: Request for comments: iptables script for use on laptops.
Uwe Hermann a écrit :
# Enable IP spoofing protection (i.e. source address verification).
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
Incomplete. The function is enabled on interface $INTERFACE when both
net/ipv4/conf/all/rp_filter *and* net/ipv4/conf/$INTERFACE/rp_filter are
set to 1 (logical AND).
[...]
Interesting. The naming of "all" is a bit misleading then...
I fixed the script to use the following now, which should be sufficient:
for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i; done
That's what does the Debian networking startup script when
/etc/network/options (now deprecated) contains rp_filter=1.
(I did the same for all other lines which used .../all/...)
Well, you'd better read the description of each kernel parameter before
doing so, because all don't follow the logical AND rule. Yeah, it's
tricky...
[ICMP]
General question: which types are usually required or should at least
be enabled in order to not cause network problems, delays, etc.?
Here are the ICMP types that I allow :
- Echo Request and Reply (useful for debugging)
- Destination Unreachable
- Time Exceeded
- Parameter Problem
I used to allow Source Quench but not any more after some flaws were
found on some OSes and I learnt it could be abused to slow down connections.
Is there anything I need to allow explicitly, or does the
ACCEPT of established/related traffic suffice?
A general "-m state --state ESTABLISHED,RELATED -j ACCEPT" allows Echo
Reply, Destination Unreachable and Parameter Problem. But it also allows
other RELATED ICMP types that may be undesirable, such as Source Quench
or Redirect. That's why I don't include RELATED in such general rule.
Instead I split by state, protocol and type.
Warning :
In 2.4 kernels older than 2.4.29, some locally generated (going through
the OUTPUT chain) ICMP error types are incorrectly tagged INVALID
instead of RELATED.
#------------------------------------------------------------------------------
# Drop any traffic from IANA-reserved IPs.
[...]
I can live with the fact that the list needs updating. And as the script
is intended for my laptop mainly, I will probably notice and fix any major
problems (e.g. blocked legitimate traffic) quite fast.
Apart from that, does it make sense to block such traffic? It'll be
mostly bogus/spoofed anyways, I guess, that's why I want it blocked.
Or should I just remove the whole paragraph and forget about it?
Well, I can only give my own opinion, not advice.
It won't protect you completely from spoofing because spoofing can use
non reserved addresses. Also, some ISP use private addresses per RFC
1918 in their networks. If yours does, you'd better not drop them if you
don't want to see "holes" in traceroute or block some ICMP error
messages. So I only drop address that should really not arrive from the
internet such as the link-local block.
[...]
There's no reason to allow INVALID traffic, right?
My first answer would be no, but for now I have no definitive answer.
I added this new rule:
$IPTABLES -A INPUT -m state --state INVALID -j DROP
Do similar rules for OUTPUT and FORWARD make sense?
OUTPUT : see my warning above about locally generated ICMP error
messages and older 2.4 kernels.
Also, such rule could prevent you from sending invalid packets on
purpose e.g. for some types of TCP scans.
FORWARD : if you disabled IP forwarding, you do not have to care about
it. A plain default policy set to DROP and no rule will do. I guess you
don't use any NAT either. If you did you might need to block INVALID
packets because they by-pass the NAT rules.
OK, fixed. I'm using REJECT/REJECTLOG everywhere now, and I added a line
at the beginning which explicitly DROPs everything in state INVALID
(see above).
Thanks a lot for your comments, that was very helpful! I added your name
and email address in the script. Let me know in case you want them
removed...
No problem, you're welcome.
One other question: should I block all IPv6 traffic (how?); I have
exactly zero experience with IPv6, and don't use it knowingly.
Can it still become a problem, i.e. do all the rules I set above
also apply to IPv6 traffic (in case it's possible, say when I'm at some
place with my laptop which allows IPv6)?
In other words, could the firewall be circumvented by just sending IPv6
traffic instead of IPv4? If so, how can I reliably prevent that?
Iptables rules apply only to IPv4 traffic. You need ip6tables to filter
IPv6 traffic. Or you can completely disable IPv6 by either not loading
the ipv6 module if compiled as a module, or by writing or uncommenting
the following line in /etc/modules.conf :
alias net-pf-10 off # IPv6
Btw, the fixed script (with some new stuff, too) is attached. If I
screwed up somewhere, please let me know.
[...]
#------------------------------------------------------------------------------
# Default policies: drop everything.
#------------------------------------------------------------------------------
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP
If you want to be complete, you should also set the defaut policy of
built-in chains in tables nat and mangle to ACCEPT, or unload these
tables if built as modules (iptable_nat and iptable_mangle) and not
needed at all.
[...]
# Drop SMB, CIFS, and related Windows traffic without logging. We don't care.
# TODO: I think not all of these use TCP _and_ UDP. Tighten the rules!
$IPTABLES -A INPUT -p tcp -m multiport \
--sports 135,137,138,139,445,1433,1434 -j DROP
$IPTABLES -A INPUT -p udp -m multiport \
--sports 135,137,138,139,445,1433,1434 -j DROP
--dports
# Explicitly drop invalid traffic.
# TODO: Do the same for OUTPUT and FORWARD?
$IPTABLES -A INPUT -m state --state INVALID -j DROP
You could DROPLOG instead of just DROP. Your choice.
Reply to: