[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

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.


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


# 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: