I'm considering the feasibility of a .onion domain for my website to cater to privacy conscious users.

Actions that occur before there's a known UserID (eg. login page) need to have a bounded number of attempts to prevent bruteforce attacks.

How do you effectively rate limit unauthenticated users on Tor to prevent bruteforce attacks?

4 Answers 4


When the brute force attacks happens in a slow manner, there is not much you can do. The situation is here quite similar to a non-Tor site.

If the attacker uses some tools which is similar to a DoS attack, you can use some tools which Tor delivers:

  • rate limiting: You can set HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSRatePerSec and HiddenServiceEnableIntroDoSBurstPerSec to tell the introduction point your rate limits. A detailed description can be found at the DoS part of the spec or at Tor's man page.
  • proof of work: Onion services have a proof of work system. You can enable it by setting HiddenServicePoWDefensesEnabled. You will need at least version (check it by running tor --modules, output should have pow: yes)

Some additional hints can be found at the DoS guidelines.


Your options are very limited.

You obviously cannot use visitor's IP because it isn't the visitor's IP.

If the user is using Tor Browser, you cannot fingerprint the client browser either, because they all will have the same or very similar fingerprints.

You could use cookies, but someone using bruteforce against your system will probably use a script and not a browser, so neither IP nor cookies nor fingerprint will result in anything.

You can use a captcha, but it will limit the services you can use because most captchas need Javascript.


You cannot do this at the network level since at this level you don't know if the user is authenticated or not. But at the application level you have this information, for example authenticated are users are the ones with a valid session cookie and everybody else is considered unauthenticated.

This means you are able to limit the number of unauthenticated requests you will process. This limit is a global limit though for all unauthenticated users since you cannot really distinguish users before they are authenticated, as ThoriumBR explained. With such a global limit anybody brute forcing the login will implicitly limit the ability for others to log in. Therefore such a limit might not be the best approach to tackle brute force logins.

Instead you might use methods which slow down any unauthenticated clients. This might be done by making the client do some work before they can connect, thus significantly slowing down any brute force attempts (which need to solve a new task for each login attempt) while at the same time only causing minor delay for normal clients (which need to solve the task only once for the single attempt). One approach might be a captcha, others might be using cryptographic Proof of Work. These methods can often also be dynamically adjusted regarding the amount of work which needs to be done, thus making it possible to offer fast access on low load but slower access on high load of your server.


You cannot ban wrongdoers by IP address but there are still things you can do by fingerprinting bad traffic. If you are under attack you will want to drop bad connections early, for instance at firewall/IDS level before they reach the webserver. This is going to take some solid sysadmin skills though.

How do you know you are under attack? Probably you or your users will notice that access to the site is slow or times out. But I strongly advise to install a monitoring solution so that you can detect abnormal traffic spikes. You need to have some metrics available, to have an idea of traffic at any given time.

In open source you have for example the Prometheus + Alert manager + Grafana. You can set alerts when certain thresholds are met. Of course that depends on the kind of hosting you have. If you use a VPS you have more flexibility than with shared hosting because you can install all the stuff you want. In the latter case, ask your webhost if by any chance they already have something in place to mitigate attacks.

When it is clear that your website is under attack, I suggest to capture a sample of traffic using tcpdump, then you can analyze it in Wireshark or do some scripting if this your thing. Scapy could come in handy here.

The trick is to find some kind of pattern in the traffic. For example, if there is a massive amount of traffic with an unusual user agent, this is a criterion you can use for blocking. Perhaps some expected headers are not set, and reveal that a bot is at work, and not a genuine user. The implementation will vary depending on the tools you use. An IDS can be used to drop packets matching a given signature.

If the attack is not so subtle and not too intense, it could be thwarted.

This could turn into a game of cat and mouse, however there is a good chance that you will be dealing with script kiddies and they will move on to another target.

Now the question is, does your hosting plan permit that plan of action. Ask the webhost about IDS availability.

There is one important consideration here. If your .onion site is hosted on the same server as your "clearnet" site, then it can be attacked outside Tor too. For instance if there is a UDP-based service like DNS running on your server, it can be subject to amplification attacks. Whereas Tor only allows TCP traffic.

The Cloudflare blog has some interesting articles on the art of blocking undesirable traffic:

This is hardcore stuff from people who literally specialize in filtering traffic, but there are interesting tidbits for regular sysadmins.

You must log in to answer this question.

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