Router tegen IoT aanvallen

[Paul Guijt]

Kan de router niet voorkomen dat IoT apparatuur erachter meewerkt aan DDos aanvallen?
En als dat technisch wel zou kunnen maar nu nog niet, wat is er dan nog nodig?

[vanaalten]

Voor een deel zal dat wel kunnen, maar:
"DDoS" is een algemene term voor verschillende manieren van het overloaden van een server. Je kan een server overvoeren met tijd-requests, HTTP request en ongetwijfeld nog vele anderen. Welke soort wil je blokkeren? En dan, welk criterium precies: max 1 request per seconde? Per minuut? En stel dat je een leuke limiet hebt gesteld, wat nou als je als gebruiker 'iets' doet waardoor je die limiet bereikt - zit een provider (die de routers vaak levert) te wachten op al die service-requests?

Daarbij, het is een 'distributed' aanval. Dus stel dat je max 1 request per seconde toestaat - en stel dat dat een limiet is waar je als gebruiker geen problemen mee hebt - dan heb je met een miljoen devices achter een miljoen verschillende routers alsnog een heleboel requests. *Dat* zal je met een enkele router niet kunnen voorkomen.

Plus, het is principieel een foute aanpak om daarmee het probleem proberen op te lossen. Beter is het als de IoT-apparatuur (yuck, marketing-blaat) zelf wat meer aan veiligheid doet.

[McKaamos]

Wat vanaalten al zegt. Hoe wil je gaan bepalen of je mee aan het werken bent met een DDoS aanval?
Het is namelijk een legitieme opdracht die verstuurd wordt, dus welke criteria wil je hanteren om te zeggen dat het niet mag?

En dan heb je inderdaad het puntje dat een DDoS niet alleen maar bij jou vandaan komt. Met een leger van miljoenen IoT devices die ieders maar 1x per seconde een request afvuren, detecteer je zelf echt niet dat jouw IoT device mee doet.

Je kan beter gaan kijken naar betere beveiliging van jouw IoT device(s).
Om de populaire development boards even onder IoT te scharen: een RaspberryPi heeft bij een verse instalaltie van z'n besturingssysteem (in dit geval even Raspbian als voorbeeld) een standaard wachtwoord. Zet er een andere op.
Standaard staat de SSH service ingesteld om directe root-login toe te staan. How about no? Inloggen met een user en dan het SU commando gebruiken, graag!
En wat dacht je van SSH met Public/Private keypairs in plaats van wachtwoorden? Veeeeel sterkere beveiliging.
Standaard staat de sudo-configuratie ingesteld dat er passwordloos gebruik gemaakt mag worden van het SUDO commando. Like, wtf?
Standaard staat er geen firewall op de Pi. Probeer eens FirewallD te installeren (apt-get install firewalld).

En zo zijn er nog wel wat dingetjes te regelen.
Beveilig het apparaat. Voorkomen is beter dan genezen.
Het is echt de moeite niet om in een embeded Linux variant wat dingen in te stellen die het leven van een aanvaller zuur maken. De bovenstaande dingetjes heb je binnen een kwartiertje geregeld.

Uiteraard zijn er nog andere aanvalsrichtingen, maar dit is toch echt wel de basis.
B.v. zorgen dat je software up-to-date is. Installeer applicaties die als service draaien niet op zo'n manier dat ze permanent als Root draaien. Geef ze gewoon een eigen user en pas de config-file aan zo dat de service (programma) als die user draait. Daarmee voorkom je al een hele hoop gedonder, en het kost nauwelijks moeite.

Kortgezegd: IoT devices doen mee aan DDoS aanvallen omdat ze zelf kwetsbaar zijn. De beveiliging is standaard ronduit naadje te noemen. En het blijft heel lang werken omdat dergelijke devices nauwelijks gecontroleerd worden. Als het eenmaal draait, doe je er niks meer aan en log je niet in om te controleren of alles goed is. Plus, men is zich niet bewust van hoe het ingesteld moet zijn. (wat ik hier boven uitleg). Je hoeft geen linux systeembeheerder of security expert te zijn om een goede basis neer te zetten, maar je moet je er wel even in verdiepen en er over nadenken.
Maak je ze minder kwetsvbaar, dan hoef je je ook niet druk te maken om het opvangen van een DDoS aanval.

[ Voor 36% gewijzigd door McKaamos op 22-10-2016 12:21 ]

[Belgar]

In principe kun je er echter wel voor zorgen dat je IOT device niet van buiten benaderd wordt. NAT en UPNP goed instellen op je router. telnet protocol blokkeren, ftp blokkeren.

Je bent niet helemaal hulpeloos.

Raspberry pi vind ik niet het sterkste voorbeeld, omdat verreweg het grootste deel achter een firewall zit en niet zelf gaten gaat lopen slaan in die firewall. Ook zijn er "geharde" versies van raspbian beschikbaar. Tegenover de meeste IOT apparaten worden ze veelal ook niet gebruikt door mensen die geen idee hebben wat technologie is. De goedkope IP camera's die zelf gaten gaan lopen slaan in de firewall en geen mogelijkheid hebben om fatsoenlijk updates te draaien zijn een veel groter probleem.

[Rmg]

Ligt ook een beetje aan je IoT device. Voor sommige devices kan je wel een uitgaande whitelist maken (domotica die naar een bepaald platform data pusht.) voor andere devices is dat lastiger (een ripe atlas is dan nutteloos)

[McKaamos]

Belgar schreef op zaterdag 22 oktober 2016 @ 13:01:
In principe kun je er echter wel voor zorgen dat je IOT device niet van buiten benaderd wordt. NAT en UPNP goed instellen op je router. telnet protocol blokkeren, ftp blokkeren.

Je bent niet helemaal hulpeloos.

Raspberry pi vind ik niet het sterkste voorbeeld, omdat verreweg het grootste deel achter een firewall zit en niet zelf gaten gaat lopen slaan in die firewall. Ook zijn er "geharde" versies van raspbian beschikbaar. Tegenover de meeste IOT apparaten worden ze veelal ook niet gebruikt door mensen die geen idee hebben wat technologie is. De goedkope IP camera's die zelf gaten gaan lopen slaan in de firewall en geen mogelijkheid hebben om fatsoenlijk updates te draaien zijn een veel groter probleem.

Een RasPi is misschien niet het beste voorbeeld, maar wel eentje die tot de verbeelding spreekt.
Daarbij is de default config van een RasPi net zo slecht beveiligd als, bijvoorbeeld, een IP Camera.

Die geharde Linux distro's zijn er inderdaad, maar die staan niet standaard op de website van RasPi. Daar zal je extra achteraan moeten.

Punt van het probleem is dat fabrikanten niet goed naar de beveiliging kijken. Of dat nu een RasPi (of derivaat) is of een kant-en-klaar product zoals een IP Camera.

En ja, ik ben het met je eens dat NAT (da's technisch gezien geen firewall!) standaard toegang van buiten tegenhoudt en je daarom een belangrijke attack-vector mist. Betekent echter niet dat er geen andere manieren zijn.
Dat beperkt het risico op infectie, dus heb je ook minder last dat je rotzooi moet opruimen.
UPNP is daarin wel weer een heel gevaarlijk ding, want die opent inderdaad die mogelijkheid weer.

Het is een beetje een kip/ei verhaal. Aan de ene kant is de gebruiker verantwoordelijk voor zijn apparatuur.
Aan de andere kant is de fabrikant verantwoordelijk voor het afleveren van een goed product. Echter, is security onderdeel van 'goed product'? of wordt die defintie geleid door de gebruikersvriendelijkheid?
Dus ja, bij wie ga je de verantwoordelijkheid voor de security beleggen? De onwetende gebruiker of de lakse fabrikant?
Zolang gebruikers het probleem niet zien, is er voor de fabrikant geen incentive om iets te gaan doen, want verkopen doen ze toch wel.

edit:
ik moet ineens ook even denken aan het interview van Darren Kitchen (Hak5) met RenderMan (een alias, ofcourse, IoT security onderzoeker) tijdens Derbycon 2016.

https://www.hak5.org/epis...6-0-2016-hacking-sex-toys

IoT enabled sex speeltjes. Met een straight face praten over de aanvalsvectoren die er zijn (b.v. via een app op een telefoon. NAT? lekker boeie!) en of het technisch gezien verkrachting is als je zo'n ding hijackt

[ Voor 11% gewijzigd door McKaamos op 22-10-2016 13:55 ]

[Belgar]

Ben het wel met je eens, maar als je kijkt naar het onderzoek van bijvoorbeeld de DDOS van gisteren zijn dat bijna allemaal UPNP apparaten met default username/password en/of bekende gecompromitteerde busybox shells via telnet.

Als alle routers UPNP uit zouden hebben staan (of in ieder geval restrictief) en via DPI telnet sessies zouden blokkeren was 95%+ van de apparaten ingezet voor de DDOS van gisteren er al niet meer geweest. Dus de TS vraag of je er niet iets zelf tegen kan doen via je eigen router is wel relevant.

Aan de andere kant horen dit soort apparaten gewoon niet geleverd te worden met default passwords, firmware van 5 jaar oud met bekende gaten en UPNP als standaard.

Volgens de Europese wet kun je van de bedrijven aantonen dat ze apparaten geleverd hebben met bekende veiligheids-problemen en dat de consument dat product ter goeder trouw heeft gekocht.

[McKaamos]

Ja, dat is ook zo. Het is nu in ieder geval nog zo dat een dergelijke aanval zo simpel is dat UPNP uitzetten en telnet restriction de meest recente DDoS had kunnen voorkomen. En waarschijnlijk voorkomt het nog wel een paar DDoSsen in de nabije toekomst als iedereen dat massal zou gaan doen.

Dat maakt het inderdaad een samenspel met slecht uitgewerkte/geimplementeerde standaarden (zoals UPNP), slecht beveiligde routers, en slecht beveiligde IoT devices.
Dus in die zin is het inderdaad legitiem dat er naar de router wordt gekeken.
Echter, er wordt gevraagd naar de verkeerde oplossing (filteren van uitgaande DDoS packets), als je het mij vraagt. Het moet niet zo zijn dat de router gaat dwijlen terwijl hij zelf UPNP zonder restricties toepast. Dát is het grote issue in de zin dat de router faciliteert dat een IoT device wordt gecompromiteerd.
Je wil niet gaan kijken naar de rotzooi die wordt veroorzaakt nadat er een infectie plaatsvindt, maar juist naar hoe je infectie in de eerste plaats al voorkomen kan worden.

Dus ja, het is zeker niet verkeerd om naar de router te kijken. Dat ben ik helemaal met je eens.
Het is gewoon zot dat een router een faciliterende rol speelt.

En wat je ook al zegt, dat IoT devices niet verkocht moeten worden met default passwords, verouderde software en intentionele gaten zoals UPNP of een openstaande Telnet service. Ben ik het roerend mee eens, en zou een flinke stap voorwaarts zijn als daar in ieder geval wat aan werd gedaan.
Simpele dingen als zorgen dat het password verlopen is en vervangen moet worden bij de eerste keer dat je er op inlogt, zijn helemaal geen lastige dingen om te implementeren.
Rotzooi opruimen na het ontwikkelproces (zoals een debug console op Telnet) hoort gewoon standaard te zijn, maar zoiets vindt zich nog veel te vaak een weg naar de productieversie.
Software updaten is mogelijk wat lastiger en kost voornamelijk meer werk om softwareversies goed te keuren en te packagen. Werk kost tijd, tijd is geld, dus moet het IoT device duurder gemaakt worden. Ik volg dat een fabrikant dat niet zo gauw doet of beperkt hoe lang de support is. Maargoed, eigenlijk zou daar iets op gevonden moeten worden. Bijvoorbeeld door een eigen repository te draaien (voor de packagemanager op je IoT devide) en die na de support termijn over te dragen naar de linux/opensource community.

[Paul Guijt]

Dank!

Als ik het goed begrijp kan een router een bescheiden rol spelen, door

Algemeen:

• wachtwoord moeilijk maken
• firmware up to date houden

Inkomend:

• NAT goed instellen
• UPnP uitzetten
• blokkeer de telnet en ftp poorten (en i.h.a. ongebruikte poorten)

Uitgaand:

• zoveel mogelijk internet toegang blokkeren voor netwerk applicaties, in ieder geval voor telnet

Vergeet ik nog iets?

Kan een gewone router (ik heb zelf een FritzBox) via DPI telnet sessies blokkeren?

Mijn FritzBox heeft ook de mogelijkheid van stealth mode, die ik nu heb aangezet. "In stealth mode the FRITZ!Box firewall rejects unsolicited queries from the Internet instead of replying with ICMP control messages." Verder heb ik het email filter via port 25 aangezet. "This filter blocks e-mail dispatch via the insecure port 25." Idem het NetBios en Teredo filter.

De staat van IoT zaken is helaas een gegeven, hooguit kun je bij aanschaf er op letten.
En de beveiliging van een RPi is een ander verhaal.

Vriendelijke groet,
Paul

[ Voor 7% gewijzigd door Paul Guijt op 26-10-2016 10:06 ]

[dion_b]

Paul Guijt schreef op woensdag 26 oktober 2016 @ 09:40:
Dank!

Als ik het goed begrijp kan een router een bescheiden rol spelen, door

- algemeen:
- wachtwoord moeilijk maken

Moeilijk is een pre, maar iets anders dan default is het belangrijkste. Bij dit soort attacks wordt niet veel tijd gespendeerd om één device te kraken, er wordt lukraak op miljoenen adressen geprobeerd met bekende vulnerabilities iets te doen.

Grootste gevaar met moeilijke wachtwoorden, zeker icm policy om ze vaak te veranderen, is dat je ze ergens gaat opslaan, aangezien menselijk geheugen niet goed omgaat met lange, vaak wisselende moeilijke wachtwoorden. Dat voegt gelijk een veel grotere single point of failure toe als iemand het wel specifiek op jou gemunt heeft. Veel beter idee is om naar 2-factor authentication te kijken als je je zorgen maakt om de sterkte van je wachtwoorden.

Iig is het voor de attack van deze week allemaal volstrekt overbodig. Je IoT wachtwoorden veranderen in "1234" zou deze al voorkomen hebben

- firmware up to date houden

Zeker een goede, maar je bent afhankelijk van de vendor dat zij regelmatig hun firmwares bijwerken en daarin alle nodige security fixes te zetten. Beter is om aan te nemen dat ze het niet doen en elk apparaat als potentieel vol lekken te beschouwen.

- inkomend:
- NAT goed instellen

NAT an sich zorgt al goed voor het niet bereikbaar zijn van kwetsbare apparaten van buitenaf. Het gaat hier vooral om wat je niet moet doen, namelijk onnodig NAT traversal (maw port forwarding en DMZ) vermijden.

- UPNP uitzetten

Dit moet in knipperende hoofdletters geplaatst worden UPNP UIT!!!!

Als er één simpele zaak is wat geen enkele specifieke kennis vergt is dit het wel.

Het heeft wel costs: 'ouderwetse' applicaties die toegang nodig hebben van buitenaf werken met vaste poort(en) die eenvoudig handmatig geforward kunnen worden, 'moderne' apps doen aan NAT traversal dmv uitgaande verbindingen (a la Skype), maar er zit een sloot zooi tussenin dat uitgaat van UPNP en geen eenvoudige manier heeft om het handmatig te regelen. Vooral sommige games lijken hier last van te hebben. Fifa2014 vraagt bijvoorbeeld om het forwarden van meer dan 20000 poorten als je UPNP uit zet

Kan dus betekenen dat je een paar harde keuzes moet maken tussen security en gebruik van specifieke toepassingen.

- blokkeer de telnet en ftp poorten (en i.h.a. ongebruikte poorten)

Ook hier: andersom aanpakken. Deny all, tenzij specifieke zaken bewust gewenst zijn. Als jij niet opzettelijk een dienst opzet op een bepaalde poort, is er geen enkele reden dat een router moet luisteren naar dat poort.

- uitgaand:
- zoveel mogelijk internet toegang blokkeren voor netwerk applicaties, in ieder geval voor telnet

Bedoel je hier niet inkomend telnettoegang voor die devices, wat al onder je punt hierboven valt?

Dat gezegd, ook hier zou insteek moeten zijn: deny all tenzij goede reden. IMHO zouden mijn IoT-apparaten alleen moeten praten met m'n LAN en niet met remote servers. Helaas worden veel van die dingen verkocht als clouddiensten waarmee ze moeten communiceren met een bepaalde externe server. In dat geval kan het geen kwaad in te stellen dat verkeer vanaf source IP IoT apparaat alleen naar bepaalde externe IP of reeks kan. Dit wordt alleen bemoeilijkt door clouddiensten die distributed gehost worden. Enige wat je daar kan doen is dergelijke diensten vermijden...

Vergeet ik nog iets?

Kan een gewone router (ik heb zelf een FritzBox) via DPI telnet sessies blokkeren?

Uh, per default gaat telnet gewoon over poort 23. Zolang jij zorgt dat poort 23 niet bereikbaar is, kan een aanvaller geen telnetsessie openen op een nog niet gecompromitteerd apparaat.

Vergeet iig DPI op een consumentenapparaat, dat moet in software - dus op de CPU - gebeuren en trekt zo'n ding ogenblikkelijk plat. Ik heb Intel Atom-based apparaten met DPI zien zakken van >>500Mbps WAN-to-LAN naar <1Mbps WAN-to-LAN
_{En dat was niets ingewikkelders dan checken voor een lijst - Amerikaanse - vieze woorden in plaintext}

Mijn FritzBox heeft ook de mogelijkheid van stealth mode, die ik nu heb aangezet. "In stealth mode the FRITZ!Box firewall rejects unsolicited queries from the Internet instead of replying with ICMP control messages."

Tja, dan reageert hij niet meer op verzoeken van buitenaf op poorten die niet geforward zijn. Marginale verbetering van security van je router zelf, maar je echte gevaar zit erachter.

Verder heb ik het email filter via port 25 aangezet. "This filter blocks e-mail dispatch via the insecure port 25." Idem het NetBios en Teredo filter.

Altijd verstandig als je zelf geen mail over port 25 gebruikt. Stel dat je per ongeluk zombie wordt, dan word je iig niet stante pede afgesloten door de abuse-afdeling van je provider.

De staat van IoT zaken is helaas een gegeven, hooguit kun je bij aanschaf er op letten.

Dat, vooral dat. En duidelijk laten weten aan een vendor dat je niet kiest voor hun product, ongeacht alle leuke toeters en bellen, omdat je geen vertrouwen hebt in hun security. Als ze merken dat security een essentieel onderdeel van de aankoopsbeslissing wordt, gaan ze er resources op zetten. Zo niet, dan niet.


Oh, en tenslotte: "IoT" is een hip woord, maar als je gaat kijken naar de daadwerkelijke lijst van apparaten die deze week gebruikt zijn in de Mirai-attack zie je naast camera's en printers vooral oude bekenden als routers (van grote ODM's als ZTE en SMC, van vendors waar je beter van verwacht zoals Ubiquiti en - meest zorgwekkend - van een chipsetvendor, Realtek) en mediaspelers (hallo Dreambox...). Dus zaken die ook ver voordat "IoT" als term gebezigd werd kwetsbaar waren en gebruikt werden voor dit soort attack. Plus ca change...


Maar goed, IMHO kun je beveiliging zo complex aanvliegen als je wilt. Als ik advies moest geven aan iemand die hooguit de GUI van z'n router kan bereiken maar verder niets van networking snapt, dan zou het neerkomen op:

1) zet UPNP uit. En retourneer producten die zonder UPNP niet (goed) aan de praat te krijgen zijn.
2) verander altijd wachtwoord van een nieuw in gebruik genomen apparaat met netwerkverbinding. Al is het nog zo simpel en al gebruik je voor ieder apparaat hetzelfde wachtwoord, en al schrijf je dat wachtwoord op een post-it die je op je router plakt, dan nog ben je door deze simpele handeling immuun voor alle attacks zoals die van deze week. En dat geldt dubbel voor je router zelf, dat altijd eerste lijn van verdediging maar daarmee ook eerste lijn van kwetsbaarheid in je huis vormt.