Anty-wzory zapory?

Jakie są najczęstsze i niewłaściwe sposoby konfiguracji zapory? Rozpocznę listę od następujących czynności:

Ślepo blokuje ICMP . To była powszechna praktyka w 1998 roku, kiedy ataki smerfowe były wściekłością. Dzisiaj istnieje ryzyko utworzenia czarnej dziury PMTU i utrudnienia w diagnozowaniu problemów. Jeśli musisz zablokować ICMP, przynajmniej pozwól na fragmentację i prześlij żądanie / odpowiedzi echa.

Stare zasady . Szkoda, że ​​nie możemy ustalić daty ważności reguł. Podczas migracji usługi często zapominam o usunięciu reguł dla starej usługi.

Otwieranie go, aby działało ... a potem nigdy nie wracanie i blokowanie czegokolwiek.

W ślad za przykładem Johna - niestosowanie komentarzy do reguł, jeśli zapora je obsługuje.

Nie ma nic gorszego niż zobaczenie zapory ogniowej po raz pierwszy i zobaczenie różnego rodzaju dziwnych zasad, które nie mają sensu gołym okiem, a komentarze są puste i nie ma dokumentacji.

Jeśli chodzi o nieaktualne zasady, jak w twoim przykładzie - odpowiednia dokumentacja i procedury wyeliminują takie problemy. Sugeruję, że twój problem w ogóle nie występuje w zaporze.

Osobiście uważam, że podział reguł przychodzących i wychodzących na dwie główne grupy jest anty-wzorcem. Zmaganie się z dwiema dużymi grupami to koszmar. Wolę grupować reguły dla ruchu przychodzącego i wychodzącego związanego z określonym protokołem / aplikacją. W ten sposób łatwiej jest nimi zarządzać.

Przenieś problem w inne miejsce.

na przykład. zapora na lokalnych komputerach PC zatrzymuje działanie niektórych usług lub aplikacji, więc wyłącz ją całkowicie i powiedz „zapora na routerze brzegowym będzie w porządku, aby chronić wszystkie komputery”.

Ręczne tworzenie i utrzymywanie ich.

Starożytne skrypty innych firm, które „działają wystarczająco dobrze, abyśmy nie zawracali sobie głowy ich wymianą”, wymagają ręcznej edycji zamiast używania plików konfiguracyjnych i są całkowicie niezrozumiałe dla osób, które nie przeczytały tezy opisującej ich działanie.