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

> From: igor.n.mitrofa...@gmail.com > Sorry for the spam. One more link to a tuning guide that I have found Contributions are good but since we're on the same list how about trimming quoted messages? ___ tor-relays mailing list

Re: [tor-relays] Pretty sure our exit was being synflooded

> On 27 Nov 2017, at 03:59, t...@t-3.net wrote: > > I spoke too soon, it seems - the exit is struggling again, with some time > spent destroyed today. > > As I look at what it's doing, it's clear that someone is relaying SYN packets It's not possible for Tor clients to relay SYN packets: a

Re: [tor-relays] Pretty sure our exit was being synflooded

I spoke too soon, it seems - the exit is struggling again, with some time spent destroyed today. As I look at what it's doing, it's clear that someone is relaying SYN packets to random ports and also random destination addresses that aren't even alive. The destination hosts and ports

Re: [tor-relays] Pretty sure our exit was being synflooded

> On 26 Nov 2017, at 21:06, t...@t-3.net wrote: > > Thanks for the configuration suggestions. I intentionally set the conntrack > limit high, maybe that was not the best thing. I think I'll be putting it > back. > > Removing my extra IPTables code plus adding a reject for : has made the

Re: [tor-relays] Pretty sure our exit was being synflooded

Thanks for the configuration suggestions. I intentionally set the conntrack limit high, maybe that was not the best thing. I think I'll be putting it back. Removing my extra IPTables code plus adding a reject for : has made the exit behave properly again. I wonder if the best possible

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

On Sat, Nov 25, 2017 at 5:15 PM, teor wrote: > need a privacy-preserving aggregation scheme > (Otherwise, anyone who can remotely trigger a rare protocol > violation can find out which relays a client or onion service is using.) The above don't necessarily lead to each

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

> kernel: nf_conntrack: table full, dropping packet If rules are dropping exit traffic based on other than traffic content, it's very hard to say other users are not adversly affected with the same, likely quite unsophisticated, hammer. And doing it based on content usually comes with major legal