Bedankt dat je de tijd hebt genomen om dit te lezen! We zijn geen experts in Tor networking, maar weten onze weg te vinden.
Als je iets snapt van wat hier is beschreven en/of je hebt een vermoeden van wat er aan de hand is, dan wordt elke vorm van feedback zeer op prijs gesteld!
1. Wat is er aan de hand?
Onze service draaide lange tijd goed en stabiel. Plots ondervond onze service eerst lichte, toen ernstige prestatieproblemen en werd vervolgens volledig onbereikbaar.
Dit lijkt geen "gewone" DDoS-aanval te zijn. Het lijkt een DoS-aanval te zijn, maar niet zoals iets bekends, omdat het alleen een aanval op de Tor daemon lijkt te zijn. Alle tegenmaatregelen die we tot nu toe hebben geprobeerd waren niet succesvol. Er is geen aanval merkbaar op de services die draaien (http, ssh, ftp, mail, etc.) maar alleen op de Tor verbinding zelf.
Ook al hebben we diepgaand onderzoek gedaan, de gebeurtenis lijkt buiten ons begrip te vallen. Documentaties over eerdere aanvallen op Tor Hidden Services zijn zeldzaam en komen niet overeen met wat wij ervaren.
We weigeren te geloven dat er een aanvalsscenario is dat onbekend is en niet tegengegaan kan worden omdat het elke Tor Hidden Service kwetsbaar zou maken waarbij tegenstanders in staat zouden zijn om elke Tor Hidden Service binnen enkele minuten voor onbepaalde tijd offline te halen. De impact op de Tor gemeenschap zou niet te overzien zijn.
We hopen dat iemand met het benodigde inzicht en expertise ons op zijn minst een hint kan geven over wat er precies aan de hand is en ons in de juiste richting kan wijzen naar het vinden van een oplossing om deze aanval te beëindigen of de impact op onze systemen te verminderen en om dergelijke aanvallen in de toekomst te voorkomen. Dit zou helpen om Tor Hidden Services over de hele wereld te beschermen tegen toekomstige aanvallen zoals degene die we nu meemaken.
2. Wat is de setup?
- Het systeem draait op een huidige en altijd up-to-date linux (amd64) server
- Al het verkeer wordt door Tor geleid via Tor transport op poort 9040, DNS zoekopdrachten worden ook via Tor opgelost
- De Tor verborgen service is v3
- Tor is versie 0.4.7.8 draait met Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 en Glibc 2.31 als libc
- Tor gecompileerd met GCC versie 10.2.1. Vanguards 0.3.1 is ook geïnstalleerd
- Tor draait als een systemd service
- Vanguards draait als systemd service
torrc configuratie:
CookieAuthenticatie 1
HashedControlPassword 16:<hash>
Virtueel adresNetwerkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 127.0.0.1:9040
DNSPort 127.0.0.1:53
HiddenServiceDir /var/lib/tor/hidden_service
HiddenServicePort 80 127.0.0.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. Wat zijn de symptomen?
- Minder dan een minuut na het opstarten van Tor met de Hidden Service ingeschakeld komt de CPU op 100%, het geheugen lijkt niet aangetast te zijn.
- De gebruikte bandbreedte neemt toe met ongeveer 100kb/s
- De Hidden Service descriptor is onbereikbaar
- Het systeem kan nog steeds clearnet en Tor adressen oplossen
- Het systeem kan nog steeds verbinding maken met uitgaande services (bijv. curl naar een website)
- Het systeem wordt overspoeld met inkomende tcp pakketten op de loopback interface
- Wanneer Tor opnieuw gestart wordt, stopt de vloed voor een paar seconden en begint dan opnieuw.
- Wanneer Tor wordt gestart zonder dat de Hidden Service is ingeschakeld lijkt er geen probleem te zijn
- Wanneer Tor gestart wordt met een tweede Hidden Service ingeschakeld, blijven beide Hidden Service Descriptors onbereikbaar:
Tor Browser op primair HS:
Onionsite heeft verbinding verbroken
De meest waarschijnlijke oorzaak is dat de onionsite offline is. Neem contact op met de onionsite beheerder.
Details: 0xF2 - Introductie mislukt, wat betekent dat de descriptor is gevonden maar dat de service niet langer verbonden is met het introductiepunt. Het is waarschijnlijk dat de service zijn descriptor heeft veranderd of dat hij niet draait.
of
De verbinding is verbroken
De server op (aangevallen verborgen service descriptor).onion doet er te lang over om te reageren.
De site kan tijdelijk niet beschikbaar of te druk zijn. Probeer het over enkele ogenblikken opnieuw.
Tor Browser op Seconday HS:
Kan geen verbinding maken
Firefox kan geen verbinding maken met de server op (secondary hidden service descriptor).onion
De site is mogelijk tijdelijk niet beschikbaar of te druk. Probeer het over enkele ogenblikken opnieuw.
- Wanneer Tor wordt gestart met een tweede verborgen service ingeschakeld die wordt beschermd door OnionAuthentication, blijft de primaire verborgen service onbereikbaar,
de secundaire (beschermde) Hidden Service Descriptor is wel bereikbaar.
- Wanneer Tor gestart wordt met alleen de tweede verborgen service ingeschakeld (met of zonder OnionAuthentication) lijkt er geen probleem te zijn.
- Wanneer Tor gestart wordt met de primaire verborgen service beschermd door OnionAuthentication, is de verborgen servicebeschrijving bereikbaar.
- Wanneer aangevallen, verschijnen deze vermeldingen in het tor logbestand:
Aug 24 19:42:18.000 [notice] Opgestart 100% (gedaan): Gereed
Aug 24 19:42:34.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn veranderd. Time-out teruggezet naar 60000ms na 18 timeouts en 388 buildtimes.
Aug 24 19:42:39.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn gewijzigd. Time-out terugzetten op 60000ms na 18 timeouts en 240 opbouwtijden.
Aug 24 19:42:53.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn gewijzigd. Time-out terugzetten op 60000ms na 18 timeouts en 489 opbouwtijden.
Aug 24 19:43:11.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn gewijzigd. Time-out opnieuw ingesteld op 60000ms na 18 timeouts en 659 opbouwtijden.
...
Aug 24 19:46:09.000 [notice] Extreem grote waarde voor circuit opbouw timeout: 122s. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:46:09.000 [notice] Zeer grote waarde voor opbouw time-out circuit: 122s. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:46:09.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn veranderd. Time-out terugzetten op 60000ms na 18 time-outs en 114 opbouwtijden.
Aug 24 19:46:15.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn gewijzigd. Time-out terugzetten op 60000ms na 18 timeouts en 125 opbouwtijden.
...
Aug 24 19:47:08.000 [notice] Extreem grote waarde voor circuit opbouw timeout: 123s. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:47:10.000 [notice] Zeer grote waarde voor opbouw timeout circuit: 122s. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:47:10.000 [notice] Extreem grote waarde voor opbouw timeout circuit: 123s. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:47:13.000 [notice] Extreem grote waarde voor opbouw timeout circuit: 123s. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:47:14.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn veranderd. Time-out terugzetten op 60000ms na 18 time-outs en 495 opbouwtijden.
Aug 24 19:47:18.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn gewijzigd. Time-out terugzetten op 60000ms na 18 timeouts en 124 opbouwtijden.
Aug 24 19:47:21.000 [notice] Extreem grote waarde voor circuit opbouw timeout: 122s. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:47:23.000 [notice] Extreem grote waarde voor opbouw timeout circuit: 123s. Aangenomen dat klok verspringt. Doel 14 (Meten van circuit timeout)
...
Aug 24 19:47:55.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn veranderd. Time-out terugzetten op 60000ms na 18 timeouts en 1000 buildtimes.
Aug 24 19:47:59.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn gewijzigd. Time-out terugzetten op 60000ms na 18 timeouts en 117 opbouwtijden.
...
Aug 24 19:52:43.000 [notice] Vreemde waarde voor circuit opbouwtijd: 121581msec. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:52:43.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn veranderd. Time-out terugzetten op 120000ms na 18 time-outs en 57 opbouwtijden.
Aug 24 19:52:53.000 [notice] Onderbreking: netjes verlaten.
4. Wat is er geprobeerd om het probleem op te lossen?
- We hebben een compleet nieuwe server vanaf nul opgezet waarop alleen het basisbesturingssysteem en tor en vanguards in de standaardconfiguratie draaien om de mogelijkheid van een verkeerde configuratie op onze getroffen server uit te sluiten. Zodra tor werd gestart met de aangevallen descriptor gebeurden precies dezelfde dingen.
- We probeerden de belasting op onze server te verdelen via OnionBalance in deze opstelling:
Server1: Voert Onionbalance uit voor primaire verborgen dienstdescriptor
Server2/3/4: voert de verborgen service uit op nieuwe en verschillende verborgen servicebeschrijvingen
- Dit brengt de oorspronkelijke verborgen servicedescriptor niet terug tot leven
- De service descriptors op servers 2/3/4 zijn bereikbaar als ze rechtstreeks worden geopend, maar niet via de nu gebalanceerde primaire descriptor
- De CPU op servers 2/3/4 gaat naar 100% zolang de aanval plaatsvindt, terwijl de CPU op server 1 (balancer) normaal blijft.
- Het toevoegen van meer backend servers aan de balancer maakte ook geen verschil
- We voegden deze directives toe aan het hidden service block in torrc en probeerden verschillende instellingen uit:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <getest met verschillende waarden>
HiddenServiceEnableIntroDoSRatePerSec <getest met verschillende waarden>.
Dit verminderde de CPU-belasting aanzienlijk op servers 2/3/4, maar de gebalanceerde service-descriptor blijft onbereikbaar.
- We probeerden verschillende instellingen in vanguards.conf te veranderen, zonder succes.
- We hebben geprobeerd de aanvallende tcp pakketten te identificeren en ze te laten blokkeren via iptables, zonder succes.
Onze expertise is niet toereikend om een idee te krijgen van wat er precies gebeurt door de inhoud van de genoemde tcp-pakketten te inspecteren, die er als volgt uitzien:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), lengte 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flags [P.], cksum 0x0df9 (onjuist -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, options [nop,nop,TS val 2971851406 ecr 2971851369], lengte 4048
E.....@[email protected]........#[.x[...f
.............
."...".i650 CIRC 9802 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC 9802 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC_MINOR 9802 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(aangevallen verborgen service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9818 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC 9818 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC_MINOR 9818 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(aangevallen verborgen service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9997 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(aangevallen verborgen service descriptor)---------| TIME_CREATED=2022-08-24T19:45:25.100429
650 CIRC 9997 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(aangevallen verborgen service descriptor)---------| TIME_CREATED=2022-08-24T19:45:25.10
Dit is met Tor draaiend op een enkele server. Wanneer gebalanceerd, wordt de |---------(aangevallen verborgen service descriptor)---------| vervangen door de backends service descriptors van server 2/3/4.
We kunnen een groter tcpdump fragment beschikbaar maken, indien nodig.
5. Conclusies
We denken dat een tegenstander de mogelijkheid heeft om een Hidden Service Descriptor (en dus de Hidden Service zelf) te "onderbreken" door de Tor daemon te overspoelen met ontelbare tcp pakketten, met het verzoek om circuits op te bouwen. Dit is wat de CPU-belasting veroorzaakt en uiteindelijk de Hidden Service Descriptor onbruikbaar maakt.
Kan iemand dit bevestigen?
Aangezien richtlijnen zoals de genoemde HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec en HiddenServiceEnableIntroDoSRatePerSec bedoeld lijken om dit soort aanvallen af te weren, net zoals voorhoedes dat zouden moeten doen, kunnen we niet verklaren waarom deze ineffectief blijven. Misschien zijn er speciale instellingen van deze waarden nodig om ze effectief te maken. Helaas zijn deze richtlijnen (evenals de instellingen in vanguards.config) slechts op een vage manier beschreven.
Weet iemand hoe deze correct moeten worden ingesteld om effectief te zijn?
Op dit moment hebben we alle verwijzingen naar tor en vanguards configuratie die we online konden vinden uitgezocht.
Nogmaals, alle hulp of informatie over deze kwestie zou zeer op prijs worden gesteld! We geloven niet dat hier geen oplossing voor is.
Als je iets snapt van wat hier is beschreven en/of je hebt een vermoeden van wat er aan de hand is, dan wordt elke vorm van feedback zeer op prijs gesteld!
1. Wat is er aan de hand?
Onze service draaide lange tijd goed en stabiel. Plots ondervond onze service eerst lichte, toen ernstige prestatieproblemen en werd vervolgens volledig onbereikbaar.
Dit lijkt geen "gewone" DDoS-aanval te zijn. Het lijkt een DoS-aanval te zijn, maar niet zoals iets bekends, omdat het alleen een aanval op de Tor daemon lijkt te zijn. Alle tegenmaatregelen die we tot nu toe hebben geprobeerd waren niet succesvol. Er is geen aanval merkbaar op de services die draaien (http, ssh, ftp, mail, etc.) maar alleen op de Tor verbinding zelf.
Ook al hebben we diepgaand onderzoek gedaan, de gebeurtenis lijkt buiten ons begrip te vallen. Documentaties over eerdere aanvallen op Tor Hidden Services zijn zeldzaam en komen niet overeen met wat wij ervaren.
We weigeren te geloven dat er een aanvalsscenario is dat onbekend is en niet tegengegaan kan worden omdat het elke Tor Hidden Service kwetsbaar zou maken waarbij tegenstanders in staat zouden zijn om elke Tor Hidden Service binnen enkele minuten voor onbepaalde tijd offline te halen. De impact op de Tor gemeenschap zou niet te overzien zijn.
We hopen dat iemand met het benodigde inzicht en expertise ons op zijn minst een hint kan geven over wat er precies aan de hand is en ons in de juiste richting kan wijzen naar het vinden van een oplossing om deze aanval te beëindigen of de impact op onze systemen te verminderen en om dergelijke aanvallen in de toekomst te voorkomen. Dit zou helpen om Tor Hidden Services over de hele wereld te beschermen tegen toekomstige aanvallen zoals degene die we nu meemaken.
2. Wat is de setup?
- Het systeem draait op een huidige en altijd up-to-date linux (amd64) server
- Al het verkeer wordt door Tor geleid via Tor transport op poort 9040, DNS zoekopdrachten worden ook via Tor opgelost
- De Tor verborgen service is v3
- Tor is versie 0.4.7.8 draait met Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 en Glibc 2.31 als libc
- Tor gecompileerd met GCC versie 10.2.1. Vanguards 0.3.1 is ook geïnstalleerd
- Tor draait als een systemd service
- Vanguards draait als systemd service
torrc configuratie:
CookieAuthenticatie 1
HashedControlPassword 16:<hash>
Virtueel adresNetwerkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 127.0.0.1:9040
DNSPort 127.0.0.1:53
HiddenServiceDir /var/lib/tor/hidden_service
HiddenServicePort 80 127.0.0.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. Wat zijn de symptomen?
- Minder dan een minuut na het opstarten van Tor met de Hidden Service ingeschakeld komt de CPU op 100%, het geheugen lijkt niet aangetast te zijn.
- De gebruikte bandbreedte neemt toe met ongeveer 100kb/s
- De Hidden Service descriptor is onbereikbaar
- Het systeem kan nog steeds clearnet en Tor adressen oplossen
- Het systeem kan nog steeds verbinding maken met uitgaande services (bijv. curl naar een website)
- Het systeem wordt overspoeld met inkomende tcp pakketten op de loopback interface
- Wanneer Tor opnieuw gestart wordt, stopt de vloed voor een paar seconden en begint dan opnieuw.
- Wanneer Tor wordt gestart zonder dat de Hidden Service is ingeschakeld lijkt er geen probleem te zijn
- Wanneer Tor gestart wordt met een tweede Hidden Service ingeschakeld, blijven beide Hidden Service Descriptors onbereikbaar:
Tor Browser op primair HS:
Onionsite heeft verbinding verbroken
De meest waarschijnlijke oorzaak is dat de onionsite offline is. Neem contact op met de onionsite beheerder.
Details: 0xF2 - Introductie mislukt, wat betekent dat de descriptor is gevonden maar dat de service niet langer verbonden is met het introductiepunt. Het is waarschijnlijk dat de service zijn descriptor heeft veranderd of dat hij niet draait.
of
De verbinding is verbroken
De server op (aangevallen verborgen service descriptor).onion doet er te lang over om te reageren.
De site kan tijdelijk niet beschikbaar of te druk zijn. Probeer het over enkele ogenblikken opnieuw.
Tor Browser op Seconday HS:
Kan geen verbinding maken
Firefox kan geen verbinding maken met de server op (secondary hidden service descriptor).onion
De site is mogelijk tijdelijk niet beschikbaar of te druk. Probeer het over enkele ogenblikken opnieuw.
- Wanneer Tor wordt gestart met een tweede verborgen service ingeschakeld die wordt beschermd door OnionAuthentication, blijft de primaire verborgen service onbereikbaar,
de secundaire (beschermde) Hidden Service Descriptor is wel bereikbaar.
- Wanneer Tor gestart wordt met alleen de tweede verborgen service ingeschakeld (met of zonder OnionAuthentication) lijkt er geen probleem te zijn.
- Wanneer Tor gestart wordt met de primaire verborgen service beschermd door OnionAuthentication, is de verborgen servicebeschrijving bereikbaar.
- Wanneer aangevallen, verschijnen deze vermeldingen in het tor logbestand:
Aug 24 19:42:18.000 [notice] Opgestart 100% (gedaan): Gereed
Aug 24 19:42:34.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn veranderd. Time-out teruggezet naar 60000ms na 18 timeouts en 388 buildtimes.
Aug 24 19:42:39.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn gewijzigd. Time-out terugzetten op 60000ms na 18 timeouts en 240 opbouwtijden.
Aug 24 19:42:53.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn gewijzigd. Time-out terugzetten op 60000ms na 18 timeouts en 489 opbouwtijden.
Aug 24 19:43:11.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn gewijzigd. Time-out opnieuw ingesteld op 60000ms na 18 timeouts en 659 opbouwtijden.
...
Aug 24 19:46:09.000 [notice] Extreem grote waarde voor circuit opbouw timeout: 122s. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:46:09.000 [notice] Zeer grote waarde voor opbouw time-out circuit: 122s. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:46:09.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn veranderd. Time-out terugzetten op 60000ms na 18 time-outs en 114 opbouwtijden.
Aug 24 19:46:15.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn gewijzigd. Time-out terugzetten op 60000ms na 18 timeouts en 125 opbouwtijden.
...
Aug 24 19:47:08.000 [notice] Extreem grote waarde voor circuit opbouw timeout: 123s. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:47:10.000 [notice] Zeer grote waarde voor opbouw timeout circuit: 122s. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:47:10.000 [notice] Extreem grote waarde voor opbouw timeout circuit: 123s. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:47:13.000 [notice] Extreem grote waarde voor opbouw timeout circuit: 123s. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:47:14.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn veranderd. Time-out terugzetten op 60000ms na 18 time-outs en 495 opbouwtijden.
Aug 24 19:47:18.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn gewijzigd. Time-out terugzetten op 60000ms na 18 timeouts en 124 opbouwtijden.
Aug 24 19:47:21.000 [notice] Extreem grote waarde voor circuit opbouw timeout: 122s. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:47:23.000 [notice] Extreem grote waarde voor opbouw timeout circuit: 123s. Aangenomen dat klok verspringt. Doel 14 (Meten van circuit timeout)
...
Aug 24 19:47:55.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn veranderd. Time-out terugzetten op 60000ms na 18 timeouts en 1000 buildtimes.
Aug 24 19:47:59.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn gewijzigd. Time-out terugzetten op 60000ms na 18 timeouts en 117 opbouwtijden.
...
Aug 24 19:52:43.000 [notice] Vreemde waarde voor circuit opbouwtijd: 121581msec. Aangenomen dat klok verspringt. Doel 14 (Circuit timeout meten)
Aug 24 19:52:43.000 [notice] De snelheid van uw netwerkverbinding lijkt te zijn veranderd. Time-out terugzetten op 120000ms na 18 time-outs en 57 opbouwtijden.
Aug 24 19:52:53.000 [notice] Onderbreking: netjes verlaten.
4. Wat is er geprobeerd om het probleem op te lossen?
- We hebben een compleet nieuwe server vanaf nul opgezet waarop alleen het basisbesturingssysteem en tor en vanguards in de standaardconfiguratie draaien om de mogelijkheid van een verkeerde configuratie op onze getroffen server uit te sluiten. Zodra tor werd gestart met de aangevallen descriptor gebeurden precies dezelfde dingen.
- We probeerden de belasting op onze server te verdelen via OnionBalance in deze opstelling:
Server1: Voert Onionbalance uit voor primaire verborgen dienstdescriptor
Server2/3/4: voert de verborgen service uit op nieuwe en verschillende verborgen servicebeschrijvingen
- Dit brengt de oorspronkelijke verborgen servicedescriptor niet terug tot leven
- De service descriptors op servers 2/3/4 zijn bereikbaar als ze rechtstreeks worden geopend, maar niet via de nu gebalanceerde primaire descriptor
- De CPU op servers 2/3/4 gaat naar 100% zolang de aanval plaatsvindt, terwijl de CPU op server 1 (balancer) normaal blijft.
- Het toevoegen van meer backend servers aan de balancer maakte ook geen verschil
- We voegden deze directives toe aan het hidden service block in torrc en probeerden verschillende instellingen uit:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <getest met verschillende waarden>
HiddenServiceEnableIntroDoSRatePerSec <getest met verschillende waarden>.
Dit verminderde de CPU-belasting aanzienlijk op servers 2/3/4, maar de gebalanceerde service-descriptor blijft onbereikbaar.
- We probeerden verschillende instellingen in vanguards.conf te veranderen, zonder succes.
- We hebben geprobeerd de aanvallende tcp pakketten te identificeren en ze te laten blokkeren via iptables, zonder succes.
Onze expertise is niet toereikend om een idee te krijgen van wat er precies gebeurt door de inhoud van de genoemde tcp-pakketten te inspecteren, die er als volgt uitzien:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), lengte 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flags [P.], cksum 0x0df9 (onjuist -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, options [nop,nop,TS val 2971851406 ecr 2971851369], lengte 4048
E.....@[email protected]........#[.x[...f
.............
."...".i650 CIRC 9802 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC 9802 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC_MINOR 9802 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(aangevallen verborgen service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9818 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC 9818 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC_MINOR 9818 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(aangevallen verborgen service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9997 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(aangevallen verborgen service descriptor)---------| TIME_CREATED=2022-08-24T19:45:25.100429
650 CIRC 9997 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(aangevallen verborgen service descriptor)---------| TIME_CREATED=2022-08-24T19:45:25.10
Dit is met Tor draaiend op een enkele server. Wanneer gebalanceerd, wordt de |---------(aangevallen verborgen service descriptor)---------| vervangen door de backends service descriptors van server 2/3/4.
We kunnen een groter tcpdump fragment beschikbaar maken, indien nodig.
5. Conclusies
We denken dat een tegenstander de mogelijkheid heeft om een Hidden Service Descriptor (en dus de Hidden Service zelf) te "onderbreken" door de Tor daemon te overspoelen met ontelbare tcp pakketten, met het verzoek om circuits op te bouwen. Dit is wat de CPU-belasting veroorzaakt en uiteindelijk de Hidden Service Descriptor onbruikbaar maakt.
Kan iemand dit bevestigen?
Aangezien richtlijnen zoals de genoemde HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec en HiddenServiceEnableIntroDoSRatePerSec bedoeld lijken om dit soort aanvallen af te weren, net zoals voorhoedes dat zouden moeten doen, kunnen we niet verklaren waarom deze ineffectief blijven. Misschien zijn er speciale instellingen van deze waarden nodig om ze effectief te maken. Helaas zijn deze richtlijnen (evenals de instellingen in vanguards.config) slechts op een vage manier beschreven.
Weet iemand hoe deze correct moeten worden ingesteld om effectief te zijn?
Op dit moment hebben we alle verwijzingen naar tor en vanguards configuratie die we online konden vinden uitgezocht.
Nogmaals, alle hulp of informatie over deze kwestie zou zeer op prijs worden gesteld! We geloven niet dat hier geen oplossing voor is.
Last edited:
