Bron: https://www.trustwave.com/Resources/Spi ... he-World-/
Kort samengevat: CVE-2018-14847 zorgt er voor dat hackers zonder enige authenticatie de login credentials kunnen bemachtigen. En zo kunnen ze dus inloggen op je mikrotik device, proxy aanzetten en een coinhive mining script injecteren.
Als je wil testen of je Mikrotik router vulnerable is, kan je deze PoC uitproberen: https://github.com/BasuCert/WinboxPoC
Patchen die handel!
Over 170K Mikrotik routers geinfecteerd met cryptojackers
-
- Deel van't meubilair
- Berichten: 29849
- Lid geworden op: 28 okt 2003, 09:17
- Uitgedeelde bedankjes: 434 keer
- Bedankt: 1972 keer
Niet echt slim van je Winbox bereikbaar te hebben op je WAN poort
-
- Elite Poster
- Berichten: 1021
- Lid geworden op: 09 maa 2011, 16:04
- Uitgedeelde bedankjes: 16 keer
- Bedankt: 81 keer
gelijk wat over je wan poort feitelijk.
Als ik remote aan mijn router settings moet tunnel ik over ssh, hoe minder open poorten hoe beter.
Als ik remote aan mijn router settings moet tunnel ik over ssh, hoe minder open poorten hoe beter.
-
- Premium Member
- Berichten: 564
- Lid geworden op: 14 mei 2004, 00:16
- Uitgedeelde bedankjes: 16 keer
- Bedankt: 34 keer
- Recent bedankt: 1 keer
Je hebt poort 22 of andere openstaan ?boran_blok schreef:gelijk wat over je wan poort feitelijk.
Als ik remote aan mijn router settings moet tunnel ik over ssh, hoe minder open poorten hoe beter.
Heb zelf mikrotik en patch geregeld dus aan een ramp ontkomen precies
-
- Elite Poster
- Berichten: 1021
- Lid geworden op: 09 maa 2011, 16:04
- Uitgedeelde bedankjes: 16 keer
- Bedankt: 81 keer
Concreet,
ik ga over ssh naar mijn server op poort 22222, authenticatie dmv private/pubkey paar, en dan via tunnels zet ik een bepaalde poort op naar het IP van de router.
In putty ziet het er dan zo uit:
dan kan ik localhost:12345 doen voor naar de pfsense login te gaan.
ik ga over ssh naar mijn server op poort 22222, authenticatie dmv private/pubkey paar, en dan via tunnels zet ik een bepaalde poort op naar het IP van de router.
In putty ziet het er dan zo uit:
dan kan ik localhost:12345 doen voor naar de pfsense login te gaan.
-
- Deel van't meubilair
- Berichten: 29849
- Lid geworden op: 28 okt 2003, 09:17
- Uitgedeelde bedankjes: 434 keer
- Bedankt: 1972 keer
Compromissen, teveel koppijn en security gaan NIET samenITnetadmin schreef:Compromissen he.
Soms moet je remote ergens in kunnen en is een vpn opzetten teveel koppijn.
Ik gebruik trouwens SSTP (zit standaard in Windows en gaat gewoon over https) als VPN naar thuis.
-
- userbase crew
- Berichten: 8974
- Lid geworden op: 28 jan 2012, 18:22
- Uitgedeelde bedankjes: 199 keer
- Bedankt: 690 keer
- Recent bedankt: 2 keer
R2504, ik ga volledig akkoord.
Dat is nu eenmaal het compromis.
Als het een tijdelijke opstelling is, weeg je soms af wat je acceptabel vindt.
Bv ik stel een router in op een remote locatie, en tijdens de initial setup, die deels remote verloopt, is de webui bereikbaar vanop de wan.
Kwestie va de vpn setup makkelijker te kunnen debuggen.
Also: port 222, 2222, en 22222, zijn al even obvious voor ssh als port 22.
Dat is nu eenmaal het compromis.
Als het een tijdelijke opstelling is, weeg je soms af wat je acceptabel vindt.
Bv ik stel een router in op een remote locatie, en tijdens de initial setup, die deels remote verloopt, is de webui bereikbaar vanop de wan.
Kwestie va de vpn setup makkelijker te kunnen debuggen.
Also: port 222, 2222, en 22222, zijn al even obvious voor ssh als port 22.
-
- Deel van't meubilair
- Berichten: 29849
- Lid geworden op: 28 okt 2003, 09:17
- Uitgedeelde bedankjes: 434 keer
- Bedankt: 1972 keer
Het zijn zo'n beetje de klassieke excuses (die niet beperkt blijven tot die initiele setup)... iemand die ernstig is met security denkt daar niet aan.ITnetadmin schreef:Bv ik stel een router in op een remote locatie, en tijdens de initial setup, die deels remote verloopt, is de webui bereikbaar vanop de wan.
Als je zo'n dingen regelmatig moet installeren heb je gewoon een script en staat het op 1 minuut dicht (en niet de komende 5 jaar).
-
- Elite Poster
- Berichten: 1021
- Lid geworden op: 09 maa 2011, 16:04
- Uitgedeelde bedankjes: 16 keer
- Bedankt: 81 keer
22222 is gewoon gebruikt voor het meerendeel van de automatische scripts tegen te houden.
Geen root of wachtwoord logins toestaan helpt ook al. Veel meer dan dat kan je ssh niet dicht timmeren.
Op een gegeven punt moet je wel vertrouwen op één protocol dat zijn werk goed doet en correct beveiligd is. Anders moet je gewoon gaan airgappen en geen enkele poort open laten.
Als er een issue is met de security van ssh zelf denk ik dat dit wel redelijk snel de ronde zou doen, nog sneller dan de CVE's van mikrotik routers.
Het enige wat nog beter zou kunnen aan mijn setup is een IP range filter en fail2ban automatische blocking bij mislukte pogingen. Maar een certificaat brute forcen duurt toch wel even.
Stap één bij gelijk welke server/device die ik heb is alles behalve die ssh dicht zetten over dat stuk kan je hoe dan ook aan al de rest.
Geen root of wachtwoord logins toestaan helpt ook al. Veel meer dan dat kan je ssh niet dicht timmeren.
Op een gegeven punt moet je wel vertrouwen op één protocol dat zijn werk goed doet en correct beveiligd is. Anders moet je gewoon gaan airgappen en geen enkele poort open laten.
Als er een issue is met de security van ssh zelf denk ik dat dit wel redelijk snel de ronde zou doen, nog sneller dan de CVE's van mikrotik routers.
Het enige wat nog beter zou kunnen aan mijn setup is een IP range filter en fail2ban automatische blocking bij mislukte pogingen. Maar een certificaat brute forcen duurt toch wel even.
Stap één bij gelijk welke server/device die ik heb is alles behalve die ssh dicht zetten over dat stuk kan je hoe dan ook aan al de rest.
-
- userbase crew
- Berichten: 8974
- Lid geworden op: 28 jan 2012, 18:22
- Uitgedeelde bedankjes: 199 keer
- Bedankt: 690 keer
- Recent bedankt: 2 keer
Dit is dezelfde discussie die ik ook voer telkens ik een remote reconfig doe op een systeem dat enkel openstaat via SSH.r2504 schreef:Het zijn zo'n beetje de klassieke excuses (die niet beperkt blijven tot die initiele setup)... iemand die ernstig is met security denkt daar niet aan.
Als je zo'n dingen regelmatig moet installeren heb je gewoon een script en staat het op 1 minuut dicht (en niet de komende 5 jaar).
Mijn manier om accidental lockout te vermijden is nl... effe telnet aanzetten.
"Jama je kan ook deze anti lockout line in de ssh server toevoegen"
Jaja, tot ik effe iets over het hoofd zie of 2 sec niet oplet of de ssh server crasht of niet goed reboot, zeker.
Scripts waar meer tijd inkruipt om ze te maken dan om het effe manueel te doen.
Mss leuk als het altijd om dezelfde modellen, of zelfs merken van toestellen, zou gaan.
Security is ook opportunity.
Een niet default user/pwd combinatie op een custom port, die tijdens een initial config of remote reconfig aangezet wordt, is een acceptable risk.
We spreken hier niet over multinationals of bedrijven met een 24/7 production cycle hoor.
-
- Deel van't meubilair
- Berichten: 29849
- Lid geworden op: 28 okt 2003, 09:17
- Uitgedeelde bedankjes: 434 keer
- Bedankt: 1972 keer
Zolang dit enorm beperkt is in tijd... en je de discipline hebt om het uit te zetten kan het een acceptable risk zijn. Ik doe het in ieder geval niet, ik heb totaal geen zin later verantwoording te gaan afleggen bij m'n klanten (en ze zouden het niet aanvaarden ook niet) waarom het grondig is fout gegaan.ITnetadmin schreef:Een niet default user/pwd combinatie op een custom port, die tijdens een initial config of remote reconfig aangezet wordt, is een acceptable risk.
Dergelijke malware of dingen zoals ransonware maken ook geen onderscheid tussen een consument of een multinational. De schade bij kleine bedrijfjes is trouwens vaak nog groter omdat ze backups en dergelijke meestal ook niet echt op orde hebben.ITnetadmin schreef:We spreken hier niet over multinationals of bedrijven met een 24/7 production cycle hoor.
-
- userbase crew
- Berichten: 8974
- Lid geworden op: 28 jan 2012, 18:22
- Uitgedeelde bedankjes: 199 keer
- Bedankt: 690 keer
- Recent bedankt: 2 keer
Ja, je moet idd wel die discipline hebben.
Ransomware lijkt me eerder binnen te komen via users die op dubieuze email attachments of links klikken dan geinjecteerd via een firewall die effe een open poort had.
Zoiezo is een van de grote gevaren naar ransomware toe slechte backups.
Waaronder ik versta "backups van dewelke alle shares accessible en writable zijn ook wanneer de backup niet genomen wordt".
Een goeie backup in een kleine omgeving heeft minstens 1 copy die offline is, of die op zn minst zelf de share accessed en ook direct terug unmount als ie gebackupped heeft (maw pull vanuit de backup ipv push vanop de file server).
Ransomware lijkt me eerder binnen te komen via users die op dubieuze email attachments of links klikken dan geinjecteerd via een firewall die effe een open poort had.
Zoiezo is een van de grote gevaren naar ransomware toe slechte backups.
Waaronder ik versta "backups van dewelke alle shares accessible en writable zijn ook wanneer de backup niet genomen wordt".
Een goeie backup in een kleine omgeving heeft minstens 1 copy die offline is, of die op zn minst zelf de share accessed en ook direct terug unmount als ie gebackupped heeft (maw pull vanuit de backup ipv push vanop de file server).