[MikroTik-apparatuur] Ervaringen & Discussie

[Thralas]

Mit-46 schreef op vrijdag 10 april 2026 @ 09:57:
Zit er ook aan te denken om de boel straks te resetten en te beginnen met de default config en vanuit daar het verder in te gaan stellen om te kijken hoe dat eruit ziet.

Ja, dat moet je absoluut doen.

De default config heeft een firewall die veilig is. Een lege config komt ook zonder firewall en dat is (zoals je hebt gemerkt) echt niet veilig. Voeg aan de default config alleen regels toe die je begrijpt.

Om nog maar eens driedubbel te benadrukken: je wil de managementinterfaces nooit openstellen voor het internet. Als ze het wachtwoord niet raden dan is je router na een paar maanden alsnog gehackt zodra er weer eens een kwetsbaarheid in de managementinterface blijkt te zitten. Er is precent genoeg.

Het alternatief heb je gelukkig al ontdekt: Back To Home zet een VPN op: dat is een uitstekende manier om er wél bij te kunnen vanaf het internet.

[Mit-46]

dubbel

[ Voor 99% gewijzigd door Mit-46 op 10-04-2026 10:14 ]

[Mit-46]

ed1703 schreef op vrijdag 10 april 2026 @ 09:52:
[...]

Nope, Voor Mikrotik dien je eerst een basis firewall in te richten..

code:

/ip firewall filter
add action=accept chain=input comment="accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="drop invalid" connection-state=invalid
add action=accept chain=input comment="accept ICMP" protocol=icmp
add action=drop chain=input comment="drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="drop invalid" connection-state=invalid
add action=accept chain=forward comment="accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="accept out ipsec policy" ipsec-policy=out,ipsec
add action=drop chain=forward comment="drop all from WAN not DSTNATed" connection-nat-state=!dstnat in-interface-list=WAN

Nieuwe accept regels from WAN (bijvoorbeeld Wireguard) zet je dan voor de "drop all not coming from LAN"

Een nieuw VLAN voeg je eventueel (hangt er een beetje vanaf wat de bedoeling is van dat VLAN) toe aan je interface list LAN.

Dank!
Ik ga ze straks een naast elkaar leggen.

Ik probeer mijn config te printen, maar deze stopt (of blijft hangen) bij rule 6 terwijl het er 13 zijn. Misschien even geduld hebben.

[Mit-46]

Thralas schreef op vrijdag 10 april 2026 @ 10:05:
[...]


Ja, dat moet je absoluut doen.

De default config heeft een firewall die veilig is. Een lege config komt ook zonder firewall en dat is (zoals je hebt gemerkt) echt niet veilig. Voeg aan de default config alleen regels toe die je begrijpt.

Om nog maar eens driedubbel te benadrukken: je wil de managementinterfaces nooit openstellen voor het internet. Als ze het wachtwoord niet raden dan is je router na een paar maanden alsnog gehackt zodra er weer eens een kwetsbaarheid in de managementinterface blijkt te zitten. Er is precent genoeg.

Het alternatief heb je gelukkig al ontdekt: Back To Home zet een VPN op: dat is een uitstekende manier om er wél bij te kunnen vanaf het internet.

Check!
Ga ik dat zo meteen maar doen.

Dank voor de input!

[pimlie]

@BaseBoyNL RouterOS ondersteunt een soort van fail2ban m.b.v. dynamic address lists & timeouts.

Hier hoe je dat toepast (uit de oude mikrotik docs, kan ik zo snel even geen link voor vinden). Ik heb een chain genaamd svcp-SSH dat automatisch ip addressen blokkeert als ze meer dan 3x in ca 3 minuten verbinding proberen te maken. Die 3x kan je aanpassen door meer of minder 'kleuren' te gebruiken'.

Het idee is dus dat:
- iemand verbind met SSH -> ip toegevoegd aan light gray adres lijst voor 1 min
- iemand verbind weer met SSH en zijn ip is in light gray -> gray voor 1 min
- iemand verbind weer met SSH en zijn ip is in gray -> dark gray voor 1 min
- iemand verbind weer met SSH en zijn ip is in dark gray -> geblocked voor 2 weken

Als er ip adressen zijn die je vertrouwt, voeg die dan toe aan de my-TRUSTED-IPs adres lijst zodat die nooit aan light gray worden toegevoegd. Anders blokkeer je je zelf ook als je 3x (succesvol) binnen 3 min inlogt.

code:

add action=return chain=svcp-SSH dst-port=!22 protocol=tcp
add action=return chain=svcp-SSH protocol=!tcp
add action=add-src-to-address-list address-list=SSH-BLACKLIST address-list-timeout=2w chain=svcp-SSH src-address-list=SSH-DARKGRAY
add action=drop chain=svcp-SSH src-address-list=SSH-BLACKLIST
add action=add-src-to-address-list address-list=SSH-DARKGRAY address-list-timeout=1m chain=svcp-SSH src-address-list=SSH-GRAY
add action=add-src-to-address-list address-list=SSH-GRAY address-list-timeout=1m chain=svcp-SSH src-address-list=SSH-LIGHTGRAY
add action=add-src-to-address-list address-list=SSH-LIGHTGRAY address-list-timeout=1m chain=svcp-SSH src-address-list=!my-TRUSTED-IPs
add action=accept chain=svcp-SSH

Je hoeft uiteraard niet een aparte chain te gebruiken, maar om mijn firewall overzichtelijk te houden definieer ik chain's per applicatie / port. Vervolgens kan je dan je binnenkomende verkeer via jump-targets door deze chain sturen:

code:

add action=jump chain=input in-interface-list=wans jump-target=in-WAN
add action=jump chain=in-WAN jump-target=svcp-SSH
... andere toegestane services
add action=drop chain=in-WAN

Let wel (1), je zou dit alleen moeten gebruiken voor services die je alleen voor jezelf daadwerkelijk publiekelijk toegankelijk wilt hebben. Het beste zou uiteraard zijn om enkel een adressen lijst als whitelist te gebruiken en/of om de ssh of telnet service niet op een standard port te draaien:

code:

add action=accept chain=svcp-SSH dst-port=22 protocol=tcp src-address-list=my-TRUSTED-IPs

Let wel (2), dat op mijn manier van het gebruiken van chains & jump-targets je significant meer firewall regels krijgt. Voor huis, tuin en keukengebruik zou dat niet een groot probleem moeten zijn, maar hoe meer firewall regels des te hogere latency uiteraard. Zelf vind ik een overzichtelijke firewall belangrijker.