Voglio condividere con la comunità un metodo semplice e funzionante per proteggere la propria rete e i servizi esposti tramite il Mikrotik dagli attacchi esterni. In particolare, con tre semplici regole si può organizzare un honeypot su Mikrotik.
Immaginiamo di avere un piccolo ufficio con un server RDP dietro un IP pubblico per il lavoro remoto dei dipendenti. La prima regola è ovviamente cambiare la porta 3389 sull'interfaccia esterna in un'altra. Ma questo è solo un rimedio temporaneo; dopo pochi giorni, il registro di audit del server terminale inizierà a mostrare diversi tentativi di accesso non riusciti al secondo da clienti sconosciuti.
Un'altra situazione: hai un Mikrotik con Asterisk nascosto, naturalmente non sulla porta UDP 5060, e dopo un paio di giorni inizia la forza brutale delle password... sì, lo so, fail2ban è la nostra salvezza, ma ci sarà ancora da lavorarci sopra... Io, per esempio, ho recentemente configurato fail2ban su Ubuntu 18.04 e con sorpresa ho scoperto che, di default, fail2ban non ha impostazioni aggiornate per Asterisk dallo stesso pacchetto di Ubuntu... e non riesco più a trovare rapide configurazioni nei 'recipe' di Google; i numeri delle release aumentano con gli anni, mentre gli articoli con 'recipe' per versioni più vecchie non funzionano più, e di nuovi ce ne sono pochi... Ma sto divagando...
Quindi, cos'è un honeypot in poche parole? È un'esca; nel nostro caso, un qualche porto popolare su un IP esterno: qualsiasi richiesta a questo porto da un client esterno invia l'indirizzo src in blacklist. Tutto qui.
/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"
La prima regola per le porte TCP popolari 22, 3389, 8291 dell'interfaccia esterna ether4-wan invia l'IP del 'visitatore' nella lista 'Honeypot Hacker' (le porte per ssh, rdp e winbox sono state preventivamente disabilitate o cambiate in altre). La seconda fa lo stesso per la popolare UDP 5060.
La terza regola, nella fase di prerouting, scarta i pacchetti dei 'visitatore' il cui indirizzo srs è finito nella lista 'Honeypot Hacker'.
Dopo due settimane di utilizzo del mio Mikrotik domestico, la lista "Honeypot Hacker" ha registrato circa millecinquecentoventi indirizzi IP di persone che amano "prendere per il collo" le mie risorse di rete (ho la mia telefonia, email, nextcloud, rdp a casa). Gli attacchi di brute-force sono cessati, è arrivata la felicità.
Al lavoro non è stato così semplice, lì il server rdp continua a essere compromesso tramite tentativi di password.
A quanto pare, il numero di porta è stato individuato da uno scanner molto prima dell'attivazione del honeypot, e durante la quarantena non è così facile riconfigurare oltre 100 utenti, di cui il 20% ha più di 65 anni. Nei casi in cui non si può cambiare la porta, c'è una piccola ricetta funzionale. Ho visto qualcosa di simile su internet, ma qui ci sono miglioramenti e una configurazione fine:
Regole per la configurazione del 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 minuti a un cliente remoto sono consentiti solo 12 nuovi "richieste" al RDP server. Un tentativo di accesso corrisponde a 1-4 "richieste". Al 12° "richiesta" viene attivato un blocco di 15 minuti. Nel mio caso, gli attaccanti non hanno smesso di tentare di violare il server, si sono adattati ai timer e ora lo fanno molto lentamente; questa velocità rende l'efficacia dell'attacco nulla. I dipendenti dell'azienda non riscontrano praticamente alcun disagio a causa delle misure adottate.
Un'altra piccola astuzia
Questa regola si attiva in base a un programma all'una di notte e si disattiva alle 5, quando le persone dormono e i bot automatizzati rimangono svegli.
/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_stage8Già all'ottavo collegamento, l'IP dell'attaccante viene messo in blacklist per una settimana. Che bellezza!
In aggiunta a quanto sopra, aggiungo un link a un articolo di Wiki, con una configurazione funzionante per proteggere Mikrotik da scanner di rete.
Su i miei dispositivi, questa impostazione funziona insieme alle regole honeypot descritte sopra, integrandole bene.
UPD: Come suggerito nei commenti, la regola di dropping dei pacchetti è stata spostata in RAW per ridurre il carico sul router.
Fonte: habr.com
