#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs