Testa dina brandväggsregler utifrån

En kontroll före och efter

Kör skanningen innan du ändrar en regel och igen efteråt. Skillnaden är ditt bevis. Om du till exempel tog bort en gammal tillåtelseregel för MySQL visar första skanningen 3306 och den andra gör det inte.

Varför skannens källa spelar roll

Brandväggar tillåter ofta vissa källadresser, till exempel ditt kontor. Den här skanningen kommer från en delad publik adress, så den ser det en vanlig besökare ser. Om din regel bara tillåter kontorets IP kommer en korrekt uppsättning att visa porten som saknad här, även om du kan ansluta från kontoret.

Vad ett rent resultat bevisar

Det bevisar att ingen av de 18 listade portarna accepterade en anslutning från skannern vid den tidpunkten. Det bevisar inte att resten av de 65 535 portarna är stängda, och UDP kontrolleras inte. Stängd, filtrerad och offline-värd ser identiska ut, så bekräfta också att värden är uppe genom att kontrollera en port som ska vara öppen.

Goda vanor

• Testa en ändring i taget, så att du vet vilken regel som gav vilken effekt.
• Ge molnreglerna tid att tillämpas innan du skannar.
• Skanna bara adresser som du äger eller har tillstånd att testa.

Vanliga brandväggslager

Trafik passerar ofta flera lager: en molnsäkerhetsgrupp, en nätverks-ACL, en brandvägg på värden som iptables eller ett liknande verktyg, och ibland en hårdvaruapparat. En port är nåbar bara när alla lager tillåter den, och blockerad när något av dem nekar. När ett skanningsresultat överraskar dig ska du kontrollera varje lager i tur och ordning, inte bara det du ändrade senast.

Kom också ihåg att en tillåten port utan något som lyssnar bakom sig fortfarande ser stängd ut. Skanningen kan bara säga om en anslutning accepterades eller inte. Anteckna varje skanning med datum och öppna portar. Det gör nästa granskning snabbare och visar när en oväntad port först dök upp.