sslh/doc/max_connections.md

56 lines
2.1 KiB
Markdown

Limiting the number of connections
----------------------------------
As a network-facing service, `sslh` can be attacked by very
simple denial-of-service attacks by creating a lot of
concurrent connections. Protecting against such attacks is
complicated from the server side. This attack will cause
`sslh` to create a large number of file handles, which can
cause exgagerated resource consumption.
This threat can be mitigated using several limitation
mechanisms. Keep in mind that limiting the number of
connections means that in case of an attack, the server
resources are protected, but this might be at the expense of
serving legitimate connections. In particular, in some cases
this might mean SSH is no longer available.
There are several mechanisms to limit the number of
connections:
- Use `ulimit` (see bash(3) or your shell's man page) to
limit the number of file descriptors.
Then, `sslh` provides several mechanisms to limit the number
of concurrent connections, which in turns limits the number
of file descriptors used.
Essentially there are two ways to do this:
- you can set `max_connections` per protocol, and `sslh`
will drop connections after probing if the count is
exceeded. This should help in keeping SSH connections
available even if an attacker is stuffing other protocols.
Currently this does not work for forking protocols (support
is planned).
- you can set `max_connections` for each `listen` entry. So
the `sslh` process for each port will limit the number of
concurrent connections to that port. This is similar to the
`udp_max_connections` setting, but for TCP.
`sslh-select` and `sslh-ev` support both limit types.
`sslh-fork` has an explicit design goal to be as simple as
possible, which makes it impossible to implement limits per
protocol (because protocol probing is performed after the
process has forked). Limits will only work for `listen`
entries.
As of sslh 2.2.5, this is an experimental feature and not
all use cases have been tested. If 2.2.5 does not exist yet,
you must be on the Git's head, so it is even more
experimtental! Do not hesitate to send feedback if you
notice inconsistent behaviour.