Hi, On Sat, May 27, 2006 at 02:50:13PM +0200, Pascal Hambourg wrote: > >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. Yeah, but that's not an option for me. I want the script to be usable anywhere (i.e. it should not depend on the distribution, configuration, kernel version, as much as possible)... Neither should any external config files be required, the single fw_laptop script must contain everything I need. > >(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... Yes, I'll read the docs (and source, as the docs aren't _really_ useful all that much). However, I think it's safe (for my purposes) to simply set the options for _all_ interfaces. My script is interface-independent anyways, and I actually _want_ it to affect all interfaces... This is of course not an option if you have multiple interfaces which need different settings... > [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. Hm, ok, I'll have to put more thought (and time) into this for further restricting ICMP. For now, I'll allow ESTABLISHED,RELATED, and an additional Parameter Problem. Later, I'll split out ICMP and handle that extra, I think. > 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. Added a comment to the script, thanks. > It won't protect you completely from spoofing because spoofing can use > non reserved addresses. Sure, that's obvious. But it blocks _some_ forms of spoofing, so why not adding it... > 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. Hm, ok, I think it's reasonable to block ALL those IP blocks from my script per default, but add a comment that if you experience problems, you should comment all lines except for the link-local block. > >$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. OK, that I would consider a feature, not a bug ;) I _do_ want to prevent "malicious" outgoing traffic, as it could come from malicious local users/applications. I'll add a comment that you should disable this line if you want to perform certain scans, though. > 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, thanks. I use DROP explicitly now, but added a comment which explains the above. > 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 That's not an option, as everything should be in one single script. I'm thinking of using something along these lines: if test -x $IP6TABLES; then # Delete all rules. $IP6TABLES -F $IP6TABLES -t mangle -F # Delete all (non-builtin) user-defined chains. $IP6TABLES -X $IP6TABLES -t mangle -X # Zero all packet and byte counters. $IP6TABLES -Z $IP6TABLES -t mangle -Z # Set the default policies (drop everything). $IP6TABLES -P INPUT DROP $IP6TABLES -P FORWARD DROP $IP6TABLES -P OUTPUT DROP # The mangle table can pass everything through unaltered (we don't use it). $IP6TABLES -t mangle -P PREROUTING ACCEPT $IP6TABLES -t mangle -P INPUT ACCEPT $IP6TABLES -t mangle -P FORWARD ACCEPT $IP6TABLES -t mangle -P OUTPUT ACCEPT $IP6TABLES -t mangle -P POSTROUTING ACCEPT fi (IPv6 doesn't have NAT, right?) The intention is to block any IPv6 traffic (if there's IPv6 support in the kernel), otherwise do nothing as there's no IPv6, hence no such traffic is possible. Does that look reasonable and complete? An "rmmod ip6tables" etc. sounds nice, too, but that would only work if it's compiled as a module, so I think the above is better. > >$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. Will this suffice? $IPTABLES -t nat -P PREROUTING ACCEPT $IPTABLES -t nat -P OUTPUT ACCEPT $IPTABLES -t nat -P POSTROUTING ACCEPT $IPTABLES -t mangle -P PREROUTING ACCEPT $IPTABLES -t mangle -P INPUT ACCEPT $IPTABLES -t mangle -P FORWARD ACCEPT $IPTABLES -t mangle -P OUTPUT ACCEPT $IPTABLES -t mangle -P POSTROUTING ACCEPT $IPTABLES -t raw -P PREROUTING ACCEPT $IPTABLES -t raw -P OUTPUT ACCEPT > >$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 Yeah, I noticed. Really fixed it this time... I'll post the updated script here soon, after I added some more things. Cheers, Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org
Attachment:
signature.asc
Description: Digital signature