Regles d’entrada d’SSH i VPN: què controla realment la llista d’autoritzats

Seguiu una connexió del client a l’amfitrió: quin ganxo travessa, per què una congelació i un rebuig signifiquen regles diferents i per què el rebuig mai no és una política.

Connecteu-vos una vegada abans de canviar una regla i fixeu-vos si el client es penja o el rebutgen de seguida. Aquesta única diferència us diu quina decisió ha descartat el paquet i us estalvia una hora de llegir fitxers de política. La resta del recorregut és curta: el paquet travessa un ganxo, coincideix amb una regla i arriba a un oïdor o no hi arriba. Una llista d’autoritzats només és comptabilitat al voltant d’aquests tres fets.

Seguiu un intent d’SSH fins al ganxo d’entrada

Un client envia un SYN a l’adreça de l’amfitrió pel port 22, i el nucli decideix si aquest paquet és per a un servei local. Si ho és, s’executa el camí d’entrada i el conjunt de regles accepta el paquet o el descarta. El silenci vol dir que el SYN ha mort abans que l’oïdor el vegi, mentre que un rebuig ràpid vol dir que alguna cosa ha respost amb un reset. Són veredictes diferents de regles diferents, i tots dos són resultats legítims.

Confirmeu després l’oïdor, perquè cap regla no pot salvar un servei que no hi és. Executeu ss -ltnp i comproveu que hi ha alguna cosa lligada al port i a la família d’adreces que espereu, i llegiu després ssh -v al client per veure on s’atura.

El reenviament és una decisió a part

En un servidor VPN el ganxo més interessant és forward, perquè el trànsit del client es routa a través de la màquina en lloc de lliurar-s’hi. Un amfitrió que només executa el seu propi client VPN necessita un conjunt de regles molt més petit que un que reenvia els paquets d’altres persones. Barrejar els dos dissenys en una sola màquina produeix regles que semblen correctes i no deixen passar res.

Escriviu la política interior com una pregunta pròpia: quines adreces de client poden arribar a quines destinacions a través del túnel. Manteniu el camí administratiu, com ara SSH, al camí d’entrada amb la seva pròpia restricció d’origen. Una regla forward permissiva afegida durant les proves és el defecte clàssic que sobreviu a la prova, així que reviseu el conjunt sencer de regles després d’un canvi i no la línia que heu editat. Obtenir l’oïdor del túnel no és permís perquè cada client connectat administri l’amfitrió.

Descartar i rebutjar són accions, no polítiques

La política d’una cadena base accepta o descarta, i aquesta és tota la llista d’opcions, tal com diu la referència de nftables. El rebuig existeix com a acció de regla amb una resposta triada, i per això escriure’l com a política falla tant a nftables com a iptables. A la pràctica, un drop no dona cap informació al client, mentre que un reject li dona un error amb què pot treballar.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Llegiu aquest esbós com la forma d’una decisió i no com un fitxer per enganxar, perquè els rangs d’adreces són exemples. Un reject explícit al port SSH fa que un client no autoritzat falli en un segon en lloc d’esperar un temps d’espera, cosa que escurça la vostra pròpia depuració. El silenci dissuadeix l’escaneig casual i no diu absolutament res a un usuari autoritzat. Trieu per servei i anoteu per què, perquè si no la persona següent ho tornarà a canviar.

Manteniu el trànsit de control que realment necessiteu

Bloquejar tot l’ICMP és un valor per defecte popular que trenca el descobriment d’MTU del camí, i el símptoma és una connexió que s’estableix i després s’encalla amb paquets grans. El descobriment de veïns a IPv6 depèn dels seus propis tipus d’ICMPv6, i descartar-los trenca l’enllaç abans que es consulti qualsevol regla TCP. Tots dos pertanyen a la llista d’autoritzats com a dependències anomenades i no com a permisos generals. Una política que trenca el descobriment en silenci és pitjor que una que admet una mica de trànsit de diagnòstic.

Permeteu l’estat established i related per a les connexions que heu iniciat, i deixeu que el motor amb estat gestioni les respostes. Després confirmeu que el camí de resposta no queda bloquejat més enllà, perquè una restricció només de sortida aigües amunt produeix el mateix temps d’espera que estàveu a punt de culpar l’amfitrió.

Demostreu la recuperació abans de retirar el camí antic

Manteniu una sessió de consola oberta, apliqueu el canvi i obriu una connexió de gestió completament nova des d’un altre terminal. Una sessió existent no demostra res, perquè pot sobreviure a una regla que bloqueja cada inici de sessió nou, cosa que la converteix en el fals positiu més convincent de la feina amb tallafocs. Si un sistema de monitoratge comprova l’amfitrió, afegiu-hi la seva adreça d’origen abans del canvi i no després de la primera alerta. Després proveu un paquet gran i un de petit per demostrar que el descobriment encara funciona.

Per a un servei VPN, repetiu-ho des d’un client que no s’hagi connectat mai, perquè una sessió represa pot reutilitzar estat que una de nova ha de negociar. Anoteu el conjunt exacte de regles que ha passat, amb una suma de comprovació o una còpia, perquè una edició posterior es pugui comparar en lloc d’endevinar. Coordineu-vos amb qui posseeix l’ordre de les regles, perquè una regla anterior guanya en silenci la que heu afegit.

Articles relacionats