Forum biedt betaalde toegang tot meer dan duizend gehackte servers in Benelux

Beveiligingsonderzoekers van Kaspersky Lab hebben een forum onderzocht dat dient als handelsplaats voor toegang tot gehackte servers. In mei kon via xDedic toegang worden verkregen tot ruim 70.000 servers, waaronder 1155 in de Benelux.

Het gaat om gehackte Remote Desktop Protocol-servers, die veelal populaire consumentenwebsites en ‑diensten hosten, volgens SecureList. Kwaadwillenden kunnen via xDedic toegang tot de gehackte servers krijgen voor prijzen vanaf zo'n vijf euro en deze gebruiken om aanvallen uit te voeren.

Het beheer van de rdp-servers wordt vaak door middel van brute force overgenomen. Op het forum kunnen klanten selecteren op rdp-configuratie, geheugen, aanwezige software en meer. In mei was zo volgens de onderzoekers toegang tot 70.624 servers in 173 landen te koop. Daaronder bevonden zich 736 Nederlandse servers en 419 servers in België. Volgens het onderzoek behoren de servers in veel gevallen toe aan gerenommeerde organisaties, waaronder overheidsinstanties en universiteiten, en zouden die zich vaak niet bewust zijn van het misbruik van hun apparatuur.

Het forum is al enkele jaren actief, maar in recente maanden zijn de activiteit en het aantal aangeboden, gehackte servers flink toegenomen. Volgens de onderzoekers zit er een Russischtalige groepering achter xDedic; de gehackte servers worden echter aangeboden door individuen. Op het moment van het onderzoek zou het gaan om 416 verschillende verkopers. Het xDedic-team heeft ook een eigen rdp-client gemaakt, die het voor klanten makkelijker moet maken om in te loggen op de gehackte servers.

Kaspersky Lab werd door een internetprovider geattendeerd op het bestaan van het forum en zegt in samenwerking met autoriteiten te werken aan aanvullend onderzoek. Een uitgebreide analyse van de xDedic Marketplace is gepubliceerd in een pdf.

De middelste afbeelding toont de locaties van de gehackte servers

Reacties (71)

[Yarisken]

Ik kan er eigenlijk niet bij dat je rdp en ssh openzet naar buiten toe.
Bij ons staat er 1 server met ssh naar buiten open maar enkel bepaalde externe ip's kunnen erop connecteren.

[unglaublich]

Als je je SSH gewoon goed instelt met alleen public-key authenticatie en geen root toegang toestaat (standaard config opties) is het hartstikke veilig. Eventueel nog fail2ban installeren zodat je na X pogingen Y minuten geblokkeerd wordt als je echt bang bent en klaar.

[sjosz]

Mee eens dat het goed instellen van SSH voldoende zou moeten zijn. 3 Dagen geleden alles ingesteld zoals Unglaublich het beschrijft; public key authenticatie (4096 bit) en fail2ban die na foutieve 15 inlogpogingen de potentiële aanval blokkeert. Er wordt verbazingwekkend vaak geprobeerd in te loggen via SSH op mijn server. Fail2ban heeft in die 3 dagen al 82 IP adressen in mijn hosts.deny bestand bestand gegooid Opvallend is dat 56 van die geblokkeerde IP adressen geregistreerd staan in China.

[Reactie gewijzigd door sjosz op 22 juli 2024 17:51]

[unglaublich]

The great firewall werkt maar één kant op zo te lezen

[viccoh]

Combineer het met https://www.blocklist.de aub (je upload je bevindingen dan naar hun)
Als iedereen dat doet stop je ze al bij de eerste poging omdat de verzamelde IP pool gedeeld kan worden EN blocklist.de stuurt abuse meldingen de deur uit.

[Deralte]

Ik krijg veel Tor exit nodes als ik een whois do op de ip's van de hackpogingen op mijn (thuis)server.

[Tadsz]

Dit blijf ik dus steeds afvragen: hoe worden grote servers steeds gehacked terwijl een home-server met SSH (keys) zo veilig zou zijn?

[unglaublich]

Omdat grote servers onderdeel zijn van grote organisaties. Niemand heeft een goed overzicht van de software die draait, de poorten die open staan en de communicatie tussen verschillende servers. Software updaten is zo goed als onmogelijk omdat alles in elkaar is verweven.

[Verwijderd]

Uit mijn eigen ervaring kom je er meestal pas achter, dat er zo'n server is.. als het te laat is.
Juist in dienstverband kennen mensen haast. Zeker met zo'n goede leider van uurtje factuurtje. Dan willen mensen wel eens dingen laten vallen, omdat ze bang zijn niet om 17:00 naar huis te kunnen, of een vervelende manager in hun nek te krijgen.

[Yarisken]

Wel, toen ik op mijn huidig werk begon heb ik 2 servers gevonden die gehacked waren.
1 met het standaard wachtwoord van tomcat en 1 met een niet-gepatchte oude versie van jboss. Admin poort stond ook open naar buiten toe.
Het wil niet zeggen dat je bij grote firma's de "beste" it'ers vindt hé :-).
Op zich is elke organisatie te hacken.
Lees dit maar eens door.
http://pastebin.com/raw/0SNSvyjJ
Hacker heeft 100 uur bezig geweest om deze jongens ( zelf hackers ) te hacken.

[GekkePrutser]

Ik ben in mijn vorige baan als consultant veel over de vloer geweest bij grote bedrijven. En het verbaasde me altijd wat je daar tegenkomt aan Admin paswoorden. Dingen als '<bedrijfsnaam>123', dat soort dingen was eerder regel dan uitzondering. Natuurlijk waren er wel Active Directory infrastructuren maar die werden vaak niet gebruikt voor applicatieservers die door derde partijen beheerd werden (en dat zijn de meesten tegenwoordig doordat bijna alles outsourced wordt). Want externe mensen mochten vaak weer geen Active Directory account hebben (SoX regels enzo).

Nu moet ik er wel bij zeggen dat deze servers niet open stonden naar internet maar waren wel voor iedereen in het bedrijfs LAN bereikbaar. Dus aan enkele tienduizenden mensen. Die allemaal met hun laptop in cafe's vliegvelden en andere onveilige omstandigheden rondlopen, dus best een grote kans op malware/botnet infecties.

Ik denk dat het komt doordat juist binnen grote organisaties paswoorden moeilijk veilig te delen zijn. Er zijn vaak wel IT policies voor beveiliging maar die zijn dan dusdanig complex dat die in de praktijk gewoon niet werken en mensen juist buiten de procedures om gaan werken. Bij voorbeeld internet toegang die zo dichtgetimmerd is dat je geen applicatie updates mag downloaden zodat je weer moet gaan hannesen met onveilige USB sticks op de server.

Dusja, ik ben niet erg verbaasd over het aantal hacks van grote servers eigenlijk.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 17:51]

[BJD1997]

En SSH met Google authenticator (raspberry pi) op een privé servertje is dat een beetje veilig dan?

[jurroen]

Dat is al een hele goede stap in de juiste richting. Zet PasswordAuthentication uit, werk met keys en indien mogelijk, laat alleen traffic toe van IP adressen die je vertrouwt.

Enigszins off topic, ik zag laatst (online) een filmpje die Google Authenticator gebruikte om de ssh poort te randomizen. Security through obscurity (verbergen is niet beveiligen) maar wel erg grappig om te zien.

[Yarisken]

En wat als er een exploit is voor je ssh service ? Mijn credo is dat als het niet nodig is , hang het dan niet aan het net.

[ejabberd]

https://wiki.mozilla.org/Security/Guidelines/OpenSSH

https://www.digitalocean....n-for-ssh-on-ubuntu-14-04

...en natuurlijk ook fail2ban.

[Verwijderd]

Veel server hosters geven gewoon RDP access tot hun machines. Je moet wel een ultra-sterk wachtwoord aanmaken want de servers staan gewoon open. Ik begrijp niet waarom ze niet aan whitelisting doen.

RDP verkeer wordt versleuteld met een RC4 stream cipher dus dat is wel redelijk veilig.. Maar als mensen eenvoudige wachtwoorden gebruiken dan is natuurlijk niets veilig. Ik had ook een Windows server en ik zag dat er continu mensen probeerden in te loggen. Helaas voor hen zijn mijn wachtwoorden extreem sterk en na een tijdje zag ik het steeds minder worden.

Is het niet zo dat je na een x aantal keren foutieve login een delay krijgt? Dat maakt brute-forcen volgens mij ondoenlijk.\

[Reactie gewijzigd door Verwijderd op 22 juli 2024 17:51]

[HollowGamer]

Altijd afgevraagd waarom mensen de RDP-poort direct openzetten, same voor SMB en/of poort 80/22.
Ookal doe je aan authentication, dan kan dit nog worden gebrute-force.
Waarom niet een VPN er tussen? Of gebruik op z'n minst whitelisting, al kan je deze in theorie ook spoofen.
Het ergste is dat dit ook gebeurd bij ervaren Systeembeheerders.

Edit:
Ja, je kunt SSH prima openzetten, echter dien je wel gebruik te maken van verschillende beveiliging/extra's: zie keys, Fail2ban, Google Authenticator, etc.
Helaas leert doorgaans de praktijk dat dit niet gebeurd.

Om eerlijk te zijn weet ik niet de huidige beveiligingsmethodes bij RDP/VNC, maar vind ik niet dat deze rechtsstreeks benaderbaar moeten zijn over het WAN. Daarvoor zet je beter eerst een VPN op als eerste laag en/of maak je gebruik van een andere tussenlaag/auth.

[Reactie gewijzigd door HollowGamer op 22 juli 2024 17:51]

[HunterPro]

RDP is anno nu minstens zo veilig als SSH. Dus wordt't op dezelfde manier ingezet - heel veel linuxbeheerders doen ook niets anders dan een sshd installeren en publiek serveren, ook al gebruiken ze geen sshkey maar gewoon wachtwoorden om in te loggen, en je wil niet weten hoeveel er remote root toestaan. RDP kun je even slecht toepassen en even goed (netjes met certificates, etc).

[Mathieu_Hinder]

Wat is er mis met specifiek remote root? Ik versta hieronder root worden over ssh (aangezien je misschien iets anders bedoelt). Vaak heb je geen andere mogelijkheid.

[Noxious]

Hij bedoelt over SSH direct kunnen inloggen als root.

Het weten van de username (in dit geval root) maakt het bruteforcen een stuk eenvoudiger.

In vrijwel iedere moderne Linux distributie is dit by default uitgeschakeld, ook wordt er aangeraden om geen root password in te stellen, zodat root alleen bereikbaar is dmv sudo.

[fvdberg]

maar er zijn ook voldoende technieken om brute forcen tegen te gaan.denk aan fail2ban of ConfigServer Security & Firewall

maar ook zonder toeters en bellen kan je "gewoon" vanuit de iptables leuke dingen doen.

bijvoorbeeld dit:

# ssh - drop any IP that tries more than 10 connections per minute
-A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
-A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 11 -j DROP
-A INPUT -p tcp --dport 22 -j ACCEPT

Beetje een christelijk wachtwoord er op die nooit te raden/genereren is en ik zie geen enkele reden waarom een root account niet over ssh open zou mogen staan. su do is ten slotte ook slechts een tussenstap..

[Reactie gewijzigd door fvdberg op 22 juli 2024 17:51]

[Jerie]

Een gebruikersnaam is een identificatiegegeven en mag nooit onderdeel zijn om brute force tegen te gaan. Programma's die rate of connection limiting toepassen of bij X aantal failed authentication overgaan tot (tijdelijk) onmogelijk maken inloggen werken daarentegen beter. Ook kun je services alleen toestaan over Tor (hidden services) en ze zelfs achter een authenticatie zetten waardoor je zonder die sleutel te hebben niet eens zult weten dat er een hidden service draait.

[CH4OS]

HunterPro bedoeld inloggen als root remotely. Dus niet su of sudo nodig zijn.

[P1nGu1n]

Zou je uit kunnen leggen wat het gevaar is van het openzetten van poort 80?

[HollowGamer]

Hiermee doelde ik op webservers die doorgaans niet over het internet hoeven open te staan (kan ook over een andere poort natuurlijk).
Vaak draait deze dan een veroude webserver/PHP/PHPMyadmin waardoor je 'eenvoudig' kunt inbreken met een script (zie GitHub voor scripts ).

[Reactie gewijzigd door HollowGamer op 22 juli 2024 17:51]

[xleeuwx]

Doordat met lui is en systeembeheerder die denken als ik een IP al niet kan onthouden wie kan er dan wel bij.

[Jerie]

Ik denk dat het gaat om zwakke wachtwoorden. Je hoeft echter met Chrome RDP al niet eens meer te port forwarden.

Verder is het een kwestie van sshguard of fail2ban of iets als IPT/PF goed instellen.

[Verwijderd]

Als vpn geen optie is (vraag me niet waarom) dan kun je rdp wel dermate beveiligen dat brute forcen niet werkt. Simpelweg een account voor x uur vergrendelen na x foutieve pogingen zorgt er al voor dat brute forcen een stuk langer duurt of zelfs onmogelijk wordt. Ook natuurlijk nooit de administrator rdp rechten geven (bij voorkeur zelfs administrator account uitschakelen), want dat is de eerste account die ze proberen.

Oh en natuurlijk nooit de standaard tcp 3389 poort gebruiken.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 17:51]

[Tribits]

Ik betwijfel eigenlijk of die opmerking uit het artikel met betrekking tot brute forcen sowieso wel klopt. In het bronartikel lees ik er ondanks zorgvuldige analyses niets over terug. Bovendien zal ook de gemiddelde Windows RDP server doorgaans wel bepaalde maatregelen hebben tegen brute forcen. De optie dat deze accounts bemachtigd worden door (externe) clients die met malware besmet zijn lijkt me eigenlijk een stuk waarschijnlijker.

[TWyk]

Is er geen detectiemethode voor die gehackte servers zodat ik kan kijken of mijn server gehackt is of niet?

[Reactie gewijzigd door TWyk op 22 juli 2024 17:51]

[LankHoar]

Gebruik jij een RDP server dan?

Het gaat om gehackte Remote Desktop Protocol-servers, die veelal populaire consumentenwebsites en ‑diensten hosten, volgens SecureList.

[TWyk]

Mischien is mijn thuiscomputer met een Windows pro versie wel een een RDP server...

[Tribits]

Die kan normaal gesproken maar 1 sessie tegelijk aan, dus dat merk je snel genoeg. Los daarvan denk ik niet dat de gemiddelde Windows Pro thuisinstallatie zo interessant is voor dit soort handelaren.

edit: Bron artikel geeft dan wel weer aan dat ze gehackte servers ook patchen om meerdere RDP sessies mogelijk te maken, dus in dat geval zou het dan wel weer onopgemerkt kunnen blijven.

[Reactie gewijzigd door Tribits op 22 juli 2024 17:51]

[Verwijderd]

Dan voer je een portscan via GRC uit op TCP poort 3389. De standaard RDP poort.
https://www.grc.com/x/ne.dll?bh0bkyd2

[The Zep Man]

Mischien is mijn thuiscomputer met een Windows pro versie wel een een RDP server...

Misschien is mijn thuiscomputer met Linux wel een RDP server.

Sowieso is het een kwalijke ontwikkeling als RDP direct op Internet wordt aangeboden. Het is zo dicht verbonden aan de kern van het besturingssysteem (in het geval van Windows) dat dit gewoon vragen is om ellende. SSH is veiliger, maar zelfs dat kan je met alle andere remote diensten gewoon beter benaderen via een VPN, waarbij de endpoints speciaal zijn ontwikkeld om in een kwaadaardige omgeving te functioneren.

[batjes]

Bij zowel SSH als RDP is het afhankelijk van de configuratie hoe veilig dit is, de ene is niet veiliger of onveiliger als de ander.

En bij RDP als minpunt gebruiken dat het "dicht verbonden aan de kern van het besturingssysteem", en dan SSH wel aanraden.

Beide kan je veilig aan het internet hangen wanneer je dit goed configureert, en bij beide is voor "echte veiligheid" het aan te raden dit enkel toe te staan binnen een VPN.

[Verwijderd]

hoeft geen rdp te zijn. het kan ook een lekke wordpress site zijn geweest op waarop men toegang verkreeg.

Het beste om een Unix server te scannen op malware / hacks is o.a met maldetect - als je server zelf geinfecteerd is dan is het altijd aan te raden alles op te ruimen en 'schoon' te beginnen.

Hacks vallen meestal pas op wanneer de 'overlast' begint zoals met de verkoop van logins van je server.

[kritischelezer]

TCP port 3389 gesloten hebben, of alleen op vertrouwde IP "open" hebben.

Lijkt me zowiezo handig dat alle poorten dicht zijn, behalve welk echt nodig zijn.

Een goed middel om onregelmatigheden te detecteren is het overzicht van je data verbruik te bekijken en te vergelijken met oudere gegevens.

[A-star]

vraag ik me ook af nu.

[secury]

reactief: kijk in de logging of je activiteit ziet vanaf plekken waar je het niet verwacht, of op momenten waarop je het niet verwacht, of acties die je niet wilt.

proactief: blok RDP direct vanuit buiten, laat het alleen toe via VPN als het van buiten moet.
forceer multi factor authentication etc etc etc.

[JohanNL]

En zodoende is het voor iedereen mogelijk met geld om goed georganiseerde DDOS aanvallen te plegen

[Tribits]

Ik denk niet dat deze accounts daar erg geschikt voor zijn. Op zich zullen de meeste servers wel over aardig wat bandbreedte beschikken, maar het zijn waarschijnlijk ook systemen waar je al vrij snel op zult vallen als je een DDOS aanval uit gaat voeren. Los daarvan gaat het om losse accounts dus zal je zelf nog wel wat werk moeten doen om er een distributed DOS aanval van te maken. Aangezien er ook partijen zijn die je dergelijke 'diensten' kant en klaar leveren lijkt het gebruik van dit soort diensten daarvoor niet de meest voor de hand liggende optie.

edit: Het artikel vermeldt dat de accounts gebruikt kunnen worden om aanvallen uit te voeren, uit het bron artikel van SecureList wordt echter duidelijk dat daarmee gedoeld wordt op het aanvallen van de IT systemen van de organisatie waar de RDP server deel van uitmaakt.

[Reactie gewijzigd door Tribits op 22 juli 2024 17:51]

[supersnathan94]

maar het zijn waarschijnlijk ook systemen waar je al vrij snel op zult vallen als je een DDOS aanval uit gaat voeren

Als het gaat om systemen van overheden en Universiteiten dan denk ik eerder van niet. Het is namelijk heel normaal dat er ineens 300-500 requests verstuurd worden naar 1 en dezelfde site en een luttele seconde. Een paar honderd extra zal niet opvallen en zelfs met enkele duizenden requests denk ik niet dat er zomaar iets gebeurd. Maak daarbij gebruik van amplification en je bent rustig een aantal GB/s aan het genereren als je het goed doet. En dat voor een paar euro's.

[Tribits]

Als je een aanval op een extern systeem inzet zal dat doorgaans gedurende langere tijd duidelijk andere activiteit opleveren dan normaal gebruik. En aangezien dergelijke gerenommeerde organisaties veelal ook software hebben draaien die dat soort ongebruikelijke patronen detecteert is er een goede kans dat je DOS aanval al snel opvalt. Dat soort detectie systemen zijn vrij essentieel in het opsporen van allerlei onbekende malware en ander misbruik. Los daarvan zal je het IP adres moeten spoofen want anders ligt er natuurlijk binnen no time een mailtje bij de beheerder of zal het slachtoffer je blocken. Het 'mooie' van een botnet is nu net dat je al die nadelen niet hebt.

[unglaublich]

Dat kon natuurlijk al lang. Cloud-computing diensten zoals Azure en AWS zijn daar eenvoudig voor te gebruiken.
Voordeel hiervan is dat het meer anoniem is en je sommige instanties kunt infiltreren.

[mhnl1979]

Tja. handig al die opmerkingen bovenin. Maar er zijn genoeg mensen die gewoon een NAS hebben en niet 100% de kennis hebben omdat allemaal goed te zetten.(incluis mijzelf) Maar dat er organisaties zijn met professionele ICT-ers die dat niet in orde hebben is wel verontrustend.

[fvdberg]

Mensen die deze kennis niet hebben worden vanzelf afgesloten door de abuse afdeling van hun provider, en worden daarmee geforceerd om of de nas niet open te zetten naar het internet, de nas uit te schakelen of zich in te lezen en een afdoende beveiliging te implementeren. de NAS is in mijn optiek dan ook niet voor gewone gebruikers geschikt. of dienen door een bekwaam persoon geconfigureerd te worden.

[Reactie gewijzigd door fvdberg op 22 juli 2024 17:51]

[mhnl1979]

Maar wat vindt jij dan voldoende kennis? Ik heb nog nooit gehoord dat de abuse afdeling mensen forceren de NAS uit te zetten.

[fvdberg]

nee dat doen ze ook niet, ze sluiten gewoon de gehele internet verbinding af.
en voldoende kennis? het blijft een Linux server en enig besef van waar je mee bezig bent lijkt me niet te veel gevraagd

[mhnl1979]

Sorry, heb ik echt nog nooit van gehoord. En gezien de grote populariteit van de Nassen tegenwoordig zou dat echt wel meer genoemd worden lijkt me. Sowieso zouden ook NAS leveranciers als Qnap en Synology daar in hun 1 klik configuratie ook iets in moeten noemen. Lijkt me dus behoorlijk kort door de bocht.

[fvdberg]

het verleden leert dat dat niet zo is. cve's genoeg maar ook actief misbruik. er is zelfs ransomware actief geweest die zo naar binnen liep op de synology. ik zou echt eens Googlen voor je roept dat het te kort door de bocht is.

[mhnl1979]

Van die synalogy firmware weet ik inderdaad. Maar als je je firmware gewoon update was ook dat geen punt. Maar zal eens googlen :-)

[iTeV]

Wat ik niet in het artikel lees, is deze forum via het "normale" web toegangbaar?

[fvanottele]

Jazeker, een stukje uit de PDF:

"The marketplace is located at the domain xdedic[.]biz and anyone can register to use it. New members
need to use their account within 72 hours of registration, otherwise the account is automatically
removed unless they pay a fee of 10 USD."

[svennd]

https://xdedic.biz

[Deem]

Lijkt me niet verstandig om de link te bezoeken. Ik sluit niet uit dat ze IP adressen sparen voor portscans.

[fvanottele]

Dat lijkt mij ook niet, daar registeren met een username & wachtwoord combinatie die je op andere websites gebruikt al helemaal niet.

[svennd]

Je kunt het hele net afspeuren in enkele uren, waarom zouden ze daarvoor ip's saven... in tegendeel, potentiële klanten willen ze wss liever niet hacken.

Overigens is het forum het platform, niet de criminelen zelf, althans dat willen ze toch laten geloven.

[fvanottele]

In het gepubliceerde PDF bestand laat kaspersky het toch wel anders lijken, scam websites, viagra websites en carding websites..

[fvanottele]

Ookal draai ik geen RDP server, toen ik mijn web server net had opgezet had ik ook veel last van brute force attempts via ssh, nadat ik mijn fail2ban filter heb aangepast heb ik er gelukkig geen last meer van gehad:).

[Iken374]

Prachtig al die 'specialisten' hier. Nederland zit er echt vol mee.

[Nees]

Ik verander de default port altijd op elke PC ivm RDP. Dat helpt ookal bij scans op bepaalde poorten.

[Deem]

Security through obscurity is geen security

[Tijder]

Mischien niet maar het voorkomt wel veel bruteforce pogingen.

[unglaublich]

Gewoon public-key authenticatie only gebruiken. Een goede SSH key van bijv. 4096 bit maakt brute-force praktisch onmogelijk. Zo'n sleutel heeft een equivalente sterkte als een 580 tekens lange willekeurige reeks van ASCII tekens (7bit).

[Deem]

Zijn eenvoudigere methodes voor om Brute force tegen te gaan. Je kunt bijvoorbeeld een lockout threshold instellen.

Na 3 pogingen het account 30 minuten locken.

https://technet.microsoft...account-lockout-threshold

[relativity]

Ikzelf heb ssh alleen binnen mijn eigen netwerk draaien en is alleen benaderbaar (vanaf buiten) via vpn. Daarnaast heb ik ook nog fail2ban aanstaan die iemand voor een jaar bant als hij 4x verkeerd inlogt.

Wachtwoord is complex en lang. Wat kan ik verder nog doen?

[SampleUser]

Alleen authenticeren met PKI sleutels en als last resort een 40 tekens lang wachtwoord met combi van letters (HOOFD + klein) en speciale karakters.

[relativity]

Argh... maar als ik dan op vakantie ben moet ik dus die sleutels overal meenemen?

Alhoewel ik dat nu ook heb met mijn vpn maar goed.