Jak skonfigurować zaporę w systemie w sieci LAN, aby niektóre porty były otwarte tylko na połączenia z sieci lokalnej, a nie ze świata zewnętrznego?
Na przykład mam skrzynkę z systemem naukowym Linux 6.1 (dystrybucja oparta na RHEL) i chcę, aby jego serwer SSH akceptował tylko połączenia z hosta lokalnego lub sieci LAN. Jak mam to zrobic?
Odpowiedzi:
Gdy iptables jądra są całkowicie puste ( iptables -F), zrobi to o co prosisz:
# iptables -A INPUT -p tcp --dport 22 -s 192.168.0.0/24 -j ACCEPT
# iptables -A INPUT -p tcp --dport 22 -s 127.0.0.0/8 -j ACCEPT
# iptables -A INPUT -p tcp --dport 22 -j DROP
Mówi to, że wszystkie adresy LAN mogą komunikować się z portem TCP 22, że host lokalny dostaje to samo (tak, 127. * nie tylko 127.0.0.1), a pakiety z każdego innego adresu niezgodnego z tymi dwiema pierwszymi regułami są bezceremonialnie upuszczane na łyżka do bitów . Możesz użyć REJECTzamiast, DROPjeśli chcesz aktywnego odrzucenia (TCP RST) zamiast uczynić port TCP 22 czarną dziurą dla pakietów.
Jeśli Twoja sieć LAN nie korzysta z bloku 192.168.0. *, Naturalnie będziesz musiał zmienić adres IP i maskę w pierwszym wierszu, aby dopasować schemat IP swojej sieci LAN.
Te polecenia mogą nie działać tak, jak chcesz, jeśli w zaporze są już skonfigurowane niektóre reguły. (Powiedz iptables -Ljako root, aby się dowiedzieć.) Często zdarza się, że jedna z istniejących reguł pobiera pakiety, które próbujesz filtrować, więc dołączanie nowych reguł nie ma żadnego efektu. Chociaż można używać -Izamiast -Az iptablespolecenia splatać nowe zasady w środku łańcucha, zamiast ich dołączania, to zwykle lepiej, aby dowiedzieć się, jak łańcuchy uzyskać zaludnionych przy starcie systemu i zmodyfikować ten proces dzięki czemu nowe zasady zawsze instalowane w poprawna kolejność.
W najnowszych systemach typu RHEL najlepszym sposobem na to jest użycie firewall-cmdlub jego odpowiednika GUI. To mówi firewallddemonowi systemu, czego chcesz, czyli co faktycznie zapełnia i manipuluje tym, co widzisz iptables -L.
W starszych systemach typu RHEL najłatwiejszym sposobem modyfikacji łańcuchów zapory podczas zamawiania spraw jest edycja /etc/sysconfig/iptables. GUI i narzędzia zapory TUI systemu operacyjnego są dość uproszczone, więc kiedy zaczniesz dodawać bardziej złożone reguły, takie jak to, lepiej wrócić do starych dobrych plików konfiguracyjnych. Uwaga: gdy zaczniesz to robić, ryzykujesz utratą zmian, jeśli kiedykolwiek użyjesz narzędzi zapory systemu operacyjnego do zmodyfikowania konfiguracji, ponieważ może nie wiedzieć, jak radzić sobie z takimi ręcznie stworzonymi regułami.
Dodaj coś takiego do tego pliku:
-A RH-Firewall-1-INPUT -p tcp --dport 22 -s 192.168.0.0/24 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --dport 22 -s 127.0.0.0/8 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --dport 22 -j DROP
To, co dodajesz, jest podchwytliwe. Jeśli znajdziesz w tym pliku linię, o której mówi --dport 22, po prostu zastąp ją trzema liniami powyżej. W przeciwnym razie prawdopodobnie powinien przejść przed pierwszą istniejącą linią kończącą się na -j ACCEPT. Ogólnie rzecz biorąc, musisz zapoznać się ze sposobem działania iptables , w którym momencie prawidłowy punkt wstawienia będzie oczywisty.
Zapisz ten plik, a następnie powiedz, service iptables restartaby ponownie załadować reguły zapory. Pamiętaj, aby to zrobić, gdy jesteś zalogowany do konsoli, na wypadek, gdybyś podrobił zmiany! Nie chcesz blokować się na komputerze, gdy jesteś zalogowany przez SSH.
Podobieństwo do powyższych poleceń nie jest przypadkowe. Większość tego pliku składa się z argumentów iptablespolecenia. Różnice w stosunku do powyższego polegają na tym, że iptablespolecenie jest odrzucane, a INPUTnazwa łańcucha staje się specjalnym RH-Firewall-1-INPUTłańcuchem specyficznym dla RHEL . (Jeśli chcesz zbadać plik bardziej szczegółowo, zobaczysz wcześniej w pliku, w którym zasadniczo zmieniono nazwę INPUTłańcucha. Dlaczego? Nie mogę powiedzieć.)
Niskopoziomowym narzędziem do konfiguracji zapory ogniowej w systemie Linux jest iptables . Dostępne są również narzędzia wyższego poziomu. Nie wiem, czy Scientific Linux ma zalecane narzędzie firewall.
Zgodnie z tą stroną internetową (nie sprawdziłem, czy dotyczy to 6.1), service iptables savezapisze bieżące reguły zapory, a te zapisane reguły są ładowane podczas uruchamiania. Musisz więc skonfigurować reguły za pomocą iptablespoleceń (lub w jakikolwiek inny sposób), a następnie uruchomić, service iptables saveaby konfiguracja była trwała.
Wpis na blogu Scotta Pack to początek upuszczania pakietów „nieparzystych”, które zwykle nie są potrzebne i wiążą się z dużym ryzykiem bycia częścią ataku. Poza tym będziesz chciał zamknąć wszystkie przychodzące porty i otworzyć tylko te, których potrzebujesz. Coś takiego:
# Accept everything on the loopback interface
iptables -A INPUT -i lo -j ACCEPT
# Accept ICMP
iptables -A INPUT -p icmp --icmp-type any -j ACCEPT
# Drop oddball packets
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
iptables -A INPUT -f -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
# Accept packets that are part of established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Accept selected incoming connections, e.g. ssh from 10.0.42.x
iptables -A INPUT -p tcp --dport 22 -s 10.0.42.0/24 -j ACCEPT
# Reject incoming connections that aren't explicitly accepted
iptables -A INPUT -j REJECT
Preferowanym sposobem na to jest iptables. Wygląda na to, że zostało to w wystarczającym stopniu uwzględnione przez innych, więc dla kompletności wskazam alternatywną metodę kontroli dostępu, która jest dostępna dla wielu demonów w większości dystrybucji Linuksa. Tę metodę kontroli dostępu zapewnia libwrapbiblioteka.
Aby sprawdzić, czy Twój ulubiony demon libwrapobsługuje, spróbuj wykonać następujące czynności:
ldd `which sshd` | grep libwrap
Jeśli otrzymasz niepuste wyniki, takie jak
libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f84e7b0e000)
to zdecydowanie jesteś gotowy.
Jest prawie pewne, że twój sshddemon ma libwrapwsparcie, dlatego powinien skonsultować się z plikami /etc/hosts.allowi /etc/hosts.deny, aby uzyskać kontrolę dostępu. Zakładając, że twoja lokalna sieć LAN jest 192.168.100.0/24, możesz odmówić dostępu do sshdwszystkich klientów oprócz klientów na lokalnym hoście lub w lokalnej sieci LAN, umieszczając w /etc/hosts.denypliku:
sshd: ALL EXCEPT 127.0.0.0/255.0.0.0, [::1]/128, 192.168.100.0/255.255.255.0
Zauważ, że ta metoda nie otwiera ani nie zamyka portów jako takich. Po prostu informuje demony korzystające z tej metody kontroli dostępu, czy przyjmować, czy odrzucać próby połączenia od klientów pasujących do podanych wzorców.
Aby uzyskać szczegółowe informacje, sprawdź strony podręcznika, zaczynając od hosts_access(5).
Jeśli masz własną zaporę ogniową opartą na systemie Linux, najlepiej skonfigurować ją iptables, jak to opisują inni. Jeśli nie, a zapora jest twoim routerem, najprawdopodobniej domyślna konfiguracja już uniemożliwia dostęp z zewnątrz, chyba że wyraźnie zezwolisz na przekierowanie portów (jak niedawno opisałem w odpowiedzi na to pytanie ).
Aby uzyskać dodatkowe bezpieczeństwo powyżej, możesz użyć oddzielnej podsieci dla połączeń w sieci LAN. Aby to zrobić, dla każdego komputera dodaj drugi adres IP, który będzie używany tylko w sieci LAN, a nie przez router. Załóżmy, że cała sieć LAN używa teraz 192.168.0.xxxadresów, a router (brama, zapora ogniowa) 192.168.0.1. Dodaj więc drugi adres dla każdego komputera - na przykład:
ifconfig eth0:0 192.168.5.1/24
Następnie edytuj sshdkonfigurację, aby używać tylko tego adresu (aby nie pozwalał na nawiązywanie połączeń 192.168.0.xxx) - edytuj /etc/ssh/sshd_configi modyfikuj ListenAddressw jednej z nowych podsieci ( 192.168.5.1w powyższym przykładzie). Otóż to! Jeśli brama nie zostanie skonfigurowana do kierowania komunikacją w tej podsieci, należy ją oddzielić od zewnętrznej strony.