Następna strona Poprzednia strona Spis treści

11. Porady w projektowaniu filtra pakietów

W dziedzinie bezpieczeństwa komputerowego zwykle za powszechną mądrość uważa się blokowanie wszystkiego a dopiero potem otwieraniu odpowiednich portów w miarę jak stają sie potrzebne. Mówi się o tym zwykle 'to co nie jest wyraźnie dozwolone, jest zabronione'. Zalecam to podejście, jeśli bezpieczeństwo jest twoim największym priorytetem.

Nie uruchamiaj żadnych usług których nie musisz mieć, nawet jeśli wydaje ci się że zablokowałeś do nich dostęp.

Jeśli budujesz dedykowaną ścianę ogniową, rozpocznij od zera z blokowaniem wszystkich pakietów, potem dodawaj usługi i reguły które pozwolą im działać.

Zalecam również bezpieczeństwo 'warstwowe': połącz tcp-wrappers (dla połączeń do filtra pakietów), proxy (dla połączeń przechodzących przez filtr pakietów), weryfikację drogi (ang. route verification) i filtrowanie pakietów. Weryfikacja drogi ma miejsce wtedy, gdy pakiet dociera z niewłaściwego interfejsu i jest odrzucany: na przykład, twoja sieć wewnętrzna ma adresy 10.1.1.0/24, a pakiet z takim adresem dociera do filtra pakietów przez interfejs zewnętrzny - powinien zostać odrzucony. Może to zostać włączone dla jednego interfejsu (ppp0) tak jak niżej:

# echo 1 > /proc/sys/net/ipv4/conf/ppp0/rp_filter
#

Lub dla wszystkich istniejących i przyszłych interfejsów tak jak niżej:

# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
#     echo 1 > $f
# done
#

Debian robi to domyślnie jeśli jest to możliwe. Jeśli masz routing asymetryczny (tzn. spodziewasz się pakietów nadchodzących z dziwnych kierunków), będziesz prawdopodobnie musiał wyłączyć takie filtrowanie na tych interfejsach.

Logowanie jest użyteczne w trakcie konfigurowania ściany ogniowej, gdy coś nie działa, ale na działającej ścianie ogniowej zawsze połącz logowanie z opcją 'limit', by zapobiec zapełnieniu twoich logów.

Zalecam również śledzenie połączeń dla systemów w których bezpieczeństwo jest sprawą priorytetową: wprowadza pewne opóźnienia, ponieważ śledzone są wszystkie połączenia, ale jest to bardzo przydatne w kontrolowaniu dostępu do twoich sieci. Być może będziesz musiał załadować moduł 'ip_conntrack.o' jeśli twój kernel nie ładuje modułów automatycznie albo jeśli nie jest on już wbudowany w kernel. Jeśli chcesz śledzić dokładnie skomplikowane protokoły, musisz załadować odpowiedni moduł wspomagający (np. 'ip_conntrack_ftp.o').

# iptables -N no-conns-from-ppp0
# iptables -A no-conns-from-ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A no-conns-from-ppp0 -m state --state NEW -i ! ppp0 -j ACCEPT
# iptables -A no-conns-from-ppp0 -i ppp0 -m limit -j LOG --log-prefix "Bad packet from ppp0:"
# iptables -A no-conns-from-ppp0 -i ! ppp0 -m limit -j LOG --log-prefix "Bad packet not from ppp0:"
# iptables -A no-conns-from-ppp0 -j DROP

# iptables -A INPUT -j no-conns-from-ppp0
# iptables -A FORWARD -j no-conns-from-ppp0

Budowanie dobrej ściany ogniowej jest poza tematem tego HOWTO, ale moją radą jest 'bądź minimalistą'. Zajrzyj do Security HOWTO po więcej informacji o testowaniu i sprawdzaniu twojej maszyny.


Następna strona Poprzednia strona Spis treści