Un utente MikroTik VPN arriva troppo lontano: limitate a un host e una porta

Il tunnel sale, l'accesso riesce e ogni host della rete risponde. Non è una VPN guasta; è una VPN senza modello di autorizzazioni. RouterOS autentica l'account e poi instrada i suoi pacchetti come quelli di chiunque altro, quindi il firewall deve fornire il limite. Aggiungere quel limite senza rompere l'accesso è tutto il lavoro.

L'autenticazione finisce dove inizia l'autorizzazione

Una volta attiva la sessione PPP, i pacchetti del client entrano nella catena forward come il traffico di qualsiasi altra interfaccia. Se la politica forward del router è permissiva, il consulente eredita quella permissività all'accesso. L'account non ha mai portato un ambito, quindi non c'è nulla da cambiare sull'account. Il set di regole era scritto per i dipendenti e la nuova sessione vi si è semplicemente unita.

Verificate a quale percorso si riferisce la richiesta prima di scrivere qualsiasi cosa. Il traffico verso gli host dietro il router attraversa forward, mentre il traffico verso il router stesso, compresi winbox e SSH, attraversa input. Un ambito che copre solo forward lascia il dispositivo aperto allo stesso client.

Entrambe le catene richiedono una decisione, anche se la decisione è lasciare input chiuso. Quella scelta appartiene alla richiesta di accesso, non a un pensiero successivo.

Collegate la sessione a un elenco con nome

Un profilo PPP può inserire l'indirizzo che assegna in un elenco di indirizzi con nome all'avvio della sessione. Questo trasforma un indirizzo di tunnel transitorio in qualcosa che il firewall può abbinare per nome, e la voce scompare quando la sessione termina. L'account eredita quindi l'ambito dal suo profilo invece che da una regola che codifica un indirizzo in modo rigido.

Create prima il profilo, poi legatevi il secret in modo esplicito. Un secret che punta ancora al profilo predefinito riproduce il problema originale.

Nominate il profilo e l'elenco in modo che i loro compiti siano evidenti, e commentate entrambi con il riferimento della richiesta. Un profilo può servire più persone con lo stesso ambito, mentre l'elenco identifica ancora ogni sessione attiva. È meno costoso da rivedere rispetto a una regola per persona.

/ppp profile add name=scoped-consultant remote-address=consultant-pool address-list=vpn-scoped-clients
/ppp secret add name=consultant password=... service=ovpn profile=scoped-consultant

Registrate il servizio consentito in un elenco

Mettete il server consentito nel suo elenco di indirizzi invece di incorporare l'indirizzo in una regola di filtro. L'elenco può essere verificato, esteso e commentato, e la regola che lo usa non cambia quando il server si sposta. Una sola voce sembra eccessiva finché non arriva il secondo host, cosa che di solito accade.

Abbinate un elenco quando l'indirizzo è dinamico o bilanciato, e abbinate l'indirizzo direttamente quando è riservato e stabile. Entrambe le scelte si leggono chiaramente se il commento nomina il servizio e il proprietario.

Limitate il protocollo e la porta oltre all'host. Un accept per un host senza restrizione di porta apre ogni servizio che quell'host esegue, il che è più ampio di quanto intendano la maggior parte delle richieste di accesso. La porta fa parte dell'autorizzazione, non è un dettaglio da aggiungere dopo.

/ip firewall address-list add list=vpn-targets address=10.0.0.10 comment="consultant RDP target"

Ordinate il salto prima di qualsiasi accept ampio

Una regola di salto invia il traffico inoltrato dall'elenco limitato a una catena privata dove l'intera politica sta in tre righe. La prima regola accetta la destinazione e la porta consentite, e l'ultima scarta tutto il resto. Il salto deve stare sopra qualsiasi accept ampio in forward, perché un accept precedente significa che il salto non viene mai eseguito. Tenete l'accept per established e related prima del salto, così il traffico di ritorno continua a fluire.

Verificate che nessuna regola fasttrack possa portare questo traffico oltre la catena limitata. Fasttrack aggira il resto del percorso di filtro, e una sessione limitata che passa per fasttrack non è affatto limitata.

Ripetete la decisione per la catena input se i servizi del router stesso devono essere irraggiungibili. Un ambito che blocca il traffico inoltrato e lascia winbox aperto è solo a metà.

/ip firewall filter
add chain=forward action=jump jump-target=scoped-vpn src-address-list=vpn-scoped-clients
add chain=scoped-vpn action=accept protocol=tcp dst-address-list=vpn-targets dst-port=3389
add chain=scoped-vpn action=drop

Verificate con i contatori e l'appartenenza all'elenco

Dal client, provate il servizio consentito e uno che deve fallire, poi leggete le statistiche delle regole sul router. I contatori accept e drop mostrano quale percorso ha preso ogni pacchetto, cosa che il client non può vedere. Confermate anche che l'indirizzo della sessione attiva sia comparso nell'elenco limitato.

Un elenco vuoto significa che l'account è su un altro profilo o che il profilo ha perso l'impostazione dell'elenco di indirizzi. Un contatore drop che sale con un servizio consentito che fallisce significa che la destinazione o la porta non corrispondono a ciò che invia il client.

Provate lo stesso servizio per nome e per indirizzo prima di concludere qualcosa. Un errore di risoluzione dei nomi sembra esattamente una porta bloccata dal lato del client. Poi registrate il profilo, entrambi gli elenchi e l'unico servizio consentito nella richiesta di accesso, così la revisione successiva confronta invece di ricostruire.

/ip firewall filter print stats where chain=scoped-vpn
/ip firewall address-list print where list=vpn-scoped-clients