How to Run High Capacity Tor Relays

[tor_ml]

> 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

example:
if you had this ruleset _using_ conntrack:

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate NEW -m multiport -p tcp --dports 22,443 
-j ACCEPT
-A INPUT -j DROP
(I assume OUTPUT is unfiltered [ACCEPT])

I would rewrite it to the following if you have to _omit_ connection 
tracking and want to have unfiltered outbound traffic

-A INPUT -m multiport -p tcp --dports 22,443 -j ACCEPT
-A INPUT -p tcp --syn -j DROP (this is the short equivalent to your rule)
(INPUT policy is ACCEPT)

regarding udp rules: it depends on your udp needs and DNS settings.

> 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?

I'm not sure why would you want to do that, as this gives no additional 
security, but if you want to block FIN and XMAS scan without connection 
tracking:

-A INPUT -p tcp --tcp-flags ALL FIN -m comment --comment "FIN Scan 
filtering" -j DROP

-A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -m comment --comment "XMAS 
Scan filtering" -j DROP

If you filter XMAS and FIN scans, nmap (-sX -sF) scans will always 
result in open|filtered regardles of their real state and the scan will 
take longer.

These rules are tested and triggered with nmap -sF/-sX
wrote also a rule for null scan (-sN) but didn't see any effect on scan 
time.