Dealing with automated SSH password-guessing

Posted Oct 25, 2016 14:34 UTC (Tue) by marcH (subscriber, #57642)
In reply to: Dealing with automated SSH password-guessing by zev
Parent article: Dealing with automated SSH password-guessing

> > (Everything should support rate-limiting nowadays)

> O(n) things (applications) instead of O(1) things?

Not "instead": everywhere.

1. In an ideal world, all applications should provide (optional) application-specific rate limiting knobs to the sysadmin. Typically: *per-user* quotas. Common code - to measure network traffic for instance - can be in shared libraries.
Try abusing some Google or Amazon cloud service just a bit and see what happens.

2. If desired again by the sysadmin, rate limits can also be set at the network level; but in an application independent / port independent / simpler manner.

The hack/"optimization" above is having application-specific rate-limiting implemented at the network level. One symptom it is a hack is seeing the port number duplicated in both layers.

This firewall discussion happened already many times - on this site and others.
https://lwn.net/Articles/596156/ is hopefully the most complete example.

Back to the main topic: if proven it's sad to see a fundamental security tool not considering rate limiting.

Dealing with automated SSH password-guessing

Posted Oct 26, 2016 8:08 UTC (Wed) by NightMonkey (subscriber, #23051) [Link] (4 responses)

That is certainly not the *NIX way. :)

Dealing with automated SSH password-guessing

Posted Oct 26, 2016 10:50 UTC (Wed) by MarcB (subscriber, #101804) [Link] (3 responses)

It's not about Unix ways, it's about fundamental networking principles, notably the end-to-end principle.

The way firewalling has evolved in the last decades has gone horribly wrong. More and more functionality that does not belong there has been moved into the firewall and kernel or even into external firewall boxes. Commercial vendors at least got an "excuse" for that: They need to compete in the feature space to impress decision makers. The technical staff will then turn most of the features off anyway, at least after the first disaster.
Open source developers somehow also felt the need to get into this race. Additionally, in Linux, pushing everything into the kernel seemed - and still seems - acceptable. The BSDs also do that, but to a lesser degree. They got more functionality in userspace daemons.

At this point, it is possible to trigger a DoS on a very busy Linux system simply by running iptables -L (which is naively assumed to never change any state), because that can cause connection tracking to be enabled, then the tracking tables to overflow and packets to be dropped. This has once caused a VoIP outage for millions of users (there is also a public story about a similar accident: https://developers.soundcloud.com/blog/shoot-yourself-in-...).

Of course, there should be a central switch for administrators to restrict reachable ports, and also depending on the source. But this could also be achieved by a shared library that reads configuration from a well-known place and is used by any application binding to an IP socket. This library could then be extended at will with logging, rate-limiting, tar-pitting, ...
This would also make administration much easier and unified. Currently, some applications can bind to given interface names. Others to IP addresses. Others only to 0.0.0.0 or ::.

There even is something like this: tcpwrapper. I used to consider this pointless, because the kernel could already to that via ipchains/iptables. But now I think this is the right approach and should be massively extended. Ideally, it would never be required to use Netfilter on a non-router.

Dealing with automated SSH password-guessing

Posted Oct 26, 2016 19:49 UTC (Wed) by marcH (subscriber, #57642) [Link] (2 responses)

> At this point, it is possible to trigger a DoS on a very busy Linux system simply by running iptables -L (which is naively assumed to never change any state), because that can cause connection tracking to be enabled, then the tracking tables to overflow and packets to be dropped.
> https://developers.soundcloud.com/blog/shoot-yourself-in-...

Amazing.

> Of course, there should be a central switch for administrators to restrict reachable ports, and also depending on the source. But this could also be achieved by a shared library that reads configuration from a well-known place and is used by any application binding to an IP socket. This library could then be extended at will with logging, rate-limiting, tar-pitting, ...
> This would also make administration much easier and unified. Currently, some applications can bind to given interface names. Others to IP addresses. Others only to 0.0.0.0 or ::.

Another funny side-effect of having application-level configuration set in the wrong place: the ridiculously massive duplication between "iptables -L" and "ip6tables -L". Just run these two commands on most Linux systems and see for yourself. Who knows: maybe some day someone will get tired of this duplication and will start some user space tool to manage it... that would be a first step towards the aforementioned library!

Dealing with automated SSH password-guessing

Posted Oct 26, 2016 21:59 UTC (Wed) by chirlu (guest, #89906) [Link]

I have a single rule file that is used both for IPv4 and IPv6 and loaded via iptables-restore (from the iptables-persistent package, formerly netfilter-persistent). In the few cases where different rules are needed, they can be marked with the -4 and -6 options.

Dealing with automated SSH password-guessing

Posted Oct 27, 2016 12:57 UTC (Thu) by philwhineray (subscriber, #6106) [Link]

> Who knows: maybe some day someone will get tired of this duplication and will start some user space tool to manage it...

So then, just a quick plug for FireHOL, which produces IPv4 and IPv6 rules from a single config, with the option to mark rules as just for one or the other.

http://firehol.org/tutorial/firehol-ipv6/

It doesn't really help when it comes to inspecting the loaded rules, though.