Or you simply block port 22 and everyone everyone lived happily ever after.
I do not care about a script kiddie trying to hack something. Bots are what I am afraid of, you get the same abuse over and over and over. Markus 2016-10-06 6:43 GMT+02:00 Green Dream <greendream...@gmail.com>: >>> > for i in subdir/*; do ssh host mkdir -p "$i"; done >>> > >>> > with an ssh-agent would look pretty exactly the same to the exit node. >>> >>> OK, so I left out the "Permission denied, please try again." bits :) >> >> The exit node doesn't see that - that's the point of ssh. It can >> at best look at the session length and timing and infer flakily >> from that. > > > Exactly. There isn't a 100% effective way to accurately filter out > "bad ssh" on the wire. It's a good example of where intrusion > prevention systems fail. > > I worked at a public university where Bro (https://www.bro.org/) was > in use. One of the enabled rules was for ssh brute-force / > failed-login. It was mostly false positives. Bro was flagging > legitimate ssh traffic. Turns out Bro is notorious for this (ref: > http://mailman.icsi.berkeley.edu/pipermail/bro/2013-September/006026.html > and many other similar posts). > > I've also worked with Snort and Cisco and Palo Alto IPS/IDS systems, > and I've come to hate all of them for a couple of reasons: > > 1) The rulesets are finicky, always in flux, highly variant between > vendors, and wildly inaccurate. > > 2) At the end of the day they are just tools for censorship. > > The way these systems work: the admin is presented with an assortment > of rulesets, usually broadly categorized, and you just go through and > start checking off boxes with labels like "adult content", "violence", > "hacking", "tor", or if you're using an open source variant it may be > a bit more refined like "ssh brute force", "syn flood", "tcp scan", > etc. > > At the end of the day though someone is just checking off boxes. The > underlying regex applied to packets may or may not have even been > looked at. > > Multiply that chaos by the number of Tor exit operators who might > implement such a thing. Think about the different experience levels of > operators too; how many would know that the Bro rule for ssh was > mostly going to block legitimate ssh traffic? > > We have technical and highly qualified Exit operators who could > install an IPS, sure. But we have others fairly new to being > sysadmins. > > One other huge problem -- where there's IPS there are IPS logs. Every > IPS tool I know of has an option to log, and they're all going to log > by default. That's bad. I'd vote BadExit flag (if I had a vote, ha). > There's too much metadata that this would leave behind, and it may > open up the operator to legal liabilities. > _______________________________________________ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
