Nicolas Boullis <[EMAIL PROTECTED]> writes: [snip] >> # Drop spoofed packets >> iptables -A INPUT -i eth0 -j DROP -s 192.168.1.3 -d 0.0.0.0/0
What about outgoing spoofed packets? They didn't get dropped in this script at all. It's only a selfish half-hearted firewall if all it does is to protect yourself against incoming nasties; there's always a responsibility not to inflict dodgy packets on others, as much as possible. >> # let ICMP in and out >> iptables -A OUTPUT -o eth0 -j ACCEPT -p ICMP >> iptables -A INPUT -i eth0 -j ACCEPT -p ICMP This is folly. At the very least, rate-limit the outgoing chain, e.g.: | iptables -A OUTPUT -p icmp -m limit \ | --limit 5/s --limit-burst 10 \ | -j ACCEPT | iptables -A OUTPUT -p icmp -j outlog | | iptables -A OUTPUT -p udp -m limit \ | --limit 10/s --limit-burst 20 \ | -j ACCEPT | iptables -A OUTPUT -p udp -j outlog otherwise there's potential for being used as an amplifier in a (D)DoS attack. >> iptables -A INPUT -i eth0 -j ACCEPT -p TCP -s 0.0.0.0/0 --source-port >> domain #53 >> iptables -A INPUT -i eth0 -j ACCEPT -p UDP -s 0.0.0.0/0 --source-port >> domain #53 "Hey! I'm a nice port, let me in!". Oops. > Well, this ruleset looks realy dangerous to me since (unless I'm missing > something obvious) you allow any machine to connect to any of your ports > as soon as the connection is coming from ports 22 or 53. You should much > better use connection tracking. Agreed, most definitely. Connection-tracking adds more dimensions to the question "did I really ask for this?". And not only were the source-ports used as criteria for passing input packets, but the source-port is the *sole* criterion. What happens to packets with zany flags (SYN+FIN, or various christmas-tree combinations) set, from sport 22 to dport 22? They waltz right on in, and can be used for remote OS fingerprinting as well! Yow. > You should add the rule: > > $IPTABLES -A INPUT -j ACCEPT -i eth0 -m state --state ESTABLISHED,RELATED > > and then remove the explicit rules for answers... Definitely. But more to the point, I'm not fussed on the layout of the above script anyway. It might not be suited to all, but I suggest a look at the comments in <http://stirfried.vegetable.org.uk/packages/secure/iptables.sh> might be in order. Note the order in which what things are done. ~Tim -- <http://spodzone.org.uk/>
