Har du blivit uppmanad att behålla din organisations brandvägg? Detta kan vara en skrämmande uppgift, speciellt om det nätverk som skyddas av brandväggen har en mångsidig grupp av klienter, servrar och andra nätverksenheter med unika kommunikationsbehov.
Brandväggar utgör ett viktigt skyddsvärde för ditt nätverk och är en integrerad del av din övergripande försvarsnätverkssäkerhetsstrategi. Om inte hanteras och implementeras på rätt sätt kan en brandvägg i nätverket lämna gapande hål i din säkerhet, vilket tillåter hackare och brottslingar in och ut ur ditt nätverk.
Känn ditt nätverk
Så, var börjar du ens i ditt försök att tämja detta djur?
Om du bara dyker in och börjar röra med Access Control Lists (ACL), kan du oavsiktligt isolera en missionskritisk server som kan ilska din chef och få dig att sparka.
Allt nätverk är annorlunda. Det finns ingen panacea eller cure-allt för att skapa en hacker-säker nätverk brandvägskonfiguration, men det finns några rekommenderade bästa metoder för att hantera ditt nätverkets brandvägg. Eftersom varje organisation är unik kan följande vägledning inte vara "bäst" för varje situation, men det kommer åtminstone att ge dig en startpunkt för att hjälpa dig att få din brandvägg under kontroll så att du inte brinner.
Skapa en brandväggsändringsstyrelse
Att skapa en brandväggsändringskontrollpanel som består av användarrepresentanter, systemadministratörer, chefer och säkerhetspersonal kan bidra till att underlätta dialogen mellan de olika grupperna och kan bidra till att undvika konflikter, särskilt om föreslagna förändringar diskuteras och samordnas med alla som kan påverkas av dem före förändringen.
Att ha varje ändring som röstats om hjälper också till att säkerställa ansvar när problem som hänför sig till en viss brandväggsändring inträffar.
Varningsanvändare och administratörer före ändring av brandväggsregeln
Användare, administratörer och serverkommunikation kan påverkas av ändringar i din brandvägg. Även till synes små förändringar i brandväggsregler och ACL kan ha stora konsekvenser för anslutningen. Av denna anledning är det bäst att varna användarna för att föreslå ändringar i brandväggsregler. Systemadministratörer bör få veta vilka ändringar som föreslås och när de ska träda i kraft.
Om användare eller administratörer har några problem med föreslagna brandväggsregeländringar, bör det ges tillräckligt med tid (om möjligt) så att de kan röra sina problem innan ändringar görs, om inte en nödsituation uppstår som kräver omedelbara ändringar.
Dokument alla regler och använd kommentarer för att förklara syftet med särskilda regler
Att försöka lista ut syftet med en brandväggsregel kan vara svårt, särskilt när den person som ursprungligen skrev regeln har lämnat organisationen och du är kvar för att försöka lista ut vem som kan påverkas av regelns borttagning.
Alla regler ska vara väl dokumenterade så att andra administratörer kan förstå varje regel och bestämma om det behövs eller ska tas bort. Kommentarer i reglerna bör förklara:
- Syftet med regeln.
- Den tjänst som regeln gäller för.
- Användarna / servrarna / enheterna som påverkas av regeln (vem är den för?).
- Det datum som regeln lagts till och tidsramen att regeln behövs (det vill säga är det en tillfällig regel?).
- Namnet på brandväggsadministratören som lagde till regeln.
Undvik användning av "Any" i "Allow" -regler för brandväggar
I Cyberoams artikel om brandvägsbestämda bästa praxis förespråkar de att man undviker användningen av "Alla" i "Tillåt" brandväggsregler på grund av potentiella problem med trafik och flödesstyrning. De påpekar att användningen av "Alla" kan ha en oavsiktlig följd av att tillåta varje protokoll genom brandväggen.
"Förneka alla" först och lägg sedan till undantag
De flesta brandväggar behandlar sina regler i följd från toppen av listan över regler till botten. Regelns ordning är mycket viktigt. Du kommer sannolikt att ha en "Deny All" -regel som din första brandväggsregel. Detta är det viktigaste av reglerna och dess placering är också avgörande. Att sätta "Neka alla" -regeln i position # 1 säger i grunden "Håll alla och allt ute först och då bestämmer vi vem och vad vi vill släppa in".
Du vill aldrig ha en "Allow All" -regel som din första regel eftersom det skulle besegra syftet att ha en brandvägg, som du bara har låtit alla komma in.
När du har "Your Deny All" -regeln på plats # 1 kan du börja lägga till dina tillåtningsregler under det för att låta specifik trafik in och ut från ditt nätverk (förutsatt att din brandvägg behandlar regler från början till botten).
Granska regler regelbundet och ta bort oanvända regler på en vanlig basis
Av både prestanda och säkerhetsskäl kommer du att vilja "spring clean" dina brandväggsregler regelbundet. Ju mer komplexa och många dina regler är, desto mer prestanda kommer att påverkas. Om du har regler som är byggda för arbetsstationer och servrar som inte ens finns i din organisation, så kanske du vill ta bort dem för att hjälpa till att minska dina regler för bearbetningskostnader och hjälpa till att sänka det totala antalet hot vektorer.
Organisera brandväggsregler för prestanda
Beställningen av dina brandväggsregler kan ha stor inverkan på nätverkstrafikens genomströmning. eWEEk har en bra artikel om bästa praxis för att organisera dina brandväggsregler för att maximera trafikhastigheten. Ett av deras förslag innefattar att ta bort några av bördorna från din brandvägg genom att filtrera lite oönskad trafik ut via dina kantrutrar.
