On 2007-10-27 Telly Williams wrote: > -A INPUT -p tcp -j bad_tcp > -A INPUT -p tcp -f -j Fragment > -A INPUT -p tcp -m iprange --src-range 10.0.0.0-10.255.255.255 -j Spoofs > -A INPUT -p tcp -m iprange --src-range 172.16.0.0-172.31.255.255 -j Spoofs > -A INPUT -p tcp -m iprange --src-range 192.168.0.0-192.168.255.255 -j Spoofs > -A INPUT -p tcp -m iprange --src-range 169.254.0.0-169.254.255.255 -j Spoofs
You don't need the iprange module for this, but you most definitely want these rules to apply to *all* IP packets, not just to TCP. iptables -A INPUT -s 10.0.0.0/8 -j Spoofs iptables -A INPUT -s 172.16.0.0/12 -j Spoofs iptables -A INPUT -s 192.168.0.0/16 -j Spoofs iptables -A INPUT -s 169.254.0.0/16 -j Spoofs Depending on your infrastructure you may also want to specify the input interface here. > -A INPUT -s 127.0.0.1 -i lo -j ACCEPT > -A INPUT -s XX.XXX.XXX.XXX -i lo -j ACCEPT No other source address than 127.0.0.1/8 is supposed to appear at the loopback interface. iptables -A INPUT -i lo -s 127.0.0.1/8 -j ACCEPT [...] > -A INPUT -d XX.XXX.XXX.XXX -m state --state RELATED,ESTABLISHED -j ACCEPT It's rather pointless to discriminate this rule by destination IP, because it's traffic that belongs to an already established connection (i.e. you already accepted traffic for this). Also you should allow ESTABLISHED,RELATED traffic in the other chains as well: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT You can omit the last one if you're not forwarding packets. > -A INPUT -i eth1 -p tcp -j tcp_packets > -A INPUT -i eth1 -p udp -j udp_packets > -A INPUT -i eth1 -p icmp -j icmp_packets Defining one chain per protocol and do all the packet handling there may work for ICMP, but for TCP and UDP it's probably not the best of ideas, because with these protocols a packet in the INPUT chain usually needs other rules than a packet in the OUTPUT (or FORWARD) chain. > -A INPUT -p tcp -m multiport --sports ! 8002 -m limit --limit 6/min > --limit-burst 6 -j LOG --log-prefix "INPUT pkt dead: " --log-level 7 Since you specified only one port you don't need the multiport module here. [...] > -A OUTPUT -s XX.XX.XXX.XXX -j ACCEPT Why are you ACCEPTing traffic based on the source address? For new outbound connections you should ACCEPT based on destination and state NEW, for everything else, you should use an ESTABLISHED,RELATED rule just like you do in the INPUT chain. [...] > -A icmp_packets -p icmp -m icmp --icmp-type 8 -j DROP > -A icmp_packets -p icmp -m icmp --icmp-type 11 -j DROP > # With the above two rules, I thought it put me in stealth > # mode(?). Repeating myself: "stealth" is braindead marketing babble invented by people who failed to understand TCP/IP for people who fail to understand TCP/IP. Your host doesn't magically become "invisible" just because it drops packets. TCP/IP doesn't work that way. Besides, you shouldn't be dropping echo-request and time-exceeded. ICMP is a vital part of IP and required e.g. for troubleshooting connection problems. Rather do something like this: iptables -N icmp_packets # Allow ping, but limit it to 10 requests per second: iptables -A icmp_packets -p icmp --icmp-type echo-request \ -m state --state NEW -m limit --limit 10/sec -j ACCEPT # Allow echo replies (pong) for accepted pings: iptables -A icmp_packets -p icmp --icmp-type echo-reply \ -m state --state ESTABLISHED -j ACCEPT # Allow troubleshooting messages for all established connections: iptables -A icmp_packets -p icmp --icmp-type destination-unreachable \ -m state --state RELATED -j ACCEPT iptables -A icmp_packets -p icmp --icmp-type source-quench \ -m state --state RELATED -j ACCEPT iptables -A icmp_packets -p icmp --icmp-type time-exceeded \ -m state --state RELATED -j ACCEPT iptables -A icmp_packets -p icmp --icmp-type parameter-problem \ -m state --state RELATED -j ACCEPT iptables -A icmp_packets -j DROP I'd also recommend to REJECT packets rather than simply DROP them, so I usually define a DENY chain and put it at the end of the INPUT, OUTPUT and FORWARD chains: iptables -N DENY iptables -A DENY -p tcp -m limit --limit 10/sec -j REJECT \ --reject-with tcp-reset iptables -A DENY -p udp -m limit --limit 10/sec -j REJECT \ --reject-with icmp-port-unreachable iptables -A DENY -j DROP > -A tcp_packets -p tcp -m tcp --dport 80 -j allowed > -A tcp_packets -p tcp -m tcp --dport 443 -m comment --comment "HTTPS" -j > allowed > -A tcp_packets -p tcp -m tcp --dport 25 -j allowed > -A tcp_packets -p tcp -m tcp --sport 123 -m comment --comment "NTP" -j > allowed Why are you ACCEPTing NTP packets based on the source port? Unlike not being "stealth" this can be an actual security breach in your firewall. ACCEPT NEW NTP connections in the appropriate chain (depending on whether you want to allow inbound or outbound NTP), the rest is covered by your ESTABLISHED,RELATED rules. [...] > -A udp_packets -i eth1 -p udp -m udp --sport 67:68 --dport 67:68 -m comment > --comment "DHCP Purposes" -j ACCEPT [...] > -A udp_packets -p udp -m udp --sport 123 -m comment --comment "NTP" -j ACCEPT Same with these. Regards Ansgar Wiechers -- "The Mac OS X kernel should never panic because, when it does, it seriously inconveniences the user." --http://developer.apple.com/technotes/tn2004/tn2118.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]