Dlaczego Linuks z iptables nie nadaje się na "poważny" firewall? Iptables to kawał porządnego narzędzia, jednak nie zaryzykowałbym wykorzystanie tego rozwiązania w "poważnych" zastosowaniach. Zamiast tego wykorzystałbym pf i OpenBSD.
Dlaczego? Cóż, przyznam szczerze, że pf jeszcze nie znam tak dobrze jak iptables, używam go w dość prymitywnym zakresie (ale wystarczającym). Wydaje mi się, że więcej "cudów" można zrobić jednak w iptables, jednak nie zawsze chodzi o to, by można było robić owe "cuda". Czasami chodzi po prostu o to, by działało. Czyli pojawia się magiczne słowo dostępność. Nie, nie niezawodność, a dostępność. Nie ma rozwiązań całkowicie niezawodnych, ale jednak są rozwiązania wysoko dostępne. Jeśli coś pełni istotną rolę, to dla poprawienia dostępności całości element ten można zwielokrotnić. I tutaj właśnie rysuje się przewaga OpenBSD, a to z uwagi na dwie technologie CARP oraz pfsync.
CARP czyli Common Address Redundancy Protocol jest "lepszą" wersją VRRP. Pozwala na to, by grupa komputerów została zgrupowana pod jednym wirtualnym adresem IP. W efekcie można osiągnąć to, że postawione zostaną dwa routery/firewalle o adresach (na przykład) 192.168.0.2 i 192.168.0.3, które dzielić będą wspólny, wirtualny adres 192.168.0.1. W przypadku, gdy jedna maszyna ulegnie awarii, druga przejmie jej funkcje. Zastosowanie CARP jest oczywiście szersze, liczba maszyn dzielących wirtualny adres IP możę być większa, możliwe jest przydzielanie priorytetów do poszczególnych hostów, dzięki czemu osiaga się load balancing dla praktycznie dowolnej usługi sieciowej. Więcej o CARP przeczytać można choćby tutaj.
Drugą funkcją, o której wspominam to pfsync. Na co pozwala pfsync? W skrócie - na synchronizację tablicy stanów między dwoma firewallami. Po co to jest potrzebne? Wróćmy do poprzedniego przykładu. Załóżmy, że mam rzeczywiście te dwie maszyny o adresach 192.168.0.2 i 192.168.0.3. Maszyna 192.168.0.2 ma wyższy priorytet, więc ruch idzie właśnie przez nią. Pf jest oczywiście statefull, tak więc to właśnie ta maszyna ma informacje o wszystkich nawiązanych połączeniach i na podstawie tych informacji przepuszcza kolejne pakiety należące do określonych połączeń. Powiedzmy, że przy użyciu sporych rozmiarów młotka zabieram się za działania destrukcyjne względem maszyny 192.168.0.2. Ponieważ pewne doświadczenia w operowaniu wspomnianym młotkiem posiadam mogę zagwarantować, że maszyna zaatakowana w ten sposób nie bedzie po kilku chwilach nadawała się do jakiegokolwiek użytku. Dzięki CARP jej rolę przejmie w tym wypadku maszyna 192.168.0.3, której chwilowo młotkiem nie zaatakowałem. Jeśli maszyna ta nie będzie świadoma połączeń nawiązanych przez swoją zniszczoną przeze mnie toważyszkę, wszystkie istniejące połączenia będą musiały zostać zerwane i nawiązane ponownie. W wielu przypadkach jest to po prostu nieakceptowalne. Dzięki pfsync 192.168.0.3 wie jakie połączenia nawiązała 192.168.0.2 przed swoim nagłym końcem działania. Dzięki CARP i pfsync możliwe jest stworzenie redundantnego rozwiązania, które w przypadku CISCO czy Checkpoint trochę kosztuje... I nie jestem świadom jak podobną funkcjonalność osiągnąć w przypadku Linuks i iptables.
A o tym, jak połączyć te dwie funkcje w roli firewalla przeczytać można tutaj. Z przykładami.
