| Port | Åtgärd | Källa | |
|---|---|---|---|
22/tcp |
ALLOW | Anywhere | |
80/tcp |
ALLOW | Anywhere | |
443/tcp |
ALLOW | Anywhere | |
8083/tcp |
ALLOW | Anywhere | |
3306/tcp |
DENY | Anywhere | |
25/tcp |
DENY | Anywhere |
UFW finns därför att den rena iptables-syntaxen inte förlåter något, och där lyckas det. Vad det inte gör är att göra en regeluppsättning lätt att granska månader senare, när ufw status numbered returnerar trettio rader och du försöker lista ut vilka som fortfarande behövs.
Den här sidan visar samma regler men sätter standardpolicyerna för inkommande och utgående trafik överst, eftersom det är just dem man glömmer. En regeluppsättning som ser restriktiv ut betyder ingenting om standardpolicyn för inkommande trafik står kvar på allow. Reglerna visas med åtgärd, port, protokoll och källa, och IPv6-posterna står bredvid sina IPv4-motsvarigheter i stället för att dubbla listan.
Misstagen som är värda att leta efter: en port som öppnades för ett test och aldrig stängdes, en tjänst som lyssnar på alla gränssnitt när localhost hade räckt, och en regel som släpper in ett helt subnät där en enda adress hade dugt. Sidan med öppna portar visar den andra halvan av bilden: vad som faktiskt lyssnar bakom reglerna.
De här två bilderna är värda att jämföra regelbundet, för de glider isär under tystnad. En regel kan stänga en port som ingen lyssnar på — då är den bara barlast i regeluppsättningen. Det kan gå åt andra hållet också: en tjänst som lyssnar på alla gränssnitt bakom en regel du trodde var stängd. Det gamla svaret på den frågan är netstat, och det är fortfarande riktigt; utdata måste bara läsas igenom med ögonen varje gång.