Hi, On Mon, Feb 26, 2018 at 11:32:26AM +0000, Kim Minh Kaplan wrote:> TL;DR: please try the patch out and report if it causes "Did not receive > identification string" log messages. I believe it does not.It depends on absolute RTT to the target. If you stay local ("< 50ms"), the 250ms offset should reliably avoid DNIS logs. If you happen to connect to Australia from Europe ("200+ms RTT") the second SYN might go out before the first handshake is done... but that should be a somewhat rare occurrence. gert -- now what should I write here... Gert Doering - Munich, Germany gert at greenie.muc.de
Gert Doering writes:> Hi, > > On Mon, Feb 26, 2018 at 11:32:26AM +0000, Kim Minh Kaplan wrote: >> TL;DR: please try the patch out and report if it causes "Did not receive >> identification string" log messages. I believe it does not. > > It depends on absolute RTT to the target. If you stay local ("< 50ms"), > the 250ms offset should reliably avoid DNIS logs.Agreed.> If you happen to > connect to Australia from Europe ("200+ms RTT") the second SYN might > go out before the first handshake is done... but that should be > a somewhat rare occurrence.Yes, but I claim that even when an other SYN is sent, it will not trigger the DNRIS log. Kim Minh.
>>> TL;DR: please try the patch out and report if it causes "Did not receive >>> identification string" log messages. I believe it does not.Aw crap. My homegrown anti-dos tool for ssh looks for either DNRIS or if logging is verbose enough a connection that didn't result in a login. I give the attacker a few tries and whitelist any successful candidate so I should be ok, but things are getting a bit riskier. I'm a big fan of happy eyeballs in general so I hope there is some way to allow happy eyeballs and still stop bots from repeatedly knocking on the door wasting cpu time. Simplest would be to never abort the extra happy eyeballs before actually logging in or the normal ssh connection timeout. There may be other ways to accomplish the same thing. -wolfgang