3

I am investigating methods to slow down the rate at which attackers can make brute force attempts against my webserver's SSH and HTTP services.
I have come across many articles as well as the iptables-extensions man page which suggest limiting the number of parallel connections an IP address can make, using rules like

iptables -A INPUT -p tcp -syn -m multiport --dport 80,443 -m connlimit --connlimit-above 20 -j REJECT

Which will only allow 20 connections per IP at any given time.

Given that the HTTP 1.1 and HTTP 2.0 (not sure about SSH) protocols support tcp multiplexing and that by default webservers like Apache will keep idle TCP connections active with KeepAlive directive, I would have thought a bruteforce tool would only need to establish a low number of connections and those connections could support many repeated requests and responses over a long period of time e.g. a browser might only need 6-8 connections at any given time yet those connections will support many HTTP request/responses.

  • Does anyone know from experience how many parallel TCP connections a brute force tool will try and open?
  • and also are rate limiting firewall rules like this effective?
Improve this question
2
  • connection limiting != rate limiting and you seem to be equating brute force logins with DoS.
    – schroeder ♦
    Nov 19, 2015 at 5:58
  • thanks, yes I guess I do equate brute force logins as having the same effect as a DOS - when the flood of attempts consumes all server resources and causes problems with page loads for users. But yes I know they are different things.
    – the_velour_fog
    Nov 19, 2015 at 6:31

1 Answer 1

Reset to default
2

Personally, I use fail2ban to stop bruce force logins. Brute force tools tend not to open many parallel connections.

As for brute forcing HTTP logins, your connection limiting rules will depend on how many parallel connections your web applications requires. If you set it too short, your legitimate users won't be able to use your service.

Improve this answer
1
  • thanks for the response! Yes I also use fail2ban on SSH and web application login pages, but I find it needs to be configured quite explicitly to a specific scenario and needs the web app/server combination to generate logs that fail2ban can detect. So I have been considering rate limiting as a kind of catch-all that applies limits to all types of interactions with the server - thereby catching things that fail2ban doesnt detect and also preventing users experiencing problems - because the server resources are consumed by a flood of traffic - e.g. a brute force login attack
    – the_velour_fog
    Nov 19, 2015 at 6:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .