Re: [tor-relays] Detecting Network Attack [re: exit synflooded]

[Igor Mitrofanov <igor.n.mitrofanov@xxxxxxxxx>]

Do not enable net.ipv4.tcp_tw_recycle:
https://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux#netipv4tcp_tw_recycle

For ip_local_port_range, make one number even and the other one odd
(i.e. 1024 and 65535). Not sure if this is still required, but won't
hurt to include port 1024.

Consider blacklisting the nf_conntrack module altogether and running a
completely stateless firewall:
https://javapipe.com/ddos/blog/iptables-ddos-protection/
https://strongarm.io/blog/linux-stateless-firewall/

On Sat, Nov 25, 2017 at 3:14 PM, Dhalgren Tor <dhalgren.tor@xxxxxxxxx> wrote:
>>Well, it's still going on, and is pretty much ruining Libero :( .  Running CentOS 6, here.
>>
>>When it's happening it can look like this:
>>
>># netstat -n | grep -c SYN
>>17696
>
> I run a fast exit and can offer some advice:
>
> 1) mitigate bug #18580 (also #21394); is a DNS denial-of-service and
> could be the problem.  either upgrade to 0.3.2.4+ or edit resolve.conf
> per https://trac.torproject.org/projects/tor/wiki/doc/DnsResolver#TuningeventdnscomponentofTorDaemon
>
> also check out https://arthuredelstein.net/exits/
>
> 2) if you continue to experience excessive outbound scanning SYNs,
> I've found that simply enabling connection tracking helps by
> implicitly limiting the rate a which connections can originate.  If an
> iptables "-m state --state ESTABLISHED,RELATED -j ACCEPT" rule exists
> it will turn it on or you could modprobe the module if you don't want
> to configure incoming connection rules.
>
> some useful sysctl.conf changes, run sysctl -p after or reboot
>
> # Tor Exit tuning.
> net.ipv4.ip_local_port_range = 1025 65535
> net.ipv4.tcp_synack_retries = 2
> net.ipv4.tcp_max_tw_buckets = 4194304
> net.ipv4.tcp_tw_recycle = 1
> net.ipv4.tcp_fin_timeout = 30
> net.ipv4.tcp_keepalive_time = 300
> net.ipv4.tcp_keepalive_intvl = 10
> net.ipv4.tcp_keepalive_probes = 3
> net.netfilter.nf_conntrack_tcp_timeout_established = 1000
> net.netfilter.nf_conntrack_checksum = 0
>
> you might see many messages:
>
> kernel: nf_conntrack: table full, dropping packet
>
> which indicates no connection table slots were available for an
> outbound connection and that rate limiting is effected
>
> state of connection tracking appears in /proc/net/nf_conntrack
> _______________________________________________
> tor-relays mailing list
> tor-relays@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays