diff --git a/opsec/torwebsite/index.html b/opsec/torwebsite/index.html index 37e7789..585ebab 100644 --- a/opsec/torwebsite/index.html +++ b/opsec/torwebsite/index.html @@ -398,6 +398,46 @@ nginx: configuration file /etc/nginx/nginx.conf test is successful +

Now that we have our website up and running, it's better to configure some DoS countermeasures to avoid any unpleasant problems.

+

There are many countermeasures, one of the most effective is PoW. If you want to learn more about other DoS prevention methods check the guidelines. If you want to learn more about how PoW works, check out the FAQs.

+

Without further ado, let's enable PoW for our onion service. +
+Add the following to your /etc/tor/torrc +

+
    HiddenServicePoWDefensesEnabled 1
+    HiddenServicePoWQueueRate 250
+    HiddenServicePoWQueueBurst 2500
+
+ +

This is what the options do (taken from tor(1) manual)

+
    HiddenServicePoWDefensesEnabled 0|1
+       Enable proof-of-work based service DoS mitigation. If set to 1
+       (enabled), tor will include parameters for an optional client
+       puzzle in the encrypted portion of this hidden service’s
+       descriptor. Incoming rendezvous requests will be prioritized based
+       on the amount of effort a client chooses to make when computing a
+       solution to the puzzle. The service will periodically update a
+       suggested amount of effort, based on attack load, and disable the
+       puzzle entirely when the service is not overloaded. (Default: 0)
+
+   HiddenServicePoWQueueRate NUM
+       The sustained rate of rendezvous requests to dispatch per second
+       from the priority queue. Has no effect when proof-of-work is
+       disabled. If this is set to 0 there’s no explicit limit and we will
+       process requests as quickly as possible. (Default: 250)
+
+   HiddenServicePoWQueueBurst NUM
+       The maximum burst size for rendezvous requests handled from the
+       priority queue at once. (Default: 2500)
+
+ +

If you don't know what rendezvous requests are, check out the specification, but essentially see them as "Hello I am NODE_X, I want to connect to NODE_Y to create a circuit, can you let me do it?"

+ +

If you are wondering how the priority queue is managed, think of it as how much effort the client put into solving the challenge; the more effort the higher the client priority will be (but also the time took to solve the challenge)

+ +

Don't forget to restart the hidden service to enable the changes made.

+ +