Manca il profilo applicazione di UFW? Descrive porte, non servizi

UFW dice di non trovare un profilo che corrisponda a OpenSSH, e la ricerca della causa porta dritta al server SSH. È la direzione sbagliata: il messaggio riguarda una definizione di firewall con nome e non dice nulla se sshd sia installato, in esecuzione o in ascolto. Un profilo applicazione di UFW è un elenco di porte e protocolli con un'etichetta. Leggere la definizione costa un comando e di solito chiude l'indagine.

Passo 1: elenca i nomi che UFW conosce davvero

Chiedi al firewall quali nomi ha prima di chiedergli di permetterne uno. L'elenco viene dai profili installati su questa macchina, quindi un nome assente è un fatto su questo sistema, non sul software che stavi cercando di proteggere. Se il nome c'è, l'errore è venuto da un refuso o da un alias obsoleto nella cronologia della shell.

ufw app list
ufw app info OpenSSH

L'elenco è breve su un'installazione predefinita, e i nomi non sono nomi di pacchetti. Un profilo chiamato OpenSSH può mancare mentre il pacchetto openssh-server è installato, e anche il contrario è possibile. Usa il nome esatto stampato dall'elenco; un nome di profilo VPN o un launcher del desktop con grafia simile non è un profilo applicazione di UFW. Se manca il nome che vuoi, questo è il risultato, e il passo successivo è guardare cosa dovrebbe fornirlo.

Passo 2: leggi la definizione, non l'etichetta

Un profilo è un file in stile INI sotto /etc/ufw/applications.d, con un nome, un titolo, una descrizione e un campo porte. Il campo porte può elencare più porte e trasporti, quindi l'etichetta dice meno della definizione. Il manuale di UFW documenta questi campi e l'operazione di aggiornamento delle applicazioni. Leggi il file invece di supporre che il nome significhi una porta nota.

cat /etc/ufw/applications.d/openssh-server
ufw app info OpenSSH

Una definizione che contiene 22/tcp descrive la porta TCP 22 e nulla più. Non dimostra che il demone su questa macchina ascolti lì, e non copre una seconda porta aggiunta in seguito. Se il demone gira altrove, il profilo è il permesso sbagliato anche se il suo nome corrisponde al prodotto. Confronta l'ascoltatore con la definizione prima di permettere l'uno o l'altro.

ss -ltnp 'sport = :22'

Fermati se la definizione e l'ascoltatore non concordano. Permettere un profilo che nomina una porta su cui nessuno ascolta crea una regola che sembra un progresso e non protegge nulla.

Passo 3: separa il profilo dal servizio in esecuzione

Permettere un profilo con nome non installa, avvia né configura il servizio, e un servizio in esecuzione non ha bisogno di un profilo pacchettizzato per essere raggiungibile. Sono decisioni separate di strumenti diversi: il gestore dei pacchetti, il gestore dei servizi e il firewall. Trattarle come una sola è il modo in cui le persone installano un server indesiderato per far comparire un nome simbolico.

Per un server VPN la separazione continua dopo che l'ascoltatore esterno è permesso. Il permesso per la porta del trasporto cifrato non abilita l'inoltro nel kernel, non aggiunge una regola NAT e non dà agli utenti del tunnel accesso a una LAN. Ognuno di questi è una politica separata con la propria revisione. Un profilo intitolato al prodotto VPN descrive solo le porte che elenca, e il resto della configurazione del server resta da scrivere a te.

Se il profilo manca e te ne serve uno, una regola di porta esplicita rivista o un profilo locale sotto applications.d sono entrambi legittimi. Installare un pacchetto che non volevi non lo è.

Passo 4: tieni una via di ritorno prima di ricaricare il firewall

Prima di qualsiasi modifica a una regola, conferma di avere una seconda via verso la macchina: una console, un indirizzo fuori banda o un rollback pianificato. Poi leggi l'insieme di regole e la politica predefinita, perché un rifiuto predefinito senza regola SSH è il modo classico di chiudersi fuori durante i test. Cambia una regola alla volta e leggi la conferma che UFW stampa. Una regola salvata, una regola attiva e un servizio raggiungibile sono tre osservazioni diverse.

ufw status verbose
ufw allow 22/tcp
ufw app update OpenSSH

Dopo la modifica, prova la connessione permessa e una via che dovrebbe restare negata. Il test di rifiuto conta quanto quello di permesso, perché una regola più ampia del previsto passa il primo test e fallisce il secondo. Annota il nome del profilo, le porte che conteneva e l'ascoltatore rispetto al quale hai verificato.

La lista di controllo finisce quando il nome esiste o è stato sostituito deliberatamente, la definizione corrisponde all'ascoltatore reale, il servizio è gestito separatamente e hai provato sia una via permessa sia una negata con una rotta di ripristino a portata di mano. Un nome nell'elenco non è nessuna di queste cose.