UFW-appprofil saknas? Den beskriver portar, inte tjänster
En UFW-appprofil är en namngiven lista över portar och protokoll, inte en tjänst. Läs app info, jämför den faktiska lyssnaren och behåll en väg tillbaka innan du läser in igen.
UFW säger att det inte hittar en profil som matchar OpenSSH, och jakten på en orsak går rakt till SSH-servern. Det är fel riktning: meddelandet handlar om en namngiven brandväggsdefinition och säger ingenting om huruvida sshd är installerad, igång eller lyssnar. En UFW-appprofil är en lista över portar och protokoll med en etikett. Att läsa definitionen tar ett kommando och avslutar oftast undersökningen.
Steg 1: lista namnen som UFW faktiskt känner till
Fråga brandväggen vilka namn den har innan du ber den tillåta ett. Listan kommer från profilerna som är installerade på den här maskinen, så ett saknat namn är ett faktum om systemet och inte om programvaran du försökte skydda. Om namnet finns kom felet från ett skrivfel eller ett inaktuellt alias i skalhistoriken.
ufw app list
ufw app info OpenSSH
Listan är kort vid en standardinstallation, och namnen är inte paketnamn. En profil som heter OpenSSH kan saknas medan paketet openssh-server är installerat, och det omvända är också möjligt. Använd det exakta namn som listan skriver ut; ett VPN-profilnamn eller en skrivbordsstartare med liknande stavning är inte en UFW-appprofil. Om namnet du vill ha saknas är det fyndet, och nästa steg är att titta på vad som borde tillhandahålla det.
Steg 2: läs definitionen, inte etiketten
En profil är en fil i INI-stil under /etc/ufw/applications.d, med ett namn, en titel, en beskrivning och ett portfält. Portfältet kan lista flera portar och transporter, så etiketten säger mindre än definitionen. UFW-handboken dokumenterar dessa fält och åtgärden att uppdatera program. Läs filen i stället för att anta att namnet betyder en känd port.
cat /etc/ufw/applications.d/openssh-server
ufw app info OpenSSH
En definition som innehåller 22/tcp beskriver TCP-port 22 och ingenting annat. Den bevisar inte att daemonen på den här maskinen lyssnar där, och den täcker inte en andra port som du lade till senare. Om daemonen kör någon annanstans är profilen fel tillstånd även om namnet matchar produkten. Jämför lyssnaren med definitionen innan du tillåter någon av dem.
ss -ltnp 'sport = :22'
Stanna om definitionen och lyssnaren inte stämmer. Att tillåta en profil som namnger en port där ingen lyssnar skapar en regel som ser ut som framsteg och skyddar ingenting.
Steg 3: skilj profilen från tjänsten som körs
Att tillåta en namngiven profil installerar, startar eller konfigurerar inte tjänsten, och en tjänst som körs behöver ingen paketerad profil för att vara nåbar. Det är separata beslut som ägs av olika verktyg: pakethanteraren, tjänstehanteraren och brandväggen. Att behandla dem som ett är hur folk installerar en oönskad server för att ett symboliskt namn ska dyka upp.
För en VPN-server fortsätter uppdelningen efter att den yttre lyssnaren tillåtits. Tillståndet för porten för den krypterade transporten aktiverar inte vidarebefordran i kärnan, lägger inte till en NAT-regel och ger inte tunnelanvändare åtkomst till ett LAN. Var och en av dessa är en egen policy med sin egen granskning. En profil uppkallad efter VPN-produkten beskriver bara portarna den listar, och resten av serverkonfigurationen är fortfarande din att skriva.
Om profilen saknas och du behöver en är en granskad uttrycklig portregel eller en lokal profil under applications.d båda legitima. Att installera ett paket du inte ville ha är det inte.
Steg 4: behåll en väg tillbaka innan du läser in brandväggen igen
Innan någon regeländring, bekräfta att du har en andra väg in i maskinen: en konsol, en adress utanför bandet eller en planerad återställning. Läs sedan regeluppsättningen och standardpolicyn, eftersom ett standardnekande utan SSH-regel är det klassiska sättet att låsa ut sig under testning. Ändra en regel i taget och läs bekräftelsen som UFW skriver ut. En sparad regel, en aktiv regel och en nåbar tjänst är tre olika observationer.
ufw status verbose
ufw allow 22/tcp
ufw app update OpenSSH
Efter ändringen, testa den tillåtna anslutningen och en väg som fortfarande bör nekas. Nekandetestet betyder lika mycket som tillåtandetestet, eftersom en regel som är bredare än avsett klarar det första testet och fallerar på det andra. Anteckna profilnamnet, portarna den innehöll och lyssnaren du verifierade mot.
Checklistan slutar när namnet finns eller medvetet har ersatts, definitionen matchar den faktiska lyssnaren, tjänsten hanteras separat, och du har testat både en tillåten och en nekad väg med en återställningsväg i handen. Ett namn i listan är inget av dessa.