Hackers installeren backdoors op ASUS-routers die firmware-updates overleven

Cybercriminelen voorzien duizenden ASUS-routers van persistente achterdeurtjes. Daardoor blijft de achterdeur ook aanwezig na een herstart van het apparaat en na firmware-updates. De campagne richt zich op routers voor thuisgebruik en kleine kantoren.

De aanvalscampagne werd in maart ontdekt door beveiligingsbedrijf GreyNoise. De aanvallers gebruiken bruteforcing en kwetsbaarheden die al van een patch voorzien zijn om binnen te komen. Het gaat onder meer om CVE-2023-39780. Dat is een commandinjectionfout, waarmee aanvallers eigen commando's kunnen uitvoeren op het systeem. Maar het gaat ook om kwetsbaarheden die nooit een CVE-nummer hebben gekregen. Eenmaal binnen wordt een publieke encryptiesleutel geïnstalleerd om via SSH toegang te krijgen tot het apparaat. Daarna kan iedereen die de bijbehorende privésleutel heeft met admin-rechten inloggen op het apparaat.

De achterdeur wordt opgeslagen in NVRAM, waardoor deze niet wordt verwijderd tijdens firmware-upgrades of als het apparaat opnieuw wordt opgestart. Bovendien wordt er geen malware geïnstalleerd en wordt de logging uitgezet, zodat detectie wordt vermeden, aldus GreyNoise.

Volgens de beveiligingsonderzoeker zijn zeker 9000 ASUS-routers getroffen door de aanval. Dat aantal blijft groeien. De onderzoekers vermoeden dat er een groot aantal gecompromitteerde apparaten verzameld wordt voor toekomstig gebruik. Vooralsnog zijn er geen signalen dat de nu getroffen routers al ingezet zijn bij andere activiteiten. Ars Technica stelt dat de campagne zich richt op routers voor thuisgebruik en kleine kantoren.

Wie er achter de aanval zit, is niet bekend. Maar de tactieken die gebruikt worden, doen volgens GreyNoise denken aan onder meer staatshackers. "Hoewel GreyNoise de aanval niet aan een groep heeft toegekend, wijst het niveau van vakmanschap op een tegenstander met voldoende middelen en grote bekwaamheid." Hoewel de campagne al in maart ontdekt werd, besloot GreyNoise met zijn berichtgeving te wachten tot ASUS bepaalde overheidsorganisaties op de hoogte had gesteld. Om welke organisaties het gaat, is onbekend.

GreyNoise geeft in zijn blog aan hoe gebruikers kunnen controleren of hun router getroffen is. Daarbij moet gecontroleerd worden of er SSH-toegang is via TCP/53282. Blijkt dat de router gecompromitteerd is, dan moet deze teruggezet worden naar de fabrieksinstellingen en handmatig opnieuw geconfigureerd worden, aldus GreyNoise.

Door Eveline Meijer

Nieuwsredacteur

29-05-2025 • 11:12

93

Submitter: SpoinkyNL

Reacties (93)

93
92
48
5
0
32
Wijzig sortering
Volgens de CVE-2023-39780 gaat het alleen om de
https://cve.mitre.org/cgi...e.cgi?name=CVE-2023-39780
ASUS RT-AX55 3.0.0.4.386.51598
Maar meestal is firmware code over veel devices grotendeels gelijk.
Ik zie op mijn RT-AX55 - 53119
En SSH staat op Lan en Wan?
Als je dat niet zelf ingesteld hebt ben je 1 van de slachtoffers.

Standaard staat SSH op "Lan only" en is de SSH poort 22.
Interessant, bij mij stond het out of the box op off.

Net maar eens nagekeken, staat nog steeds op off gelukkig.

Maar wij hebben een GT-AX6000 dus of deze last heeft van deze backdoor weet ik niet.

[Reactie gewijzigd door Mizgala28 op 29 mei 2025 12:38]

Van een gehackt device kan je de settings niet meer geloven. Onder die grafische schil kunnen andere dingen gebeuren. Just my 2 cents.
Ja bij mij stond het ook off, waarschijnlijk met quick setup uitgeschakeld een keer.
Mijn router is ssh uit en indien aangezet na 20 min auto uit.
3.0.0.4.386_51967 en update automatisch.
Verder gebruik ik deze router als subnet achter een kpn router. Mijn wifi netwerk is ook een subnet. Tevens staan alle poorten dicht op de Asus.
Als ik hier kijk,
https://drivers.softpedia...ASUS%20RT-AX55%20Firmware
zie ik daar al 7 versies na de bewuste firmware, dus daar kan het best opgelost zijn. Maar mocht je besmet zijn heeft dat niet meer geholpen. IK heb even de readme's van de firmwares daar gelezen, maar daar wordt betreffende CVEniet genoemd.
Je zou inderdaad denken dat dit het geval is, maar bij de ASUS routers is die niet gelijk. Ze hebben een base, maar die verschilt per serie. Er is dus geen algemene firmware (helaas).

Schrik er wel van, misschien is dit wel de push die ik nodig heb om weg te gaan.
De campagne richt zich op routers voor thuisgebruik.
Hoewel de campagne al in maart ontdekt werd, besloot GreyNoise met zijn berichtgeving te wachten tot ASUS bepaalde overheidsorganisaties op de hoogte had gesteld
Dan komt bij mij de vraag op, waarom worden apparaten bedoeld voor thuis gebruik, gebruikt bij overheidsorganisaties?
"Op de hoogte brengen" is iets anders dan daadwerkelijk gebruiken. Hoewel het niet duidelijk is of er persoonlijke data is gestolen, zal de AI en mogelijk de AIVD eerst op de hoogte zijn gesteld.

De overheid kan wel kwetsbaar worden, want er zullen ongetwijfeld thuiswerkers zijn die een gehackte router gebruiken.
Maakt in de praktijk nauwelijks iets uit, bijna alle routers bevatten kwetsbaarheden. Het is wel zo dat sommige fabrikanten veel proactiever zijn dan anderen.

Je kan wel veel doen om je router te beveiligen:

https://routersecurity.org/
Vind dit wel een aparte website, beweert je doodleuk om IPv6 uit te schakelen 8)7

Ben daarna maar gestopt met lezen, zo komen we er toch nooit als iedereen IPv6 uit gaat zetten..
Wat betreft IPv6, daar zijn voors en tegens. Hier zijn discussies over. Het is eigenlijk heel simpel, alles uitschakelen wat je niet gebruikt. De adoptie van IPv6 blijft achter en veel mensen gebruiken het niet.

Even een aanvulling:
Overigens wel flauw (en dit zie je meer) om aan cherry picking te doen (dingetje vinden die je niet bevalt) en dan gelijk de hele website af te schrijven. De man achter deze website is geen oliebol. Verweg het meeste wat hij schrijft snijdt wel degelijk hout.

[Reactie gewijzigd door NotWise op 30 mei 2025 11:53]

Klassiek kip-ei verhaal. Maar we zullen echt moeten.

IPv6 adoptie blijft achter omdat providers (*kuch* Odido *kuch*) weigeren IPv6 te implementeren.

Je gebruikt IPv6 automatisch als de provider hun netwerk op orde hebben en ze het modem firmware updaten dat de clients in het LAN dmv DHCPv6 een IPv6 krijgen aangeboden. Alle clients krijgen dan een publiek benaderbaar IP, maar daar is niks engs aan, je firewall op de router en de client zelf zorgen voor dat er geen ongewenst inkomend verkeer binnen komt.
Er is natuurlijk wel degelijk iets engs aan. Je hebt een barriere minder tussen het 'grote boze internet' en je client device. Dus je bent meer afhankelijk dat er geen lekken in je client zitten en dat je firewall goed werkt. Bij NAT is een niet zo goed werkende firewall of een niet-bijgewerkte client niet meteen heel erg.

Daar komt bij, dat we het nu zo gewend zijn. Ik zit er niet zo bovenop dat iedereen z'n telefoon altijd meteen update, want er zit toch wel NAT tussen. Ik begrijp dan ook niet, dat de ontwerpers van IPv6 niet in zoiets voorzien hebben. Je kunt prima met IPv6 hetzelfde doen als nu met IPv4 en een intern IPv6 netwerk binnen je huis/kantoor/bedrijf hebben, dat wel volledig gescheiden is van het echte internet. Maar toch zit dat in geen enkele router die ik ken.

Daarnaast hebben we nog een ander argument: privacy. De Googles en Meta's van deze wereld vinden het natuurlijk machtig interessant om te weten welke apparaten jij in huis hebt. Door alle apparaten hun eigen ip-adres te geven, is dat veel makkelijker te onderscheiden. Als alles achter NAT zit met dynamisch veranderende poortnummers, dan is dat lastiger.

Dus er zijn wel degelijk goede redenen om vast te houden aan IPv4. Het is niet houdbaar, dat snap ik wel, maar ik snap ook dat er mensen zijn die het wel willen.
Ben het wel met je eens. Het meeste wat ik over IPv6 (vele jaren geleden) heb geleerd is inmiddels al weer weggezakt. Maar ik ben nog altijd van mening dat, als je dingen niet gebruikt, (omdat je bijv. je hw of provider het niet ondersteund) je het vaak het beste kan uitzetten. Zeker gezien de brakke firmware van veel verouderde routers.

https://threatpicture.com/blog/why-disable-ipv6/

Er zijn hele discussies over als je gaat Googelen.

Maar ik ben het volledig met je eens w.b.t. adoptie. De providers zijn niet echt bezig om dit pushen.
In plaats van stoppen met lezen zou je dan juist hun argumentatie moeten lezen waarom ze dat adviseren.

Maar ja, dat is blijkbaar teveel moeite in de huidige maatschappij.
Nou goed nieuws, die heb ik gelezen! En er word verwezen naar een obscure IPv6 feature die sommige routers of devices (incorrect?) gebruikte waardoor je locatie op de wereld mogelijk vrijgegeven word.

Beetje slap excuus imo

De vraag is, heb jij m gelezen?

[Reactie gewijzigd door smiba op 30 mei 2025 20:40]

Ik ben verantwoordelijk voor een paar duizend Linux servers waarbij we overal IPv6 hebben uitgeschakeld. Net als kernel-modules als CramFS en andere zooi die we niet gebruiken.

Waarom? Heel simpel, als je het niet gebruikt dan hoeft het ook niet aan te staan. En bij voorkeur nieteens geïnstalleerd.

En meer specifiek over IPv6, voor ons bedrijfsnetwerk hoeft die transitie niet zo nodig. Intern gebruiken we een private IPv4 reeks en kunnen daarmee prima uit de voeten. Extern zien we het nut wel en zijn de websites met zowel IPv4 als IPv6 benaderbaar.

Bedenk ook dat IPv6 bedacht is met het idee om elk apparaat ter wereld een uniek adres te geven. Een leuk en nobel streven, maar ik zie daar totaal geen voordelen aan. Wel genoeg nadelen overigens. Een van de belangrijkste nadelen is dat NAT niet nodig is met IPv6 en daarmee een belangrijke scheiding tussen intern en extern wegvalt. Natuurlijk gebruikt je router doorgaans een firewall maar het is toch wezenlijk anders.

Het is niet dat IPv6 nutteloos is, want het lost wel degelijk het probleem op met het wereldwijde tekort aan IPv4 adressen. Alleen of dat dan moet op een manier dat ook al mijn apparaten verplicht een uniek adres nodig hebben…?
Het is niet dat IPv6 nutteloos is, want het lost wel degelijk het probleem op met het wereldwijde tekort aan IPv4 adressen. Alleen of dat dan moet op een manier dat ook al mijn apparaten verplicht een uniek adres nodig hebben…?
Het voordeel aan elk apparaat een IPv6 geven die publiekelijk is, dat je geen (dure) NAT translation meer hoeft te doen. Het voordeel van een NAT is ook eigenlijk alleen dat je minder publieke IP adressen gebruikt, maar omdat IPv6 absoluut genoeg heeft is hier geen enkele logische redenen voor. Als het om firewalling gaat, kan dit nog steeds namelijk

Het uitschakelen van IPv6 is voor mij eigenlijk echt een alarmbel van iemand die niet competent is, zelden (eigenlijk nooit) zie ik redenen om het uit te schakelen omdat het positief bijdraagt aan de transitie naar IPv6 voor het internet in het algemeen. De redenen die ik hoor zijn vaak allemaal redenen die of niet relevant (meer zijn), een setting is of iets simpels als een firewall

[Reactie gewijzigd door smiba op 31 mei 2025 18:32]

Dan ben ik maar incompetent. Maar bij mij is het juist een alarmbel als mensen het perse aan willen zetten zonder te kijken naar de situatie.

Zo heb ik in al de jaren dat ik in het vak zit al zo vaak gezien dat progressie enkel om de progressie vaak uitdraait op een fiaso. Helemaal als die wordt gestuurd door managers die niet gehinderd zijn door enige technische kennis.

Bij IPv6 heeft men onderschat (of bewust de afweging gemaakt) om met een schone lei te beginnen en de adressen belachelijk lang te maken. Hoewel je dat als netwerkbeheerder prima behapbaar kunt segmenteren door te zorgen dat je kleine (IPv4 size) subnets houdt en het eerste deel van het adres zoveel mogelijk gelijk houdt, schrikt de adreslengte al veel mensen af. En het gebruik van verschillende adrestypen en meerdere methodes voor dynamische adressen maakt de leercurve almaar steiler. Dat is wat mij betreft een van de belangrijkste redenen voor het trage verloop van de transitie. En IPv6 is helemaal niet zo moeilijk… maar zo lijkt het wel.

De andere oorzaak is inderdaad dat er weinig noodzaak voor is. Zolang we met z’n allen de belangrijkste websites nog over IPv4 kunnen benaderen dan hoef ik niet zo nodig IPv6 te gebruiken. En, zoals gezegd, het staat bij ons ook uit. Maar al zou ik het aanzetten kom ik niet eens van het subnet af; ook in het netwerk staat het uit.

Maar als belangrijke websites of diensten morgen met IPv4 stoppen dan heb ik vandaag voor EoB IPv6 draaien op de servers die daar van afhankelijk zijn. En wellicht is ons netwerkteam dan ook zo rap.

Echter zie ik dat niet zo snel gebeuren en ga ik niet het risico lopen om IPv6 aan te zetten zonder de wetenschap dat AL mijn collega’s mee zijn op die boot en hun kennis adequaat genoeg is.

Dat laat ik liever over aan bedrijven vol met jonkies die net uit de schoolbanken kopen en tijdens hun opleiding (hopelijk) op een of meerdere toetsen zijn doorgezaagd over IPv6. Er komt vanzelf een punt dat we mee moeten. Maar ik heb daar geen productieverstoring of andere risico’s voor over.
Kende deze website niet. Staan zeer veel goede tips op. Must read voor iedereen. Dank!
Dan komt bij mij de vraag op, waarom worden apparaten bedoeld voor thuis gebruik, gebruikt bij overheidsorganisaties?
Waarschijnlijk niets. ;)
Maar waarschijnlijk moeten overheidsorganisaties, die over cybersecurity gaan, op de hoogte worden gebracht.

[Reactie gewijzigd door LooneyTunes op 29 mei 2025 16:08]

Die overheidsorganisaties kunnen natuurlijk intern een plan maken hoe ze dit zullen aanpakken voor consumenten. Betekend niet direct dat de overheid deze routers zelf gebruikt.
Welkom in de wereld van thuiswerken.
Wat jezelf met een router beschouwd is veilig zijn vanaf het internet. Maar voor de meeste (en zeker thuis gebruik) is dat ook direct de koppeling met het thuis netwerk.
Het staat hackers dan ook vrij om verder te kijken wat er aan te vallen is. En of dat nou een overheidsmedewerker is de lokale stratenmaker wat weten ze van te voren ook niet.
Zodat he signal kan gebruiken in het pentagon. Zoiets misschien?
[...]
Dan komt bij mij de vraag op, waarom worden apparaten bedoeld voor thuis gebruik, gebruikt bij overheidsorganisaties?
Een antwoord met wat aannames maar ...
Ik vermoed dat de opsporende overheidsorganisaties worden bedoeld die dan waarschijnlijk weer hebben onderhandeld over het publiceren van dit lek zodat ze tijd hebben om te kijken wie er achter zit \ kijken hoe ze het zelf kunnen gebruiken \ hun eigen sporen nog kunnen uitwissen *

* streep door wat niet van toepassing is u het liefste leest.

[Reactie gewijzigd door bastro op 29 mei 2025 11:35]

Dan komt bij mij de vraag op, waarom worden apparaten bedoeld voor thuis gebruik, gebruikt bij overheidsorganisaties?
Dat staat nergens vermeld.
Er staat dat beveiligingsbedrijf GreyNoise, pas nadat het overheidsorganisaties heeft verwittigd, hier publiek over heeft bericht.

[Reactie gewijzigd door Baserk op 29 mei 2025 11:46]

Asus heeft ook een serie routers voor zakelijke klanten. Gebruiken voor een groot deel zelfde software.
Misschien verwachten ze dat die doelwit worden van een eventuele aanval? Of willen ze informeren wie ze denken dat er achter zit.? Hoeft niet te gaan over dat die overheden asus gebruiken..
"De overheid" is natuurlijk een heel grof, ongenuanceerd begrip. Ik mag hopen dat er met veiligheidsniveaus wordt gewerkt. Kerncentrales zullen nou eenmaal beter beveiligd zijn dan een vacature website. En communicatie binnen defensie een stuk beter dan de website van de lokale afvaldienst.

In het kader van kosten/baten zou ik het wel wenselijk vinden als er voor systemen in de categorie 'nuttig maar niet noodzakelijk' kant-en-klare (en dus goedkopere) hardware wordt gebruikt.
Mijn SSH staat standaard uit. Dus zou goed moeten zijn. Maar hoe check ik niet gehackt ben? Oftewel welke commando’s moet ik gebruiken in terminal?
idd checken dat SSH op WAN uitstaat onder Administration, tabje System
En zorg dat je remote access op WAN op No staat; dat is echt een no-go

verder kun je checken of de log file bestaat en of de keys file de sleutel bevat (zelf inloggen met putty op een port die je openzet voor SSH op je LAN only)
zie https://www.labs.greynoise.io/grimoire/2025-03-28-ayysshush/

ASUS Filesystem:

/tmp/BWSQL-LOG
/tmp/home/root/.ssh/authorized_keys

Pubkey:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAo41nBoVFfj4HlVMGV+YPsxMDrMlbdDZJ8L5mzhhaxfGzpHR8Geay/xDlVDSJ8MJwA4RJ7o21KVfRXqFblQH4L6fWIYd1ClQbZ6Kk1uA1r7qx1qEQ2PqdVMhnNdHACvCVz/MPHTVebtkKhEl98MZiMOvUNPtAC9ppzOSi7xz3cSV0n1pG/dj+37pzuZUpm4oGJ3XQR2tUPz5MddupjJq9/gmKH6SJjTrHKSECe5yEDs6c3v6uN4dnFNYA5MPZ52FGbkhzQ5fy4dPNf0peszR28XGkZk9ctORNCGXZZ4bEkGHYut5uvwVK1KZOYJRmmj63drEgdIioFv/x6IcCcKgi2w== rsa 2048

[Reactie gewijzigd door R1 op 29 mei 2025 12:07]

Blijkt dat de router gecompromitteerd is, dan moet deze teruggezet worden naar de fabrieksinstellingen en handmatig opnieuw geconfigureerd worden, aldus GreyNoise.
Je kan de configuratie van een Asus router exporteren vanuit de firmware web-ui. Hiermee kan je een restore van de settings doen na factory-reset of upgrade nieuwe router. Er zijn scripts om het .CFG backup bestand te decoderen naar een tekst bestand zodat je de settings kan inzien of vergelijken met eerdere settings.

[Reactie gewijzigd door ajbu op 29 mei 2025 11:43]

Maar aangezien de backdoor zich nestelt in de NVRAM, is de backdoor dan ook daadwerkelijk van de router verwijderd? Of pak je hiermee alleen de symptomen aan?
Maar aangezien de backdoor zich nestelt in de NVRAM, is de backdoor dan ook daadwerkelijk van de router verwijderd? Of pak je hiermee alleen de symptomen aan?
Volgens GrayNoise wordt de backdoor verwijderd door een factory-reset. In het ideale geval heb je een eerdere backup die je kan terugzetten na de factory-reset waarmee de backdoor verwijderd is. Wat ik zelf eerder heb gedaan bij een eerder ander probleem is (1) settings exporteren (2) factory-reset (3) settings van na de factory-reset exporteren (4) de-obfuscate export files en met text-diff tool verschil tussen mijn eigen settings en de factory-default controleren.
Dit zal voor veel mensen te veel moeite zijn en is handmatig opnieuw instellen het beste te begrijpen
Het word afgeraden om een restore van de settings te doen die gemaakt zijn met een oudere firmware!
Word in de router niet voor gewaarschuwd maar is in het verleden de oorzaak geweest van menige gremlin en instabiliteit in Asus routers.
Als ik een factory reset doe maak ik eerst een screenshot van alle instellingsschermen en doe dan de reset, dit is onder tussen mijn 4e Asus router en gebruik de Merlin firmware.
Je kan dat als fabrikant ook gewoon een keer oplossen... het is maar een text file en zoveel veranderen die instellingen ook niet. Deed ik in het jaar 2000 al met de software die in gratis online zette 🤷‍♂️
Het is niet zomaar verstandig om toch een kopie van de instellingen terug te zetten. Het advies om het handmatig te doen geven ze waarschijnlijk niet voor niets. Er zijn namelijk ook de opmerkingen gegeven dat de malware niet zomaar van een besmet apparaat af is en ook gebruik maakt van gebruikelijke configuratie-opties.

Als je van een besmetting af wil komen dan zul je genoeg controle moeten hebben over het apparaat. Bewust zelf handmatig het apparaat instellen geeft meer controle dan simpel een backup terugzetten waarvan onduidelijk is wat deze allemaal terug zet.

Als iemand dan toch de configuratie wil terugzetten dan kan die er maar beter zeker van zijn precies te weten wat de inhoud van de backup van de configuratie precies voor betekenis heeft.
offtopic:
Je moet een router ook niet aan het internet hangen! Oh wacht ;)
Maar het gaat ook om kwetsbaarheden die nooit een CVE-nummer hebben gekregen.
Dit is eigenlijk het meest choquerende van het artikel.


Dit stukje misbruik is dus duidelijk een stuk verkeerd ontwerp.

Op de eerste plaats is niet een apparaat 100% veilig en kunnen er overal fouten gemaakt worden. Maar hier zie je ook heel duidelijk een ontwerpfout. Hoe kan het zijn dat een actieve publieke sleutel onbeheerd geplaatst en behouden kan blijven. Idealiter forceert de managementsoftware op de router dat bij een reboot alle actieve sleutels opnieuw gezet worden. Ofwel. Die sleutels hebben niets te zoeken op die plaats van het NVRAM-stukje. De sleutels zouden dus alleen 'permanent' in de configuratiedatabase bestaan, en bij een reboot moeten ze daar vandaan opnieuw gezet worden.

Idealiter doe je met 'al' je instellingen (dus dat een reboot eigenlijk een soort factory-reset is, die vervolgens zichzelf opnieuw provisioned met de officiële configuratie. Dit maakt het in elk geval zichtbaar wat er allemaal gebeurd. Ook zou er een grote waarschuwing op de interface moeten staan dat de logging is uitgezet. (afhankelijk van wat er precies mee bedoeld wordt, natuurlijk.)

[Reactie gewijzigd door lenwar op 29 mei 2025 13:05]

Je moet een router ook niet aan het internet hangen! Oh wacht ;)
Even zonder gekheid. SSH, FTP en HTTP(s) toegang over het internet naar je router zelf moet je _altijd_ uitzetten. Of met een firewall regel toelaten vanaf een vertrouwd IP. Een van de reden waarom ik altijd kies voor een prosumer router, dan heb je hier zelf volledig controle over en gebeuren er niet allerhande 'handigheidjes' onder water als je iets aanvinkt.

De incidenten rondom Fortinet geven aan dat zelfs de grotere spelers in deze markt ook niet immuun zijn voor veiligheidsproblemen. Dus de poort dichtmetselen en niet vertrouwen op het slot van de poort.
En dan ligt het er net aan hoe dit wordt geregeld of dit foutje dan ook niet misbruikt kan worden. (Als het effectief ACL is, dan 'kan' dat met die publieke sleutel gepasseerd worden. (Ligt er dus puur aan hoe het gedaan wordt. Als ze het blokkeren met firewall of dat ze domweg niet luisteren op de WAN-kant, helpt het natuurlijk wel.)

Maar in de basis is het inderdaad dat wel een goed idee. Wat in de praktijk ook al scheelt, is alleen Nederlandse IP-adressen toelaten. (Mits je de optie hebt)

Ik heb privé een VPS'je, waar ik dus 'remote' bij kan. Sinds ik alleen Nederlandse adressen toelaat, waren de hoeveelheid 'inlogpogingen' met ongeveer 95% gedaald. Voor de rest fail2ban. (Dus na een 3 mislukte pogingen een autoblock). Dit heb ik dus voor IMAP, HTTPS, SSH, SMTP, enz.

De meeste script-kiddies nemen blijkbaar niet de moeite om naar een Nederlands VPN-punt te gaan😊
Over het algemeen is de eerste connectie actie een soort wildcard vraag. Dus simpel gezegd "Een connectie vanaf IP X wil iets". Dat vang je meestal af door de firewall te laten starten met een deny-all op alle connecties. Dus alles wordt tegengehouden tenzij aangegeven. Sommige routers kan je ook instellen om juist te werken met een 'allow-all' maar dat is voor hele specifieke scenario's. Zeker niet voor productie gebruik. Onder water gebeurt we uiteraard wel wat meer zoals als je zelf al een sessie opent. Browse je naar een website dan is het ook wel handig dat er informatie terug kan komen. (gok dat je dit zelf ook wel weet maar is zeker niet bij iedereen bekend)

Als de connectie gemaakt mag worden dan wordt er pas gekeken naar een authenticatie actie met o.a. SSH keys, login tokens voor de webportal/FTP enz. De firewall is altijd leidend in een connectie keten, niet een bepaalde token voor een deel van de management interface. Dat zou ook echt niet best zijn.

Het zou je nog verbazen hoeveel VPN's misbruikt worden voor aanvallen vanuit het eigen land. De standaard poortscannertjes kan je er meestal prima mee tegengaan maar de bekende jongens uit bepaalde landen pakken het meestal toch iets serieuzer aan. Zeker gezien "NL-only" een vaak gebruikt/misbruikt punt is in veiligheid adviezen.
Ik ben er volledig mee bekend allemaal. :)

Het is voor mij ook primair dat ik helemaal kierewiet werd van compleet onleesbare logbestanden. 15000 inlogpogingen op niet-bestaande IMAP-accounts (of ssh-sessies van niet bestaande users enzo), idiote hoeveelheden http(s)-verzoeken naar bekende exploits in webapplicaties e.d. Gewoon irritant, en daar hielp die 'alleen Nederland' al heel erg mee.

Ik heb niet de illusie dat als iemand mijn VPSje echt wil pakken dat ik dan helemaal 'veilig ben'.

Ik heb over de jaren heen hele 'vreemde' constructies gezien om bepaalde dingen voor elkaar te krijgen. Soms gewoon netjes (firewall dicht, service laten luisteren op een specifieke interface, dat soort zaken), maar je wil niet weten hoeveel vage constructies ik voorbij heb zien komen met betrekking tot happy-flows.
Ik zou zeggen kijk is naar crowdsec ipv het aloude fail2ban. Crowdsec kan wat fail2ban kan en meer.
Ik heb hem nu een dagje gehad, maar ik ben niet erg te spreken over de interface. Ook het maken van eigen filters/controles vind ik vrij complex in verhouding tot fail2ban.

Het heeft uiteraard echt voordelen, zeker als je veel/meerdere nodes hebt, maar de gratis variant is in elk geval niks voor mij.

Maar in elk geval bedankt voor de suggestie!!
Het is ff wennen, maar ik ga niet meer terug :) To each his own!
Het is nauwelijks een backdoor te noemen, als ze binnen zijn maken ze gebruik van de reguliere SSH instellingen. Dat is ook de reden dat het een Firmware upgrade overleefd. Bij het terugzetten naar fabrieksinstellingen worden die SSH nstellingen weer op default gezet, standaard staat internet access uit.

Het paswoord word gebruteforced e/of gebruik gemaakt van oude bekende kwetsbaarheden, dat betekent dat inloggen vanaf de internet kant op de router aan staat 8)7, sorry maar dat moet je zelf aan zetten en is gewoon tegen elke security conventie in.
Als je vanaf buiten in wil loggen gebruik aub de VPN functie van de router. En nee SSH met keys etc. word afgeraden, er zijn in het verleden meerdere kwetsbaarheden in de webinterface geweest waardoor dit soort inbraken mogelijk waren, weet niet of er nu weer een nieuwe bij is gekomen maar het is in de SNB forums algemeen bekend dat de Asus webinterface een grote gatenkaas is.
Het paswoord word gebruteforced e/of gebruik gemaakt van oude bekende kwetsbaarheden, dat betekent dat inloggen vanaf de internet kant op de router aan staat 8)7
Nee. Het kan ook zijn dat een ander apparaat op het lokale netwerk gecompromiteerd is, en men vervolgens de gateway, wat de router zou zijn, gaat proberen aan te spreken door op dat adres poortnummers te proberen totdat er eentje een webinterface terug geeft. En als dat de ASUS webinterface is; hebbes.
Het is altijd een goed idee om SSH en Telnet niet te gebruiken als je het niet nodig hebt, uitzetten dus.

Verder heb ik met commando nmap
nmap -p 53282 192.168.10.1
of de poort nog open stond, en het gaf terugmelding
PORT STATE SERVICE
53282/tcp closed unknown
kan ik nu uitgaan dat mijn routers niet gehacked zijn?

[Reactie gewijzigd door D!rk op 29 mei 2025 12:22]

dit zegt iets over of de poort openstaat richting je local network, niet of de poort openstaat naar buiten toe.
om je systeem van buiten uit te laten checken gebruik ik altijd shieldsup.
https://www.grc.com/shieldsup
Zo had ik het niet bedacht, bedankt _/-\o_
Kwalijk, maar is dit lek al gepacht en vanaf welke versie is dit verholpen?

Asus heeft op zich een mooi semi open systeem maar daardoor is er uiteraard ook veel kennis over hoe deze uit te buiten aan de hand van een vulnerability. Straks maar eens kijken of onze routers al in het botnet zitten. En eens kijken of er dus al dan niet een patch voor is.

[Reactie gewijzigd door mjl op 29 mei 2025 13:36]

Blijkt dat de router gecompromitteerd is, dan moet deze teruggezet worden naar de fabrieksinstellingen en handmatig opnieuw geconfigureerd worden, aldus GreyNoise.
Maar is het probleem daarmee opgelost of kunnen ze de router weer voorzien van een backdoor met zelfde type aanval?

Want stel dat ik mijn router moet herstellen naar fabrieksinstellingen, en dit kan binnen no time met zelfde backdoor veroorzaakt worden.

Is het überhaupt wel een slim idee om een Asus router nog in gebruik te hebben?

Misschien lees ik overheen en is er al een patch uit, maar zo komt het niet voor mij over.
Ik koop altijd een router met openwrt ondersteuning.
Heb nu een ASUS RT-AX53U
In het algemeen heb ik het idee dat openwrt toch wat robuuster is tegen dit soort dingen.
En ssh van buiten uit toestaan lijkt heel handig, maar iedere open poort is een potentieel security issue.


Om te kunnen reageren moet je ingelogd zijn