Een gemakkelijke manier om uw Mikrotik tegen aanvallen te beschermen

Ik wil met de gemeenschap een eenvoudige en werkende manier delen om Mikrotik te gebruiken om uw netwerk en de diensten die erachter "gluren" te beschermen tegen aanvallen van buitenaf. Namelijk slechts drie regels om een ​​honeypot op Mikrotik te organiseren.

Laten we ons dus voorstellen dat we een klein kantoor hebben, met een extern IP-adres waarachter een RDP-server staat waarmee werknemers op afstand kunnen werken. De eerste regel is uiteraard om poort 3389 op de externe interface te wijzigen in een andere. Maar dit zal niet lang duren; na een paar dagen zal het auditlogboek van de terminalserver verschillende mislukte autorisaties per seconde van onbekende clients gaan tonen.

Een andere situatie, je hebt een sterretje verborgen achter Mikrotik, natuurlijk niet op de 5060 udp-poort, en na een paar dagen begint ook het zoeken naar wachtwoorden... ja, ja, ik weet het, fail2ban is ons alles, maar we moeten nog steeds werk eraan... ik heb het bijvoorbeeld onlangs geïnstalleerd op ubuntu 18.04 en was verrast om te ontdekken dat fail2ban standaard geen huidige instellingen bevat voor asterisk uit dezelfde box van dezelfde ubuntu-distributie... en snelle instellingen googlen want kant-en-klare “recepten” werken niet meer, de aantallen releases groeien door de jaren heen, en artikelen met “recepten” voor oude versies werken niet meer, en nieuwe verschijnen bijna nooit... Maar ik dwaal af...

Dus wat is een honeypot in een notendop - het is een honeypot, in ons geval, elke populaire poort op een extern IP-adres, elk verzoek aan deze poort van een externe client stuurt het src-adres naar de zwarte lijst. Alle.

/ip firewall filter
add action=add-src-to-address-list address-list="Honeypot Hacker" 
    address-list-timeout=30d0h0m chain=input comment="block honeypot ssh rdp winbox" 
    connection-state=new dst-port=22,3389,8291 in-interface=
    ether4-wan protocol=tcp
add action=add-src-to-address-list address-list="Honeypot Hacker" 
    address-list-timeout=30d0h0m chain=input comment=
    "block honeypot asterisk" connection-state=new dst-port=5060 
    in-interface=ether4-wan protocol=udp 
/ip firewall raw
add action=drop chain=prerouting in-interface=ether4-wan src-address-list=
    "Honeypot Hacker"

De eerste regel op de populaire TCP-poorten 22, 3389, 8291 van de externe ether4-wan-interface stuurt het “gast”-IP naar de “Honeypot Hacker”-lijst (poorten voor ssh, rdp en winbox zijn vooraf uitgeschakeld of gewijzigd in andere). De tweede doet hetzelfde op de populaire UDP 5060.

De derde regel in de pre-routeringsfase laat pakketten vallen van “gasten” wiens srs-adres is opgenomen in de “Honeypot Hacker”.

Na twee weken met mijn thuis Mikrotik te hebben gewerkt, bevatte de lijst "Honeypot Hacker" ongeveer anderhalfduizend IP-adressen van degenen die mijn netwerkbronnen graag "bij de uier vasthouden" (thuis is er mijn eigen telefonie, mail, nextcloud, rdp). De aanvallen met brute kracht stopten en de gelukzaligheid kwam.

Op het werk bleek niet alles zo eenvoudig, daar blijven ze de RDP-server breken door brute forcering van wachtwoorden.

Blijkbaar werd het poortnummer door de scanner bepaald lang voordat de honeypot werd aangezet, en tijdens quarantaine is het niet zo eenvoudig om meer dan 100 gebruikers, waarvan 20% ouder dan 65 jaar, opnieuw te configureren. In het geval dat de poort niet kan worden gewijzigd, is er een klein werkrecept. Ik heb iets soortgelijks op internet gezien, maar er komt wat extra toevoeging en afstemming bij kijken:

Regels voor het configureren van Port Knocking

 /ip firewall filter
add action=add-src-to-address-list address-list=rdp_blacklist 
    address-list-timeout=15m chain=forward comment=rdp_to_blacklist 
    connection-state=new dst-port=3389 protocol=tcp src-address-list=
    rdp_stage12
add action=add-src-to-address-list address-list=rdp_stage12 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage11
add action=add-src-to-address-list address-list=rdp_stage11 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage10
add action=add-src-to-address-list address-list=rdp_stage10 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage9
add action=add-src-to-address-list address-list=rdp_stage9 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage8
add action=add-src-to-address-list address-list=rdp_stage8 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage4
add action=add-src-to-address-list address-list=rdp_stage7 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage6
add action=add-src-to-address-list address-list=rdp_stage6 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage5
add action=add-src-to-address-list address-list=rdp_stage5 
    address-list-timeout=4m chain=forward connection-state=new dst-port=
    3389 protocol=tcp src-address-list=rdp_stage4
add action=add-src-to-address-list address-list=rdp_stage4 
    address-list-timeout=4m chain=forward connection-state=new dst-port=
    3389 protocol=tcp src-address-list=rdp_stage3
add action=add-src-to-address-list address-list=rdp_stage3 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage2
add action=add-src-to-address-list address-list=rdp_stage2 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage1
add action=add-src-to-address-list address-list=rdp_stage1 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp 
/ip firewall raw
add action=drop chain=prerouting in-interface=ether4-wan src-address-list=
rdp_blacklist

In 4 minuten mag de externe client slechts 12 nieuwe “verzoeken” indienen bij de RDP-server. Eén inlogpoging bestaat uit 1 tot 4 “verzoeken”. Op het 12e "verzoek" - blokkering gedurende 15 minuten. In mijn geval zijn de aanvallers niet gestopt met het hacken van de server, ze hebben zich aangepast aan de timers en doen het nu heel langzaam, een dergelijke selectiesnelheid reduceert de effectiviteit van de aanval tot nul. De medewerkers van het bedrijf ondervinden op het werk vrijwel geen hinder van de genomen maatregelen.

Nog een klein trucje
Deze regel wordt volgens een schema om 5 uur 's nachts ingeschakeld en om XNUMX uur 's ochtends uitgeschakeld, wanneer echte mensen definitief slapen en geautomatiseerde plukkers wakker blijven.

/ip firewall filter 
add action=add-src-to-address-list address-list=rdp_blacklist 
    address-list-timeout=1w0d0h0m chain=forward comment=
    "night_rdp_blacklist" connection-state=new disabled=
    yes dst-port=3389 protocol=tcp src-address-list=rdp_stage8

Al bij de 8e verbinding wordt het IP-adres van de aanvaller een week lang op de zwarte lijst gezet. Schoonheid!

Welnu, als aanvulling op het bovenstaande zal ik een link toevoegen naar een Wiki-artikel met een werkende opstelling om Mikrotik te beschermen tegen netwerkscanners. wiki.mikrotik.com/wiki/Drop_port_scanners

Op mijn apparaten werkt deze instelling samen met de hierboven beschreven honeypot-regels en vormt een goede aanvulling hierop.

UPD: Zoals gesuggereerd in de opmerkingen, is de pakketdrop-regel verplaatst naar RAW om de belasting van de router te verminderen.

Bron: www.habr.com