[tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sun Jan 21 16:48:56 UTC 2018
#24902: Denial of Service mitigation subsystem
-------------------------------------------------+-------------------------
Reporter: dgoulet | Owner: dgoulet
Type: enhancement | Status:
| needs_review
Priority: Very High | Milestone: Tor:
| 0.3.3.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: ddos, tor-relay, review-group-30, | Actual Points:
029-backport, 031-backport, 032-backport |
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Changes (by dgoulet):
* keywords: ddos, tor-relay, review-group-30 =>
ddos, tor-relay, review-group-30, 029-backport, 031-backport,
032-backport
* priority: Medium => Very High
* status: accepted => needs_review
Comment:
Hello again world!
Ok, some code is ready implementing the above. It defers greatly from the
previous branch. Most of it has been simplified. This branch also now
implements the 3 detections mentioned above which are (1) circuit creation
DoS, (2) concurrent connection DoS and (3) ESTABLISH_RENDEZVOUS from
client (tor2web) DoS.
Some stuff you might find useful to know before you dive in:
* Each detection (listed above) have for now only one single type of
defense implemented so if we think of more that we might want short term,
now is a good time to get them in. Defenses can be selected by a consensus
parameter.
* For the (3) defense, I've gone quite explicitly with a torrc option
(controlled also by a consensus param) to refuse tor2web client
connections. There is no threshold no nothing for now because frankly I
think tor2web clients are more hurting us than anything else by their
ability to directly connect to all relays and thus induce resources
pressure onto all relays "naturally"...
* This code uses the geoip client cache which seems fine but has an
interesting quirks. After 24h, an entry is wiped out which means we loose
all the DoS mitigation statistics for the entry at that point. Not too bad
because if the client address is still DoSing, it will be detected again
and blocked. Wouldn't be too hard to not do that but would require a bit
more code/thinking to clean it up so it doesn't grow infinitely.
* The branch you are about to review is based on 029 considering a
possible backport. If you want to test this on a relay that was previously
>= 0.3.1, know that your client won't connect to it until you get a new
consensus because it will be expecting an ed25519 key for which there is
none used at 029. Either use an older client or merge forward to latest
master by resolving the few conflicts there will be :).
* All the DoS detection and defense are disabled by default. It requires a
consensus param to be set for them to be enabled. So, if you want to test
this on a relay, go in `src/or/dos.h` and change the enabled default
values in there for both CC and CONN defenses.
* A log has been added to the heartbeat so if it works, you should see
such a line (real one!):
{{{
Jan 21 16:32:57.647 [notice] DoS mitigation since startup: 459085 cells
rejected, 128 marked address. 235 MB have been dropped. 20126 connection
rejected. 200 tor2web client refused.
}}}
Let us bikeshed on names here if you don't like them and please propose an
alternative because this is currently the best I can come up with my "non-
English-been-a-month-on-DoS-land brain" :).
Branch: `ticket24902_029_01`
Oniongit: https://oniongit.eu/dgoulet/tor/merge_requests/16
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24902#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list