also sprach Nicolas KOWALSKI <niko@xxxxxxxxxxxxxxxxx> [2008.04.04.1359 +0200]: > > also sprach Nicolas KOWALSKI <niko@xxxxxxxxxxxxxxxxx> [2008.04.04.1057 +0200]: > >> -A INPUT -s ::/0 -d ::/0 -m state --state RELATED,ESTABLISHED -j ACCEPT > >> -A INPUT -s ::/0 -d ff01::/32 -j ACCEPT > >> -A INPUT -s ::/0 -d ff02::/32 -j ACCEPT > >> -A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j LOG > >> -A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j DROP > > > > Why do you treat multicast special before INVALID? > > These rules matched the router sollicitation packets, apparently. I > will reorder the ICMPv6 ACCEPT rule before INVALID. I read in another email to this thread that conntrack does not involved multicast (yet), so you're right. > >> -A INPUT -s 2001:6f8:3f1::/48 -d ::/0 -i eth0 -j ACCEPT > > > > Source-authenticated rules *can* be exploited. > > Even with the '-i eth0' ? > > Well, I will remove this also. Sure, if they are on the inside. 70% of the attacks come from the inside in companies. Of course, if this is a home network, the issue (and security requirements) are different. > >> -A INPUT -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT > >> -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 22 -j ACCEPT > > > > You probably want --syn in there too. > > ESTABLISHED,RElATED connections are matched before, so at this point > these can only be new sessions, and so I did not feel it was necessary > to add more checks. I will correct this. NEW just means that conntrack does not know about the connection. --syn means that the SYN flag is set. They *should* be the same, and if INVALID worked right, then you would never see non-syn flags at this point, but they do have different meanings. Ideally, however, --syn is no longer needed if you do -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -m state --state INVALID -j DROP -A INPUT -m state --state NEW -j in-new -A in-new -p tcp --dport 22 -j ACCEPT [...] -A INPUT -j log-and-drop I /think/ this is the correct way to write iptables rules, but please correct me if I am wrong, anyone! > -A INPUT -s ::/0 -d ::/0 -i lo -j ACCEPT > -A INPUT -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT > -A INPUT -s ::/0 -d ::/0 -m state --state RELATED,ESTABLISHED -j ACCEPT Now make sure that your hosts don't honour redirects. I actually don't think passing *all* ICMPv6 is a good idea. Do read the RFC (see followup thread). > -A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j LOG > -A INPUT -s ::/0 -d ::/0 -m state --state INVALID -j DROP (might not want to log this, actually. who cares?) > -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT > -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT > -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT > -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT > -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 465 -m state --state NEW -j ACCEPT > -A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 993 -m state --state NEW -j ACCEPT note how I simplify the rules with the in-new chain... > -A FORWARD -s ::/0 -d 2001:6f8:3f1::/48 -i sixxs -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT > -A FORWARD -s 2001:6f8:3f1::/48 -d ::/0 -i eth0 -o sixxs -j ACCEPT In an ideal world, the addresses shouldn't be needed because the routing tables should ensure that no other peers could be routed through the interfaces you specify, but I am still not sure about this... -- martin | http://madduck.net/ | http://two.sentenc.es/ obviously i was either onto something, or on something. -- larry wall on the creation of perl spamtraps: madduck.bogus@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
