Primo hardening post-installazione: la checklist completa

Perché serve una checklist

Un MikroTik appena configurato e messo online con la default config è un bersaglio: scanner e botnet provano in continuazione credenziali deboli e porte di management aperte. La maggior parte delle compromissioni reali NON sfrutta exploit esotici, ma password deboli, Telnet/API in chiaro e servizi raggiungibili dalla WAN. Questa checklist mette in fila, in ordine, i passi minimi da applicare a OGNI apparato prima della produzione.

Checklist in 8 passi

• 1. Account: crea un admin con nome non ovvio (gruppo full), disable admin, password lunga; account separato read+api per il monitoraggio
• 2. Servizi: disabilita telnet/ftp/www/api; sposta ssh di porta; limita ssh/winbox/www-ssl/api-ssl agli IP di gestione (address=)
• 3. Firewall input: droppa tutto il management dalla WAN; consenti solo le subnet di gestione (vedi sotto)
• 4. Identity + NTP: nome parlante e orologio sincronizzato (log con timestamp corretti)
• 5. MAC-server e discovery: confinati alla sola interfaccia di management
• 6. Log remoto: invia i log a un syslog centrale (sopravvivono a reboot e compromissioni)
• 7. Backup off-device: export .rsc + backup binario inviati a un server (scheduler)
• 8. Aggiorna: RouterOS al canale scelto + firmware RouterBOARD allineato

Firewall di management: il cuore dell'hardening

Limitare i servizi con address= è il primo strato; il secondo, più robusto, è una regola firewall sulla chain input che permette il management SOLO dalla rete di gestione e droppa tutto il resto. È questa regola che protegge anche se domani abiliti per errore un servizio: l'attaccante dalla WAN non arriva comunque al router.

# Prepara una address-list con le reti di gestione fidate
/ip/firewall/address-list/add list=mgmt address=192.168.100.0/24 \
  comment="LAN gestione"
/ip/firewall/address-list/add list=mgmt address=10.0.0.0/24 \
  comment="VPN amministrazione"

# Chain input: accetta connessioni stabilite, ICMP, e management dai soli mgmt
/ip/firewall/filter/add chain=input connection-state=established,related \
  action=accept comment="established/related"
/ip/firewall/filter/add chain=input connection-state=invalid \
  action=drop comment="invalid"
/ip/firewall/filter/add chain=input protocol=icmp action=accept \
  comment="ping"
/ip/firewall/filter/add chain=input src-address-list=mgmt action=accept \
  comment="management consentito"

# ...regole specifiche dei servizi della rete (DNS, DHCP verso la LAN) ...

# DROP finale: tutto il resto verso il router viene scartato
/ip/firewall/filter/add chain=input action=drop comment="drop input default"

Log centralizzato

# Definisci l'azione 'remote' verso il tuo server syslog
/system/logging/action/set remote remote=192.168.100.250 remote-port=514

# Manda topic utili (login falliti, modifiche, errori) al server remoto
/system/logging/add topics=info,!debug action=remote
/system/logging/add topics=error action=remote
/system/logging/add topics=critical action=remote

# Verifica
/system/logging/print

I log locali di RouterOS stanno in memoria volatile e si perdono al riavvio (e un attaccante li cancella). Inviarli a un syslog centrale è essenziale per audit e per ricostruire un incidente: login falliti, cambi di configurazione, drop firewall sospetti restano fuori dalla portata di chi compromette il singolo apparato.