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.