Un modo semplice per proteggere il tuo Mikrotik dagli attacchi

Voglio condividere con la comunità un modo semplice e funzionante per proteggere la propria rete e i servizi 'in vista' da attacchi esterni utilizzando Mikrotik. In particolare, organizzare un honeypot su Mikrotik con soli tre regole.

Immaginiamo di avere un piccolo ufficio, con un IP esterno dietro cui si trova un server RDP per il lavoro remoto dei dipendenti. La prima regola è ovviamente cambiare la porta 3389 sull'interfaccia esterna in un'altra. Ma questo non durerà a lungo; dopo pochi giorni, il registro di audit del server terminale inizierà a mostrare diverse autorizzazioni non riuscite al secondo da client sconosciuti.

In un'altra situazione, avete un asterisk nascosto dietro Mikrotik, naturalmente non sulla porta udp 5060, e dopo un paio di giorni inizia anche qui il tentativo di indovinare le password... sì, lo so, fail2ban è la nostra salvezza, ma richiede ancora un po' di lavoro... per esempio, io recentemente l'ho installato su ubuntu 18.04 e con sorpresa ho scoperto che, di default, fail2ban non contiene impostazioni aggiornate per asterisk della stessa versione di ubuntu... e non è possibile cercare impostazioni rapide di 'ricette' pronte, i numeri delle release aumentano nel tempo e gli articoli con 'ricette' per le versioni vecchie non funzionano più, mentre nuove ricette sono quasi assenti... Ma, scusate, mi sono distratto...

Quindi, cosa è un honeypot in poche parole - è una trappola; nel nostro caso, un porto popolare su un IP esterno, qualsiasi richiesta a quel porto da un client esterno inoltra l'indirizzo src nella 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 sui porti TCP popolari 22, 3389, 8291 dell'interfaccia esterna ether4-wan inoltra l'IP dell'ospite nella lista 'Honeypot Hacker' (le porte per ssh, rdp e winbox sono state preventivamente disattivate o cambiate). La seconda fa lo stesso sul popolare UDP 5060.

La terza regola, durante la fase di prerouting, scarta i pacchetti degli 'ospiti' il cui srs-address è finito in 'Honeypot Hacker'.

Dopo due settimane di funzionamento del mio Mikrotik domestico, la lista 'Honeypot Hacker' ha accumulato circa millecinquecento indirizzi IP di chi ama 'tenere sotto controllo' le mie risorse di rete (a casa ho la mia telefonia, email, nextcloud, rdp). Gli attacchi di brute-force sono cessati, è giunto il paradiso.

Al lavoro non è stato così semplice, lì il server rdp continua a essere violato con tentativi di indovinare le password.

A quanto pare, il numero della porta è stato determinato da uno scanner molto prima dell'attivazione del honeypot, e durante il periodo di quarantena non è così semplice riconfigurare più di 100 utenti, di cui il 20% ha più di 65 anni. Nel caso in cui non si possa cambiare la porta, c'è una piccola ricetta funzionante. Ho visto qualcosa di simile su internet, ma qui c'è un miglioramento 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, il cliente remoto può effettuare solo 12 nuove "richieste" a RDP server. Un tentativo di accesso equivale a da 1 a 4 "richieste". Con la 12esima "richiesta" scatta il blocco per 15 minuti. Nel mio caso, gli aggressori non hanno smesso di tentare di violare il server, si sono adattati ai timer e ora lo fanno molto lentamente; questa velocità di tentativi riduce l'efficacia dell'attacco a zero. I dipendenti dell'azienda non avvertono praticamente alcun disagio nelle loro attività a causa delle misure adottate.

Un altro piccolo trucco
Questa regola si attiva secondo una programmazione all'una di notte e si disattiva alle 5, quando le persone stanno sicuramente dormendo, mentre i tentativi automatizzati continuano a rimanere 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_stage8

Già alla ottava connessione, l'IP dell'aggressore viene inserito nella blacklist per una settimana. È fantastico!

In aggiunta a quanto detto sopra, aggiungo un link a un articolo di Wiki con una configurazione funzionante per proteggere il Mikrotik dagli scanner di rete. wiki.mikrotik.com/wiki/Drop_port_scanners

Sui miei dispositivi, questa configurazione funziona insieme alle regole di honeypot sopra descritte, completandole bene.

UPD: Come suggerito nei commenti, la regola di drop dei pacchetti è stata spostata in RAW, per ridurre il carico sul router.

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server 🔥 Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster