W związku z tym, aby stworzyć tablicę, należy przełożyć powyższe na język firewalla. Firewallem w Fikcyjnej Firmie niech będzie dla przykładu Checkpoint NGX.

Zgodnie z pkt. 1 polityki mamy umożliwić pracownikom dostęp do dowolnych serwisów WWW. Dodatkowo tylko wtedy, jeżeli będą przebywać na terenie firmy - zob. ekran 1.

A więc pozwalamy na wszystkie połączenia wychodzące z sieci LAN przy użyciu protokołów HTTP i HTTPS. Nie interesuje nas, jakie strony są odwiedzane, więc możemy odpuścić sobie rejestrowanie (reguła nr 1). Punkt pierwszy rozwiązany. Ale czy na pewno? Polityka bezpieczeństwa o tym nie wie, ale żeby korzystać z zasobów Internetu, wypadałoby umożliwić rozwiązywanie nazw. W Fikcyjnej Firmie taką rolę pełnią dwa serwery DNS znajdujące się w sieci LAN i niedostępne z Internetu (obydwa serwery zgrupowane są w obiekcie LAN_DNS). Pozwalamy więc użytkownikom na wysyłanie zapytań do tych serwerów (reguła nr 2) - zob. ekran 2.

Warto zwrócić uwagę na to, że zezwoliliśmy tylko na ruch UDP/53. Przejdźmy do pkt. 2. Zapewniamy dostęp pracownikom do firmowej poczty elektronicznej. A więc pozwalamy im na zarówno wysyłanie, jak i odbieranie poczty (reguła nr 3) - zob. ekran 3.

Jest jeszcze coś, o czym polityka nie mówi, a co musimy uwzględnić, żeby zrealizować wymagania pkt. 2. W Fikcyjnej Firmie SA mamy dwa serwery pocztowe - wewnętrzny i zewnętrzny. Użytkownicy wysyłają i odbierają pocztę tylko z serwera wewnętrznego. Ale żeby dostawać pocztę z zewnątrz, wewnętrzny serwer pocztowy co 3 min pobiera pocztę z serwera w DMZ (reguła nr 4) - zob. ekran 4.

Tutaj włączyliśmy rejestrowanie połączeń. W następnej kolejności musimy pozwolić naszemu serwerowi pocztowemu na wysyłanie poczty w świat z wyjątkiem przekazywania jej dalej do DMZ (reguła nr 5). Jak widać, nie pozwoliliśmy serwerowi pocztowemu w DMZ na inicjowanie jakichkolwiek połączeń do sieci LAN. Zatem gdyby został zaatakowany, nie nawiąże kontaktu z siecią wewnętrzną - zob. ekran 5.

Chwilowo pominiemy pkt 3 polityki. Wrócimy do niego później. Zajmijmy się pkt. 4 i pozwólmy użytkownikom na korzystanie z Gadu-Gadu (reguła nr 6) - zob. ekran 6.

Do tej pory zajmowaliśmy się pracownikami firmy. Pora teraz na umożliwienie internautom dostępu do serwisu WWW umieszczonego na serwerze w DMZ (reguła nr 7) - zob. ekran 7.

No i na "deser" pozostał nam pkt 6 polityki. Z pozoru prosty do spełnienia, a jednak ze względu na lakoniczność jego sformułowania wcale nie oczywisty. Jako osoby odpowiedzialne za bezpieczeństwo musimy wymyślić, jak sprawić, aby administratorzy mogli bezpiecznie zarządzać usługami i to bez względu na swoje położenie. Cóż, jeżeli podłączeni są do sieci lokalnej firmy, to sprawa jest prosta (reguła nr 8). Wiemy, że administratorzy będąc w firmie używają tylko swoich komputerów biurkowych. Zatem możemy tym osobom zezwolić na dostęp do odpowiednich zasobów. Przykładem niech będzie administrator intranetowego serwisu WWW. Zarządza on swoimi usługami z poziomu konsoli SSH oraz przeglądarki pracującej na odpowiednim porcie - zob. ekran 8.

A co zrobić, żeby zapewnić naszemu administratorowi tak samo bezpieczny dostęp kiedy jest poza firmą? Od czego mamy VPN. Pominiemy, rzecz jasna, kwestie konfiguracji samej usługi. A zatem użytkownik admin_www może połączyć się do swojego serwera będąc poza firmą tylko wówczas, jeżeli uczyni to przez kanał VPN w połączeniu typu client-to-site (reguła nr 9) - zob. ekran 9.

To już prawie wszystko. Mamy tablicę reguł, ale brakuje w niej porządku. Poza tym kilku rzeczy jeszcze nie wzięliśmy pod uwagę. To, że spełniliśmy wymogi polityki bezpieczeństwa, nie oznacza, że możemy spocząć na laurach. Zacznijmy od tego, czego brakuje. Dobrą zasadą jest, aby na początku każdej tablicy zablokować bezpośredni dostęp do firewalla z zewnątrz. Tworzymy więc tzw. regułę niewidkę. Jeszcze rzut oka na tablicę i okazuje się, że nie zajęliśmy się ruchem nieujętym w stworzonych regułach. Teoretycznie nie musimy nic robić, bo - jak wiemy - wszystko co nie pasuje do reguł jest odrzucane. My jednak nie jesteśmy o tym informowani. Dlatego też ostatnią regułą będzie taka, która rejestruje wszystkie odrzucone połączenia.

Kolejna sprawa to zapewnienie sobie dostępu do firewalla - my też przecież jesteśmy administratorami. Dodaliśmy regułę niewidkę na początku tablicy, więc aby nie odciąć sobie dostępu do zapory, regułę administracyjną utworzymy tuż przed niewidką. Jeszcze jedno - DMZ. Jako strefa niezaufana powinna być objęta szczególną uwagą, a połączenia z niej do LAN z całą bezwzględnością blokowane. Ślad takiego kontaktu może oznaczać obecność intruza w DMZ. Samo rejestrowanie zatem nie wystarczy. Potrzebny jest alarm, który poinformuje o niebezpieczeństwie. Skoro już zajęliśmy się porządkami, dodajmy jeszcze regułę, która odetnie dopływ hałaśliwych pakietów netbiosa do naszej zapory. Zobaczmy, jak te uwagi wyglądają w odniesieniu do naszej tablicy reguł - zob. ekran 10.

Teraz pora na ostateczny szlif, czyli ułożenie reguł w odpowiedniej kolejności, podzielenie na sekcje dla lepszej czytelności. No i jeszcze kwestia pkt. 3 polityki. Sprawę korzystania z prywatnej poczty rozwiązaliśmy niejako przy okazji. Nigdzie nie zezwoliliśmy na dostęp do poczty poza naszą siecią zarówno po smtp, jak i pop3. Rzecz jasna, sprytni użytkownicy mogą ominąć to zabezpieczenie, tunelując ruch. Ale to już osobny temat. Jest jeszcze kwestia dostępu do poczty przez portale webowe. Możemy bawić się dodatkowo blokując ruch z najpopularniejszymi portalami, ale nie o to przecież chodzi.

Teraz po ciężkim dniu z dumą możemy spojrzeć na gotową tablicę reguł - ekran 11.

I na końcu doprawić

Jak widać, budowa reguł w firewallach nie jest rzeczą bardzo skomplikowaną, ale też nie można do tego zadania podejść "z biegu". Sama budowa reguł to przedostatni etap zarządzania zaporą. Potem zostaje już tylko nigdy niekończąca się troska o właściwe funkcjonowanie zabezpieczeń. A pracy jest sporo. Jeżeli weźmiemy pod uwagę stale rozrastającą się infrastrukturę informatyczną, szybko okaże się, że pod naszą opieką mamy kilka zapór, każda od innego producenta, z czego dwie stoją na styku z Internetem, a kolejne dwie kontrolują ruch pomiędzy departamentami. Jeżeli do tego dołożymy konieczność współistnienia z innymi rozwiązaniami zabezpieczającymi, to całość staje się dość skomplikowaną łamigłówką. Czeka nas zatem sporo planowania, główkowania i nauki. Ale czy nie o to właśnie chodzi? Przecież satysfakcja po trudach jest największa.