Przetestuj reguły zapory z zewnątrz

Sprawdzenie przed i po

Uruchom skan przed zmianą reguły i ponownie po niej. Różnica to Twój dowód. Jeśli na przykład usunąłeś starą regułę zezwalającą na MySQL, pierwszy skan pokaże 3306, a drugi już nie.

Dlaczego źródło skanu ma znaczenie

Zapory często zezwalają na określone adresy źródłowe, na przykład Twoje biuro. Ten skan pochodzi z wspólnego publicznego adresu, więc widzi to, co widzi zwykły odwiedzający. Jeśli Twoja reguła zezwala tylko na IP biura, poprawna konfiguracja pokaże tu brak portu, mimo że z biura możesz się połączyć.

Co znaczy czysty wynik

Dowodzi, że żaden z 18 wymienionych portów nie przyjął połączenia od skanera w tym momencie. Nie dowodzi, że pozostałe 65 535 portów są zamknięte, a UDP nie jest sprawdzane. Zamknięty, filtrowany i niedostępny host wyglądają tak samo, więc potwierdź też, że host działa, sprawdzając port, który powinien być otwarty.

Dobre nawyki

• Testuj jedną zmianę naraz, abyś wiedział, która reguła wywołała który efekt.
• Daj regułom chmury czas na zastosowanie, zanim zaczniesz skanować.
• Skanuj tylko adresy, których jesteś właścicielem lub które wolno Ci testować.

Typowe warstwy zapory

Ruch często przechodzi przez kilka warstw: grupę zabezpieczeń w chmurze, ACL sieci, zaporę na hoście, np. iptables lub podobne narzędzie, a czasem urządzenie sprzętowe. Port jest dostępny tylko wtedy, gdy każda warstwa go przepuszcza, a zablokowany, gdy choć jedna go odrzuca. Gdy wynik skanu Cię zaskakuje, sprawdzaj każdą warstwę po kolei, a nie tylko tę, którą edytowałeś ostatnio.

Pamiętaj też, że dozwolony port bez niczego nasłuchującego za nim nadal wygląda na zamknięty. Skan może powiedzieć tylko, czy połączenie zostało przyjęte, czy nie. Zapisuj krótką notatkę z każdego skanu, z datą i otwartymi portami. Ułatwia to kolejny audyt i pokazuje, kiedy pojawił się nieoczekiwany port.