Cybercriminelen nemen MikroTik-routers over via twee kritieke SSH-lekken

Cybercriminelen misbruiken twee onlangs bekendgemaakte kwetsbaarheden in routers van MikroTik. Daarmee kunnen de aanvallers apparaten overnemen waarvan de SSH-diensten via internet toegankelijk zijn.

Met een van de kwetsbaarheden, CVE-2026-67276, omzeilen aanvallers de authenticatie in Secure Shell (SSH), schrijft het Poolse CERT. MikroTik RouterOS controleert de publieke sleutels voor SSH-verificatie niet goed. Een aanvaller die een gebruikersnaam en de publieke modulus van een sleutel kent, kan daardoor een andere sleutel aanmaken en via SSH inloggen zonder dat hij de bijbehorende privésleutel heeft.

De tweede kwetsbaarheid die de aanvallers inzetten, is CVE-2026-86060. Dit is een privilege-escalatiefout in SSH, waarmee een aanvaller beheerdersrechten krijgt in RouterOS. Deze fout is ontstaan doordat RouterOS niet goed omgaat met gebruikersnamen voor de SSH-login die beginnen met een niet-toegestaan teken. Aanvallers kunnen daardoor zelf een gebruikersnaam aanmaken waarmee ze SSH-sessies manipuleren.

Het Poolse CERT ontdekte deze twee kwetsbaarheden met GPT-5.5 Cyber en GPT-5.6 Sol. Beide krijgen binnen het Common Vulnerability Scoring System (CVSS) een score van 9,2 op een schaal van tien. De aanval met deze kwetsbaarheden heet MikroTrick.

Derde kwetsbaarheid

Het CERT-team licht daarnaast een derde kritieke fout uit: CVE-2026-67277. Deze kwetsbaarheid, met een CVSS-score van 8,8, raakt de bandbreedtetestdienst van RouterOS. Ongeautoriseerde aanvallers kunnen door de fout gegevens uit het kernelgeheugen laten lekken of op afstand een denial-of-serviceaanval (dos) uitvoeren, zodat het systeem opnieuw opstart.

MikroTik bracht eerder al patches uit voor de gevonden kwetsbaarheden. Het CERT-team adviseert dan ook updates zo snel mogelijk te installeren. De patches zitten in versie 7.25 beta 3, 7.24.2, 7.23.4 en 6.49.21.

Reacties (87)

[Cergorach]

Wie zet z'n SSH nog open naar buiten toe?

[Klauwhamer]

Mijn OpenSSHs staan gewoon open naar buiten hoor. Root login disabled en fail2ban goed geconfigureerd. Komt u maar

[blaatenator]

Jep, inderdaad. En om het nog iets lastiger te maken kun je ook password based logins uitzetten en alleen logins obv een cert toestaan.

Ik heb eigenlijk meer vertrouwen in OpenSSH dan de verschillende VPN protocollen ondanks dat het 'oude' code is..

(edit: Libre was natuurlijk voor LibreSSL, n.a.v. Heartbleed. Niets te maken met SSH)

[Reactie gewijzigd door blaatenator op 7 september 2026 18:55]

[Jerie]

Jep, inderdaad. En om het nog iets lastiger te maken kun je ook password based logins uitzetten en alleen logins obv een cert toestaan.

Public keys zul je bedoelen. Dat is precies wat hier lek was. Dit is een effectief een remote vulnerability.

[De Vliegmieren]

nee het artikel is niet volledig. Er is ook CVE-2026-67279 die remote code execution mogelijk maakt nog voordat de SSH verbinding is geauthenticeerd - geen public key modulus nodig.

Ik hoop dat Mikrotik stopt met hun eigen implementatie van kritieke beveiligingsprotocollen en ervoor kiest om standaard implementaties te gebruiken die al zeer onderhevig zijn aan audits en fuzzing door LLM en andere tooling. Zal wel ten koste gaan van de upgradeability van oudere modellen netwerkapperatuur met weinig cpu en ram...

[Jerie]

Ja, dat weet ik. Het is een remote kwetsbaarheid. Dat schreef ik ook. Zeer ernstig.

Qua eigen implementatie. Ik weet niet hoe het tegenwoordig zit, maar vroeger was Dropbear, hoewel een iets kleinere footprint (vooral met dietlibc), afschuwelijk qua security track record.

[Jef61]

Ja, maar dan staat ssh ook niet 'gewoon' open maar goed beveiligd lijkt me (of in ieder geval over nagedacht). Ik zou het niet doen..

[Reactie gewijzigd door Jef61 op 7 september 2026 16:19]

[Jerie]

Geef het IPv6 maar

[stefanheggins]

Het is goed om verschillende lagen van beveiliging te gebruiken zodat je niet door de kwetsbaarheid van een systeem (zoals je internet router) je volledige netwerk gehacked kan worden.

[betwetor]

Maar waarom?

Zit je op een terrasje en denk je, "waar ik zin in heb? Even mijn router logs bekijken."

Dat je op een server wil inloggen, dat kan ik me voorstellen, maar op je router?

[Keyb]

Er is niet veel mis met OpenSSH open zetten. Tenzij Jan en alleman zijn eigen zwakkere implementatie gaat schrijven.

[Ed Vertijsment]

Er is geen garantie dat openssh veilig is, indien niet nodig kun je beter geen ssh naar buiten open zetten

[Keyb]

Er is geen enkele garantie, maar er is weinig veiliger dan openssh?

[thunderbird2k]

Je zet het achter een vpn zoals wireguard (of old school OpenVPN).

[Keyb]

Right.. of je nou een jumpbox met OpenSSH of Wireguard er voor zet maakt bijzonder weinig verschil. Zolang je openssh PasswordAuthentication no en KbdInteractiveAuthentication no gebruikt in je config is het verschil wat? Beide oplossingen gebruiken public keys. Daarnaast luisteren wij naar een beperkte set IP adressen. Wireguard is inherent niet een veiliger protocol dan openssh.

[Bor]

Dat maakt in dusverre verschil dat je een 2e laag aanbrengt. Mits goed geconfigureerd hoeft een compromised VPN connectie dan nog niet automatisch tot een compomised SSH connectie (en daarmee vaak admin / root toegang) te leiden.

Dat beide oplossing public keys gebruiken zegt precies niets in dit geval.

[Reactie gewijzigd door Bor op 7 september 2026 18:41]

[Keyb]

Een tunnel in een tunnel zegt ook niets over een van die 2. Als mijn key op straat komt te liggen is daar geen admin/root mee te verkrijgen trouwens? Verder niks mis met die extra laag doen wij ook meestal, maar niet altijd.

[Bor]

Het gaan dan ook niet om het punt dat een tunnel in een tunnel iets zegt over 1 van die twee maar over het toepassen van meerlaagse beveiliging wat gewoon best practice is. Het compromitteren van de eerste laag moet dan niet tot het compromitteren van de 2e laag leiden. Als er slechts één laag is dan....

[Keyb]

Dan trek je de discussie een stuk breder. Moving goalposts.

[Bor]

Zeker niet. De goalposts staan nog gewoon op dezelfde plek. Jammer dat je dit zegt. We hebben het hier over best practice beveiliging. Dat gaat doorgaans uit van een multi layered defence waarbij die multi layer aanvallen op meerdere lagen hoort tegen te houden. Het hele punt is dat het niet best practice is (understatement) om admin consoles en toegang (wat SSH in de meeste gevallen is) aan het publieke internet te hangen zonder aanvullende maatregelen.

[Bor]

Jouw stelling was: " maar er is weinig veiliger dan openssh". Dat is gewoon onjuist om de genoemde redenen als protocol- en daemon vulnerabilities. Multi layered aanpakken zijn er juist om dergelijke issues waar mogelijk te mitigeren en dat is daarmee heel relevant. Dat is dus onderdeel van de discussie. Je kan niet simpelweg stellen dat iets buiten de discussie valt op basis van dat iets je niet aanstaat of omdat je er geen rekening mee hebt gehouden in je betoog. OpenSSH staat niet bekend als product dat nooit urgente kwetsbaarheden heeft / heeft gehad. Zelfs op de officiele website staat een lijst met issues die zich over de jaren hebben voorgedaan. Dat er ook voor andere tools CVE's zijn is helemaal waar maar dat is het hele issue hier niet (maar op zijn best een what about)....

[Reactie gewijzigd door Bor op 7 september 2026 19:19]

[Keyb]

De stelling, misschien ongelukkig geformuleerd, stelt dat er maar weinig protocollen zijn die zo veilig zijn. In die club weinig vallen ook OpenVPN en Wireguard hoor. Zeker, maar Wireguard again is op zich niet vele malen veiliger dan openssh. Maar je begint er nu een semantische discussie van te maken en daar heb ik geen zin in. Ik heb nergens gesteld dat openssh geen CVEs heeft, ik heb nergens gezegd dat layered practices slecht zijn. Openssh is een prima protocol, doet niet onder voor een Wireguard oplossing. Success met je layered practice betoog. Ik hou het er bij.

[Snow_King]

Ben het helemaal met je eens. VPN’s zijn er zo ingeslopen bij veel mensen als de holy grail dat je continu in deze discussies raakt.

OpenSSH kan prima aan het internet als jumpbox, via Agent forwarding kan je daarna bij je machines daar achter. Uiteraard alleen met keys, niet met password, precies zoals jij beschrijft.

Zo heb je gewoon meerdere lagen beveiliging en dat werkt goed.

[Bor]

Als die SSH connectie direct aan het internet hangt en foreward naar ook weer SSH heb je eigenlijk geen meerdere lagen beveiliging. SSH direct ontsluiten aan het internet is al jaren geen best practice meer.

[ByteArray]

OpenVPN is waarschijnlijk onveiliger dan OpenSSH, zeker als je dat vergelijkt met de inheemse versie van OpenSSH - voor OpenBSD, waar welgeteld nog maar één RCE in is gevonden de afgelopen bijna 30 jaar. De overdraagbare versie voor Linux is qua RCE's waarschijnlijk ook veiliger. Gewoon standaard configuratie + "AuthenticationMethods publickey". Kan ook nog met een speciale veiligheidssleutel (YubiKey o.a.) gecombineerd worden.

Als je via OpenVPN direct binnen een heel netwerk kunt kijken, is dat misschien wel onveiliger. Stel dat ze dat als springplank gebruiken naar bijv. een verouderde Postgres-sever?

Natuurlijk kun je de VPN ook zo configureren binnen je netwerk, dat je alleen bij de SSH-server kunt, en dan pas verder. Maar ja, genoeg ICT'ers die er een potje van maken...

Dus lijkt me vooral theoretisch beter, maar in de praktijk misschien niet.

[mbovenka]

Hmmm...ik denk dat de attack surface van Wireguard kleiner is dan die van OpenSSH. In die zin is het wel inherent veiliger denk ik. Maar een goed dichtgespijkerde SSH is volgens mij uiteindelijk veilig genoeg. Maar daar kun je over van mening verschillen.

[Keyb]

Interactieve ssh sessies zijn sowieso tricky. Zeker als je ziet hoeveel default users er op veel Linux distributies al aanwezig zijn. Die worden meestal wel redelijk afgeschermd zonder shell e.d. maar dan nog. Als je nog veel gebruikers aanmaakt met zwakke wachtwoorden begint het wel een dingetje te worden. En toegegeven de drempel daarvoor op wireguard is misschien hoger.

[stefanheggins]

Het gaat om de risicos die je neemt. We kunnen er van uitgaan dat er hacker-groepen zijn die van beveiligingslekken weten die nog niet publiek bekend zijn. Het gaat er dus niet alleen om je systemen up-to-date te houden maar ook alleen dingen open te zetten die je echt nodig hebt.

[Bor]

maar er is weinig veiliger dan openssh?

Eh... nee? Een paar willekeurige en (semi) recente CVE's:

CVE-2026-35414: Authorized keys principals mishandling vulnerability affecting versions before 10.3, which can allow an authenticated attacker to bypass access controls and gain unauthorized root access.

CVE-2026-35388: A local privilege escalation weakness (CWE-420) involving unconfirmed proxy-mode multiplexing sessions in versions prior to 10.3.

CVE-2026-35386: Arbitrary command execution via shell metacharacters injected into a command-line username, requiring a non-default configuration.

CVE-2024-6387 (RegreSSHion): A well-known unauthenticated remote code execution signal handler race condition affecting versions 8.5p1 through 9.7p1 on glibc-based Linux systems.

[Keyb]

Ja wedstrijdje CVEs vinden? Die laatste is een glibc-linux combinatie probleem. Niet aanwezig in OpenBSD.

Hier 2 wireguard issues.

1. CVE-2023-35838 — Windows client 0.5.3: firewall config lets an adjacent attacker block traffic to non-RFC1918 "local" nets while the tunnel is up (TunnelCrack LocalNet).
2. CVE-2021-46873 — Windows client: attacker-set future system clock (unauth NTP) can permanently burn a static private key.

[Bor]

Nee het is geen wedstrijdje en dat er ook CVE's in wireguard zitten is bekend en eigenlijk niet helemaal relevant. Meer dan een "what about" plaats je eigenlijk niet. Je gaat voorbij aan het daadwerkelijke punt. Het gaat niet om het toepassen van een enkel product of een enkele oplossing maar juist om het toepassen van meerdere lagen / layers die elkaar beschermen en waarbij er een laag over blijft wanneer de andere gecompromitteerd is.

Daarnaast: heb je de CVE's die je aanhaalt daadwerkelijk gelezen? In het eerste geval gaat het om een beperkte dos aanval. In het tweede geval is unauth NTP vereist en hebben we het over een client issue.

[Jerie]

Ergo: Wireguard heeft een betere track record dan OpenSSH. Zelfs als je meeneemt dat Wireguard minder lang bestaat. Ook niet verbazingwekkend: Wireguard is maar 5k LOC .c, OpenBSD een veelvoud. Dat een kwetsbaarheid afwezig is in OpenBSD OpenSSH, dat is de reference implementatie maar OpenBSD wordt nagenoeg niet gebruikt; dus doet niet terzake. Het leeuwendeel gebruikt immers OpenSSH portable op Linux.

Overigens ken ik geen meer veilige SSH implementatie dan OpenSSH.

[Reactie gewijzigd door Jerie op 8 september 2026 02:35]

[citegrene]

Dat is sarcasme hoop ik...

[Keyb]

Nope. Vertel mij eens wat veiliger is?

[xxs]

VPN tunnel? Maar een ssh met key en MFA kan best veilig opgezet worden.

[Keyb]

Check, interactieve logins hebben we uit staan. En ook geen ssh op elke box, alleen een openBSD doos als jumpbox. En ondersteunen alleen de PQC ciphers vanuit onze beroepsdeformatie.

[Cergorach]

Maar OpenSSH heeft ook een sloot aan CVEs, daar zitten ook gaten in die net zo ernstig waren als deze gaten...

En OpenSSH openzetten naar buiten toe is net zo onveilig gebleken de laatste jaren.

Zet een (VPN) tunnel op van remote locatie naar binnen je network en als je echt paranoid wil wezen stel je in dat je dit alleen met bepaalde IPs en certificaten kan...

[Bor]

Dat is inderdaad een goede vraag. Het openstellen van beheer consoles en beheer toegangen (waar SSH doorgaans ook onder valt) is al jaren geen best practice meer. Je maakt jezelf erg kwetsbaar op die manier voor lekken in o.a. de SSH deamon en trekt behoorlijk de aandacht. Het is kinderlijk eenvoudig om openstaande SSH toegang te scannen of zelfs te querien inclusief eventuele default wachtwoorden, vulnerabilities etc.

[Klauwhamer]

Nee, hoor. Dat doe je helemaal niet, wanneer je basale configuratie van je daemon toepast. Ik heb het al eerder gezegd maar denk aan fail2ban, RSA-logins, root login disablen. Scannen kan en mag iedereen tot op zekere hoogte en, wanneer je username/password accepteert inderdaad ook gewoon proberen in te loggen. Dit is helemaal niet verkeerd, kwalijk, of wat dan ook, wanneer je dus de basis in orde hebt.

[Sine]

Ik neem aan dat SSH niet standaard open staat naar de buitenwereld, dat zou nog veel kwalijker zijn.
Dan heb je al een aanvaller binnen je netwerk nodig om schade aan te richten. Niet helemaal onschuldig, maar zeker voor de thuisgebruiker niets waar je je meteen te druk over moet maken.

[WargamingPlayer]

Daarom zit er bij mij een IP allow list op alle Management van mijn MikroTik spullen. En in een separaat VLAN.

[xxs]

Management NOOIT open vanaf de buitenwereld, maak een VPN en vandaar uit eventueel een mgmt toegang. Bij mij alleen mgmt vanaf bekabeld in huis ik kan in geval van nood wel mijn FW aanpassen.

[WargamingPlayer]

Ik snap je opmerking niet. Waarom zou ik mijn management interface en ssh niet in een special niet routeerbaar VLAN mogen zetten? Met daarop een whitelist en max filtering?

[xxs]

Meer veiligheid krijg je door gelaagdheid. Meerdere barricades opwerpen zodat bij één kwetsbaarheid niet meteen de hele zaak aan de buitenwereld zichtbaar is.

[WargamingPlayer]

Maar een privé management VLAN afgescheiden van alles is volgens mij gewoon het meest veilige. Vooral als je daar niet via een ander netwerk bij kan.

[xxs]

En wel bereikbaar vanaf het internet? Die snap ik dan weer niet.

[WargamingPlayer]

Totaal niet bereikbaar vanaf Internet. Mijn beheer VLAN is alleen maar benaderbaar wanneer ik fysiek een laptop op mijn switch aansluit of via een Virtuele Jumphost.

Ik snap niet hoe je er bij komt dat het benaderbaar is via Internet. Sterker nog, beheer interfaces van mijn ESX, Switches, routers en andere devices zijn niet via Internet benaderbaar. Zelfs mijn VPN is in een eigen afgeschermd VLAN getermineerd om te voorkomen dat er te veel benaderbaar is.

Gezinsleden hebben ook allemaal eigen VLAN.

[xxs]

Dan lees even mijn eerste opmerking terug waarop jij reageerde.

“Management NOOIT open vanaf de buitenwereld, maak een VPN en vandaar uit eventueel een mgmt toegang.”

[Harkov]

Nee klopt, ssh staat normaal niet aan de de WAN poort.

[Luchtbakker]

Als je gebruik maakt van sftp wel.

[RobbyTown]

Toch aardig wat die het juist hebben aangezet.

The Shadowserver Foundation, een stichting die onder andere onderzoek doet naar kwetsbare systemen op internet, meldt dat het ruim 122.000 MikroTik-routers op internet heeft gevonden die via SSH toegankelijk zijn. Het gaat om bijna zevenhonderd routers in Nederland.

[Xilonz]

Oeps, gelukkig hier vrijwel alle poorten dichtgezet, maar toch snel even updaten zodra ik thuis ben.

In het gelinkte artikel staat dat iedereen een push notificatie gehad zou moeten hebben op de mobiele app, maar ik heb iig niets gezien.

(tip in IP > Services kan je de SSH volledig uitschakelen)

[Harkov]

Ik heb de push notificatie ook niet gehad. Nu maar ingeschreven voor de nieuwsbrief. Je hebt een optie om alleen security gerelateerd nieuws te ontvangen.

[sygys]

Als ik inlog op de mikrotik app krijg ik gelijk een rood blok in beeld met de waarschuwing om direct de update uit te voeren. Vroeg me al af hoe veilig router os daadwerkelijk was. Blijkbaar niet zo veilig als iedereen dacht.

Zo en weer geïnstalleerd!

[Reactie gewijzigd door sygys op 8 september 2026 09:03]

[DigitalExorcist]

SSH openzetten vanaf het internet is dan ook niet zo heel erg handig zeg maar.. bouw een fatsoenlijke VPN naar een managementsegment als je dat perse nodig vindt en beveilig dat.

[Reactie gewijzigd door DigitalExorcist op 7 september 2026 16:02]

[Klauwhamer]

Het is niet handig wanneer je niet een paar basisregels in acht neemt. Zodra je dat wel doet, kan er niet zoveel spannends gebeuren. OpenSSH is veilig, MicroTik heeft één of andere halfgare implementatie bij elkaar spaghetti't, en daar zit het probleem. Niet bij OpenSSH of SSHds die naar buiten exposed zijn.

[DigitalExorcist]

OpenSSH en allerhande libraries die die gebruikt zijn ook niet bepaald verschoond van lekken en issues... gewoon niet openzetten vanaf het internet, maar netjes achter een VPN en met keys ipv wachtwoorden, dat soort werk.

[Klauwhamer]

Alsof VPN-services geen lekken en issues hebben..? Wanneer je root login disabled, fail2ban z'n werk laat doen, en/of desgewenst alleen via RSA-sleutels laat inloggen laat ik rustig al mijn SSH'tjes naar buiten open staan hoor. De drie dingen die ik noem zijn veel eenvoudiger in te stellen dan een fatsoenlijke VPN-verbinding opzetten. En bovendien heb je dan niet eens volle overlap in de Venn-diagram van use cases.

[DigitalExorcist]

Dat is ook zo. Ik ben zelf groot fan van Zerotier, een soort VXLAN meets VPN, dat draait ook 'native' op de Mikrotik als package. Geen poorten die naar binnen toe openstaan, gratis voor 10 devices, je hoeft alleen naar buiten te communiceren en niet de andere kant op, uitstekend te filteren op zowel Zerotier niveau als op Mikrotik niveau.. en installeren is 5 minuten werk. ZT connecteert alleen 'naar buiten toe' en zodra je een tweede device in je VXLAN opneemt praten ze als een mesh met elkaar. Snelheid is ook uitstekend.

Mikrotik erin, iPhone erin, (werk)laptop erin en je hebt overal en altijd toegang, en anderen niet. Sterker nog, ik woon in bij m'n ouders en die hebben hun Ziggo modem ook niet in bridge mode staan; inkomend verkeer is onmogelijk richting de Mikrotik die ik erachter heb hangen maar Zerotier connect gewoon binnen 3 seconden.

[Reactie gewijzigd door DigitalExorcist op 7 september 2026 16:30]

[Bor]

fail2ban gaat je bij diverse exploits niet helpen gezien er niet altijd meerdere failed authentication attempts nodig zijn voor een succesvolle hack.

Je mist bescherming tegen lekken in het protocol en / of de SSH deamon.

En bovendien heb je dan niet eens volle overlap in de Venn-diagram van use cases.

Dat heb jij ook niet

[Reactie gewijzigd door Bor op 7 september 2026 19:04]

[Bor]

Dit heeft echt niets met FUD te maken. Jammer dat je die kaart trekt.

De "rest" is allemaal afhankelijk van je SSH deamon en lagen die weinig tot niets toevoegen tegen protocol en daemon exploits. Daar zit (mede) het gevaar. Kijk alleen eens bij en overzichtje van OpenSSH zelf over security issues: https://www.openssh.org/security.html en dan hebben we het nog niet over alle andere SSH implementaties.

[Reactie gewijzigd door Bor op 7 september 2026 20:23]

[ByteArray]

De inheemse versie van OpenSSH, heeft welgeteld nog maar één keer een RCE gehad, in 2002. OpenSSH bestaat sinds 1999. Sindsdien is de beveiliging alleen maar beter geworden. Betere privsep en capability-based sandboxing (pledge/unveil op OpenBSD, capsicum op FreeBSD, en seccomp op Linux).

Dezelfde OpenSSH, maar dan de overdraagbare versie, voor o.a. Linux is ietsje minder veilig, maar nog steeds zo veilig dat je het wel degelijk gewoon naar buiten toe kunt openzetten. Mits goed geconfigureerd (bijv. standaard configuratie + "AuthenticationMethods publickey"), is dat net zo veilig als een goede VPN.

De versie die RouterOS gebruikt is, is een geheel andere implementatie. God mag weten waarom.

[Reactie gewijzigd door ByteArray op 7 september 2026 22:21]

[DigitalExorcist]

Was er niet iets met ssl libraries en zo? Of met ssh zélf wellicht?

[ByteArray]

Je hebt ook nog andere implementaties zoals libssh, deze implementatie Dropbear (voor RouterOS o.a.), en nog een paar andere, ook commerciële.

OpenSSH is de veiligste. En dat is wat standaard is inbegrepen bij (vrijwel) alle Linux distro's, Windows 10+, macOS, FreeBSD, NetBSD en natuurlijk OpenBSD zelf.

OpenSSL is een ander project, waar inderdaad vaak gedonder mee was, en nog steeds is. Maar je kunt ook LibreSSL gebruiken, eveneens van OpenBSD, dat is een veiligere versie.

[MadEgg]

Ik heb de push notificatie vorige week ontvangen, gelijk de hele zwik aan access points, routerboard, CRS switch en CHR geupdate. Bij mijn weten de eerste keer dat ik een push notificatie van Mikrotik heb ontvangen. Maar ging best soepel bij mij.

Ik heb uiteraard geen open SSH, alleen via een Wireguard VPN, dus was als het goed is niet kwetsbaar maar better safe than sorry.

[DDX]

Op welke manier heb je die push notificatie gehad ?

[MadEgg]

Via de iOS Mikrotik app. Wist niet eens dat die notificaties kon geven.

[DDX]

Ah ok, geen idee waaroim ik die app zou installeren.
Dacht via de winbox oid

[MadEgg]

Best handig om je router thuis te beheren moet ik zeggen.

[ECM-Droid]

Iemand anders bij wie de update faalde?

Bij mij faalde hij bij het opnieuw opstarten, en bleef hij uit/ging niet meer aan(alle lampjes bleven uit). Zodra ik de stekker er opnieuw in deed starte hij weer netjes op alsof er niks aan de hand was, maar niet geüpdatet.

Toen ik de SSD, welke via USB aangesloten zat er uit haalde, lukte de update wel.

Heel raar...

[fuzzyIon]

Ssh bereikbaar via het internet zonder knockd (poort knocking) en of fail2ban pure armoede.

Zelf laat ik sshd op het wireguard tunnel addres luisteren waarbij ik ook nog eens een knock secret instel. Dus zonder wg sleutel en ook nog eens knock sequence is er geen toegang tot de ssh server.

[Keyb]

Lekker bezig daar bij MicroTik met een eigen ssh implementatie die brak is dan. Dit is dus geen SSH bug, maar een MicroTik implementatie bug. Het protocol is prima.

[Sine]

Waarbij je je meteen weer afvraagt waarom men voor dit soort dingen het wiel opnieuw wilt uitvinden?

[vandeGerrit]

Los van dat het in dit artikel in ieder geval nergens staat of het een eigen implementatie is of dat ze gewoon de versie uit Linux hebben gepakt (waarop RouterOS is gebaseerd). Moet je je library die je gebruikt wel zo gebruiken en integreren dat dit past in jouw beoogde doel hiervoor. Bijvoorbeeld: Hoe kan een standaard SSH library jouw sessie valideren als jij zelf gaat over het aanmaken en beheer van gebruikers. Dan moet je dit stukje toch zelf regelen. En juist hierin zit de fout.

Daarnaast als ik kijk naar de puinzooi aan pakketjes die je soms krijgt, loont het soms echt wel om het wiel dan maar opnieuw uit te vinden, en je dit op de duur minder tijd vergt om te onderhouden. Of soms zit je met licenties die niet passen bij je beoogde doel, dan wel heb je eisen dat je applicatie op bepaalde hardware moet draaien (die ze ook zelf ontwikkelen) waardoor je wellicht andere eisen hebt aan libraries etc etc.

[Bedge85]

OpenVPN hebben ze ook gebouwd op basis van een eigen implementatie.

[mutley69]

Zonet de update gedaan. Security voor alles.

[FrostyPeet]

Met het huidige AI-geweld lijkt het mij meer de vraag wanneer mijn router aan de beurt is voor overname door een (staats)hacker. Ik kan er moeilijk drie achter elkaar zetten.