Thus spake Mike Perry (mikeperry@xxxxxxxxxx): > > > net.netfilter.nf_conntrack_tcp_timeout_established=7200 > > > net.netfilter.nf_conntrack_checksum=0 > > > net.netfilter.nf_conntrack_max=131072 > > > net.netfilter.nf_conntrack_tcp_timeout_syn_sent=15 > > > > ^- best to just disable conntrack altogether if you can. -J NOTRACK in > > the raw table as appropriate. > > you're going to each up lots of memory with a decent nf|ip_conntrack_max > > ( check /proc/sys/net/ipv4/netfilter/ip_conntrack_max , etc ) > > Will this remove the ability to do PREROUTING DNAT rules? I know a lot > of Tor nodes forward ports and even IPs around. > > Good suggestion though. Perhaps we should mention both options in the > final draft. Actually, I learned the hard way that if you ACCEPT RELATED,ESTABLISHED in your iptables rules, you also need conntrack, otherwise your box will accept no data. It should have been obvious in retrospect, I guess. Do you have suggestions on how to rewrite firewall rules without using RELATED,ESTABLISHED? My primary goal is to prevent access to other ports, which I believe can be done with: iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST SYN -j DROP However, this obviously doesn't cover udp. Also, my secondary goal is to slow down port scanning of the machine. I'm guessing a simple SYN filter rule like this might still allow other scan types to work without issue. What else can be done to eliminate those? -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgpZFbVUnSnwP.pgp
Description: PGP signature