Mikrotik HAP Lite - Deel 1

Door fvdberg op dinsdag 17 april 2018 17:00 - Reacties (25)
Categorie: Mikrotik, Views: 5.384

Welkom bij deel 1 van de Mikrotik HAP lite Howto reeks

Onderdeel van Hackers op je netwerk

We gaan gelijk beginnen.

We willen vanuit security overwegingen meerdere netwerken hebben.

Om meerdere netwerken te maken willen we eigenlijk ook de IP reeksen scheiden. Daarmee zien we gelijk duidelijk met welk subnet we te maken hebben. De mooiste optie daarvoor vind ik altijd een IP helper. Die versimpelt het hele verhaal behoorlijk.

Zie https://www.cisco.com/en/...ation/guide/htdhcpre.html

IP helper is een onderdeel van Cisco die op een Cisco device in de DHCP relay implementatie zit... En dus niet op onze Mikrotik. We moeten dus echt hardcore gaan routeren en kunnen ons er niet lui van af maken. Mooi, want daarmee krijg ik gelijk een kans om je echt een kijkje in de keuken van netwerk beheer te geven. En laten we eerlijk zijn...de IP helper op de Cisco is ook een lapmiddeltje en heeft weinig met bewust routeren te maken.

Wizards zijn handig en toegankelijk, dat is leuk maar niet leerzaam. Omdat we toch hardcore gaan kies ik dus ook bewust voor de console. Lekker old school, maar wel heerlijk duidelijk en nog leerzaam ook.

We hebben geen IP Helper op de Mikrotik. All is lost?

Nee, we nu eerst even de overige mogelijkheden bespreken.

Als we geen IP helper hebben.. hoe gaan we dan de boel opsplitsen?

Op de Mikrotik is wel de optie DHCP relay aanwezig...
En ja die kunnen we gebruiken icm een DHCP server met een brede scope.
Zie https://wiki.mikrotik.com/wiki/Manual:IP/DHCP_Relay

Als voorbeeld: 192.168.1.1 - 192.168.254.254 in de DHCP server geeft ons 254 ranges van 254 adressen. Met Subnet mask 255.255.0.0 kunnen we deze allemaal adresseren. Oftewel we moeten er een oplossing tussen plaatsen die alleen het gewenste deel van het subnet door laat. Hier komt DHCP relay in beeld. Hiermee kunnen we een soort van proxy die de aanvragen naar de DHCP beheerd plaatsen per interface en zo toch de DHCP server van ons modem gebruiken.

Dit werkt in de praktijk wel maar is niet de ultieme oplossing die de controle en bijbehorend veiligheidsniveau geeft die we onszelf als doel hebben gesteld. We routeren zo feitelijk ook helemaal niets met onze mikrotik router. We laten dat nog steeds compleet aan ons modem van de provider over. Vanuit het modem kunnen we nog steeds overal bij komen.

En vanuit het netwerk?

Als we op een client het subnet handmatig aanpassen naar 255.255.0.0 kunnen we gewoon op de andere subnetten binnen komen. En dat zullen we ook wel moeten want we moeten voor internet echt de gateway van het modem opvoeren.. Dit zouden we op kunnen vangen met een firewall... maar toch... Eigenlijk willen we echt per interface een eigen DHCP server, gateway, firewall en ip reeks hebben. We gebruiken de Mikrotik met bovenstaande config dus feitelijk enkel als een managed switch.

Kort om: fuck die shit...We gingen Hardcore, en gaan de Mikrotik gebruiken waar hij voor ontworpen is: Routeren. We gaan dus echt all the way. Cisco eat your heart out! IP helpers zijn voor dummy's De keuze voor routeren maakt het wel iets technischer... Maar het blijft Tweakers toch? Ik geloof in jullie!

Om de Mikrotik te configureren gaan we WINBOX gebruiken. Deze verbinden we op het mac adres van de 2e poort van de router. We beginnen met een "lege" Mikrotik. We laden dus geen Default Configuration in. We gaan vervolgens de boel vanuit de commandline interface (console screen) configureren. Dit om er mee bekend te raken.

Eerst maken we bruggen aan:

/interface bridge
add disabled=no name=LAN-bridge
add disabled=no name=LAN2-bridge
add disabled=no name=LAN3-bridge

Hier gaan we nu de Interfaces aanhangen:

/interface ethernet
set 0 disabled=no name=ether1-UPLINK
set 1 disabled=no name=ether2-LAN
set 2 disabled=no name=ether3-LAN2
set 3 disabled=no name=ether4-LAN3


Poort 1 gaat naar ons modem.
Poort 2 is LAN
Poort 3 is LAN2
Poort 4 is LAN3

Meer poorten hebben we niet. Ok. Klaar met poorten voor nu, terug naar de config

LAN willen we als reeks 10.0.0.1 t/m 10.0.0.254 geven.
LAN2 willen we als reeks 192.168.0.1 t/m 192.168.0.254 geven
LAN3 willen we als reeks 172.16.0.1 t/m 172.16.0.254 geven

Bewust maken we dus 3 verschillende subnets in 3 verschillende pools:

/ip pool
add name=lan ranges=10.0.0.1-10.0.0.254
add name=lan2 ranges=192.168.0.1-192.168.0.254
add name=lan3 ranges=172.16.0.1-172.16.255.254

Dit moeten we natuurlijk ook als dhcp servers aanmaken:

/ip dhcp-server
add address-pool=lan disabled=no interface=LAN-bridge lease-time=1d name=LAN
add address-pool=lan2 disabled=no interface=LAN2-bridge lease-time=1d name=LAN2
add address-pool=lan3 disabled=no interface=LAN3-bridge lease-time=1d name=LAN3

In dit voorbeeld kiezen we voor een lease van 1 dag. Een afgegeven IP wordt dus voor minimaal 24 uur gereserveerd.

Bij gasten netwerken die openbaar zijn kan dat misschien beter nog lager worden gezet. 1h bijvoorbeeld, 1 uur.

In netwerken met weinig apparaten kan zelfs voor 1 week worden gekozen (1w)
Ik vind een dag echter mooi zat.

Nu gaan we onze poorten koppelen aan de bruggen:

/interface bridge port
add bridge=LAN-bridge disabled=no interface=ether2-LAN
add bridge=LAN2-bridge disabled=no interface=ether3-LAN2
add bridge=LAN3-bridge disabled=no interface=ether4-LAN3

Nu hebben we 3 fysieke poorten op de Mikrotik met daar op 3 losse netwerken en nu moeten we daar dus de DHCP servers naar laten verwijzen, we willen wel automatisch adressen hebben wanneer we er iets aan hangen:

/ip address
add address=10.0.0.1/24 disabled=no interface=LAN-bridge
add address=192.168.0.1/24 disabled=no interface=LAN2-bridge
add address=172.16.0.1/24 disabled=no interface=LAN3-bridge

De /24 achter het adres staat voor 255.255.255.0 als subnetmask in CIDR notatie. Prima voor een thuis netwerk, laten we dit dus even simpel houden.

Vervolgens moeten we ook nog de adressen van de default gateway toekennen:

/ip dhcp-server network
add address=10.0.0.0/8 comment="lan" dns-server=8.8.8.8 gateway=10.0.0.1 netmask=24
add address=192.168.0.0/24 comment="lan2" dns-server=8.8.8.8 gateway=192.168.0.1 netmask=24
add address=172.16.0.0/16 comment="lan3" dns-server=8.8.8.8 gateway=172.16.0.1 netmask=24

Wederom keert de 24 hier weer terug.

De default gateway wordt onze toegang tot het internet.
De dns server is 8.8.8.8, oftewel google DNS.

De DNS komen we later in een andere blog over de Pi-Hole op terug. Voor nu is het prima.

We hebben nu alleen 1 ding gemist:

Onze default gateway hebben we wel opgevoerd in de DHCP-server, maar dat gaat zo niet werken. Wat we nu nog niet doen is het daadwerkelijke internet verkeer beschikbaar maken. Dit komt aan op ether1-UPLINK en is feitelijk onze toegang tot de DMZ. Dit moeten we dus nog gaan routeren. De wijze hoe heet NAT. NAT is kort voor Network Adress Translation We gaan eerst voor een werkende configuratie zonder IPTV, die kan je namelijk ook rechtstreeks op je modem steken voor nu.

Terug naar NAT

We kijken even in de handleiding:
https://wiki.mikrotik.com/wiki/NAT_Tutorial is een optie, maar het staat iets simpeler in https://wiki.mikrotik.com...o_configure_a_home_router

We gaan beginnen met onze 1e netwerkpoort automatisch een IP op te laten halen op ons modem:

/ip dhcp-client
add interface=ether1-UPLINK add-default-route=yes use-peer-dns=yes

We hebben op dit moment nog steeds geen internet op de poorten.

De volgende stappen in dit verhaal zijn:

- NAT gebruiken als gateway,
- DMZ door laten verwijzen naar de Mikrotik
- Configureren van de firewall
- Port forwarding.

Als we dat onder de knie hebben kunnen we virtuele netwerken aanmaken, en Wifi inclusief meerdere vlans instellen of Mikrotiks koppelen via het LAN of door de lucht. Maar klaar voor nu, anders wordt de serie wel wat kort :)

En wie vindt als eerste de fout in deze blogpost... Ik ben namelijk het aller aller belangrijkste deel bewust vergeten.... De eerste die het in de comments meldt wint eeuwige roem!

Volgende keer gaan we compleet NAT

Hackers op je netwerk!

Door fvdberg op maandag 16 april 2018 17:20 - Reacties (10)
Categorie: -, Views: 6.958

Mijn blog behandeld de laatste tijd te vaak politieke of sociale zaken, en hoewel ook daar veel aan te tweaken is wil ik weer eens terug naar de oorsprong:

Howto's

Wel merk ik dat ik het schrijven leuk vind. Ik wil dus de howto's iets minder algemeen maken, en meer projecten plaatsen die Algemene, Sociale of door de politiek veroorzaakte (privacy) problemen oplossen. Een goede start daarbij lijkt me IoT wat echt een onderschat veiligheidsrisico is. Daarbij wil ik beginnen met het probleem eerst te bespreken in dit blog en daar later een leuke oplossing uitwerken d.m.v. Howto's die steeds iets dieper gaan binnen de focus. Dus ja ook darknets, VPN's en zaken als TOR komen aan bod.

Daarnaast wil ik in een aparte reeks een stapje in de richting van de ontwikkelaars gaan:
Hoe kan je voorkomen dat je apparatuur misbruikt wordt, Hoe kan je voorkomen dat anderen meekijken met wat jij doet maar ook gedachten delen over de inrichting van dergelijke systemen. Als ontwikkelaars hebben we de verantwoordelijkheid om vele issues op klant niveau op te lossen die ons tegelijkertijd ook extra voordelen opleveren. Welke? Daar kom ik later op terug.

Ik hoor graag hoe jullie hier over denken.

Als eerste wil ik beginnen met IoT.

Internet of Things

Een koppeling met het internet wordt door veel leveranciers als iets standaard gezien maar vrijwel nergens wordt iets over de impact gemeld die dit kan hebben. Er zijn steeds meer nieuws artikelen te vinden over actief misbruik van lekken in deze categorie. Ik trek deze categorie echter iets breder als enkel koelkasten... het eerste wat men als IoT ziet dankzij de media. Ik denk dan ook dat we dit probleem echt in een veel breder spectrum als IoT moeten zien.

Hoe breed?

Zo breed als mogelijk. We gaan eerst even helemaal terug naar de basis.De meeste huis tuin en keuken netwerken hebben routers/modems die niet actief beheerd kunnen worden of beheerd worden door de internet providers. Inzage in het daadwerkelijke verkeer is niet mogelijk. Laat staan filteren of blokkeren. Je weet nooit wat er precies gebeurt als je de mogelijkheden en de middelen niet hebt om actief te beheren. Dit in combinatie met functionaliteiten die de gebruikers ontlasten zo als automatische configuratie van de benodigde in en uitgaande poorten via UPNP betekend het dat je gratis een flink lek erbij hebt gekregen.

Weet je echt zeker dat niemand in je netwerk kan?

Een mooi voorbeeld is een IP camera van een prijsstunter die redelijk simpel overgenomen kan worden. Daarbij kan er meegekeken worden, maar ook terug gepraat worden. Je kind zal maar zo'n camera op de kamer hebben.... Wanneer dit een camera is in een openbare kleedkamer wordt er moord en brand geschreeuwt... zelfs als het een gesloten circuit is zonder connectie met internet. Dit is een van de ergste vormen van privacy schending... ze zullen je maar opnemen in je blote lus... of erger... Maar je zet wel die webcam van die prijsstunter neer zonder er over na te denken...
De afgelopen tijd zijn er echt veel leuke voorbeelden geweest van IP-Camera's die openbaar aan het internet hangen.

Als voorbeeld: http://www.insecam.org/

Maar het gaat nog verder...

Apparaten waar je het niet van verwacht kunnen volledige toegang tot je netwerk geven. Met de huidige trend van het automatiseren is er een nieuw probleem: slimme thermostaten
In Amerika is er een casino gehacked via een thermometer de in een vertrouwd netwerk is gehangen.

Zie http://frontpage.fok.nl/n...ackt-via-thermometer.html

Verder hebben we ook nog de Ransomware attacks als Wannacry, Petya en NotPetya.
https://internetofbusiness.com/petya-notpetya-iot-security/

Het volgende target wordt bijna zeker "IoT"

Je moet eerst een bitcoin betalen voor je bij je magnetron maaltijd mag!
"Even" een apparaat ondoordacht in je netwerk hangen is niet slim en kan zelfs gevaarlijk zijn en verregaande gevolgen hebben voor zover dat nu al niet zo is. Het belang van een actief beheer van toegang op het netwerk is enkel alleen om die reden al gewenst.

Actief beheer gaat veel verder als een pakket als Kaspersky Total Internet Security, Ziggo Safe Online of KPN Veilig (beide F-Secure) op je laptop installeren. Dat is verreweg onvoldoende omdat dit alleen de daadwerkelijke PC waar het op staat beschermt en je feitelijk nog steeds vertrouwt op het werk van anderen.
Het gaat dus niets doen voor je smart tv of thermostaat. Als jou thermostaat als "man in the middle" gebruikt zou kunnen worden moet jij dus ook een "man in the middle" in je netwerk hebben die letterlijk inzage heeft en geeft in met wie er gecommuniceerd wordt en op welke poort. En eigenlijk zpu je ook exact willen weten wat al is dat weer een privacy gevoelig iets.
Al is het alleen maar om te voorkomen dat je thermostaat met een ander als de fabrikant of jezelf communiceert. Een thermostaat heeft echt niet meer toegang nodig, dus waarom zouden we hem dit geven? En UPNP... super handig vanuit de gedachte dat je gebruikers niet op moet zadelen met technische handelingen, maar als er met security verder niks gedaan wordt is het gewoon een lek. En dat is iets wat we bij veel IoT apparatuur zien. Er worden via UPNP niet standaard poorten open gezet zonder dat bekend is waarom.
Vaak is er een Linux achtige terminal aanwezig die als ie al versleuteld is met SSL toegankelijk is met niet al te sterke (vaak standaard) wachtwoorden. Net als een webinterface op poort 80 met als gebruikersnaam en wachtwoord admin en admin. Over het algemeen is er totaal niet over de veiligheid nagedacht of zijn er van fabriekswege al issues in de firmware aanwezig. Vervolgens is er door het karakter van IoT (Internet of Things) vrij lastig te definieren is welk verkeer mag of niet. En ja ook je router van je provider heeft dit issue. Deze kan je enkel als DMZ (De-Militarized Zone) gebruiken. Oftewel wanneer je je internet verkeer beheert op je systeem met een pakket als de F-Secure Ziggo/KPN pakketten is het relatief veilig. Nog steeds onvoldoende in mijn ogen... maar beter als niets doen. Een slimme thermostaat? No way! Die wil ik nooit in een DMZ zien! De reden weet je. Toch doe je het. En stiekem vaker als je denkt! Niet alleen met thermostaten.

We moeten dus als we IoT apparatuur willen gebruiken ook een beveiliging/structuur aanbrengen in ons thuisnetwerk maar om nu gelijk een "Barracuda" op te hangen... Dat gaat wat ver. Nog buiten dat het slechts een merk is met een oplossing ipv een oplossing. Toch wil ik die meuk niet direct in mijn netwerk hebben,
Ook wil ik zeker weten dat die meuk communiceert en met wie. Dit zodat ik uit kan sluiten dat het met zaken communiceert waarvan ik absoluut niet wil dat het communiceert. Aangezien die zooi allemaal op wifi werkt tegenwoordig wil ik daar een apart V-Lan / SSID voor maken. Dat geeft ons een iets gerichtere focus. Maar we willen er natuurlijk wel gewoon als vanouds bij kunnen vanuit het interne netwerk. We zullen een oplossing moeten vinden..

Ook op een laag budget zijn er mogelijkheden! De kosten van bijvoorbeeld de Mikrotik Routerboard producten en daarbij een Raspberry Pi Zero met pi-hole als DNS maken wel dat we voor relatief weinig geld iets kunnen configureren waarmee we in elk geval de controle terug kunnen krijgen. Ik wil voor deze blogserie een budget van maximaal 50 euro pakken. We gaan in het volgende blogje beginnen met een stukje introductie en basis configuratie van een simpele Mikrotik HAP Lite van minder als 30 euro. Later pakken we een raspberry pi zero van minder als een 10 tje.

Ik heb er zin in en jullie?