[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: How to Run High Capacity Tor Relays



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