Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata

[Mirimir <mirimir@xxxxxxxxxx>]

On 10/05/2016 10:43 PM, Green Dream wrote:
>>>>   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.

Oh :(

> 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).

Actually, that thread concerns Bro notifications that are, in the
context of this discussion, false negatives. That is, OP was concerned
about a successful SSH login reported by Bro. And the tentative
conclusion was:

| Right, if the ssh connection's response bytes are above this
| threshold it'll log the session as having a successful login. If
| you have a large pre-auth login banner (usually for compliance
| reasons) it will very likely report as a false positive.

So maybe Bro can be tuned to flag failed logins reliably. Also, a few
failed logins doesn't matter. It's rapid-fire failed logins from the
same IP that need to be blocked.

More generally, it seems doable to block all sorts of automated activity
in ways that don't impact Tor project's target userbase. If someone
wants to scrape stuff, they can bloody well learn how to do it in ways
that don't burn down exit relays.

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

Some of the rules are censorship, certainly. But I can't imagine how
it's censorship to block SSH brute force attacks.

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