W tym artykule rozważymy proces organizacji i konfiguracji prostej bramy internetowej opartej na CentOS 7.x. Ta brama pozwoli użytkownikom z sieci lokalnej uzyskać dostęp do Internetu, a także dostęp do serwerów lub komputerów w sieci wewnętrznej z zewnątrz. Aby zorganizować routing i przekazywanie pakietów, użyjemy technologii NAT opartej na firewallu iptables. Zastanawiamy się również, jak utrzymywać i analizować dzienniki połączeń w bramie internetowej, gdy użytkownicy zewnętrzni uzyskują dostęp do sieci lokalnej.
Treść
- Schemat sieci lokalnej z bramą dostępu do Internetu, typy NAT
- Konfigurowanie źródłowego NAT: dostęp LAN
- Skonfiguruj docelowy NAT i przekierowanie portów: dostęp z Internetu do sieci lokalnej
- Analiza dzienników połączeń sieciowych NAT w systemie Linux
Schemat sieci lokalnej z bramą dostępu do Internetu, typy NAT
NAT (Tłumaczenie adresów sieciowych) - tłumaczenie adresów IP, jest to mechanizm, który pozwala zastąpić adresy źródłowy i docelowy w nagłówku IP pakietów, gdy przechodzą one przez router, tj. między różnymi sieciami.
Skonfigurujemy NAT między siecią wewnętrzną z adresowaniem 10.2.0.0/24 a zewnętrzną siecią internetową dwóch rodzajów:
- źródłowy NAT - w naszym przypadku jest to zamiana źródłowego adresu IP na zorganizowanie dostępu do Internetu za pośrednictwem jednego publicznego adresu IP kilku klientów.
- docelowy NAT - podstawienie docelowych adresów IP, w naszym przypadku, w celu zapewnienia dostępu z zewnętrznej sieci internetowej przez publiczny adres IP do wewnętrznych serwerów sieciowych.
Definiujemy elementy sieci (rysunek 1), między którymi będzie zorganizowany NAT:
- gw-server - brama serwera tj. nasz serwer CentOS Linux, który zapewnia dostęp poza siecią wewnętrzną. Ma dwa interfejsy, pierwszy eth1 (10.2.0.1) w sieci wewnętrznej, drugi eth0 (84.201.168.122) z publicznym adresem IP i dostępem do Internetu;
- web-server01 - Serwer sieci wewnętrznej, adres IP 10.2.0.11;
- my-server01 - serwer osobisty sieci wewnętrznej, adres IP 10.2.0.12.
Konfigurowanie źródłowego NAT: dostęp LAN
W przypadku źródłowego NAT dla zewnętrznych serwerów sieciowych żądania od naszych klientów z sieci wewnętrznej będą wyglądać, jakby serwer bramy komunikował się bezpośrednio z nimi - gw-server01.
W ostatnim artykule „Podstawowa konfiguracja zapory Linux przy użyciu iptables” omówiliśmy podstawy korzystania z iptables. Tym razem będziemy pracować w iptables nie tylko ze stołem filtruj, ale także ze stołem nat. W przeciwieństwie do tabel do filtrowania ruchu filtruj, Tabela nat zawiera następujące łańcuchy:
- WSTĘPNE - W tym łańcuchu przychodzące pakiety IP są przetwarzane, zanim zostaną podzielone na te przeznaczone dla samego serwera lub do transmisji na inny, tj. przed podjęciem decyzji o wyborze trasy dla pakietu IP;
- WYDAJNOŚĆ - Łańcuch przeznaczony jest do przetwarzania pakietów IP generowanych lokalnie przez aplikację na serwerze. Lokalnie generowane pakiety IP nie przechodzą przez łańcuch PREROUTING;
- POSTROUTOWANIE - wszystkie wychodzące pakiety IP są przetwarzane w tym łańcuchu, po podjęciu decyzji o trasie dla pakietu IP.
Działania wykonywane dla pakietów IP w tej tabeli są również różne:
- MASQUERADE i SNAT- zastępuje źródłowy adres IP pakietów wychodzących. Różnica między tymi działaniami polega na tym, że SNAT umożliwia ustawienie konkretnego adresu IP dla nowego źródła, aw przypadku MASQUERADE dzieje się to dynamicznie;
- DNAT - zastępuje docelowe adresy IP przychodzącymi pakietami.
Rysunek 2 pokazuje kroki przetwarzania pakietu IP z sieci wewnętrznej na bramie gw-server01 za pomocą SNAT na iptables. Adres IP i port docelowy pozostają niezmienione..
Rycina 2
- Pakiet IP przybył na wewnętrzny interfejs eth1 serwera gw-server01. Ponieważ docelowy adres IP nie należy do gw-server01, pakiet IP przechodzi do przetwarzania przez łańcuch FORWARD.
- Po przejściu łańcucha FORWARD dla pakietu IP określa się wychodzący interfejs sieciowy, z którego należy go wysłać, jest on oznaczony na żółto
- Na koniec pakiet IP przechodzi przez łańcuch POSTROUTING, w którym źródłowy adres IP jest zmieniany na adres IP zewnętrznego interfejsu eth0 serwera gw-server01
Przygotujmy się. Najpierw musisz ustawić parametr jądra, który umożliwia przesyłanie pakietów między interfejsami serwera. Aby to zrobić w pliku /etc/sysctl.conf dodaj zmienną:
net.ipv4.ip_forward = 1
Aby zastosować zmiany, wykonaj polecenie
sysctl -p /etc/sysctl.conf
tutaj sysctl to polecenie, które pozwala zarządzać parametrami jądra, kluczem -p oznacza, że musisz odczytać parametry z pliku.
Utwórz regułę w iptables, która pozwala na przesyłanie pakietów między interfejsem wewnętrznym (eth1) i zewnętrznym (eth0):
iptables -A DO PRZODU -i eth1 -o eth0 -j AKCEPTUJĘ
i przesyłajmy pakiety między interfejsami związanymi z już ustanowionymi połączeniami.
iptables -A DO PRZODU -m stan -state POWIĄZANE, USTALONE -j AKCEPTUJ
Sensowne jest utworzenie dwóch poprzednich reguł tylko wtedy, gdy zasada DROP jest domyślnie ustawiona dla łańcucha FORWARD:
iptables -P DROP DO PRZODU
Włącz SNAT:
iptables -t nat -A POSTROUTING -s 10.2.0.0/24 -o eth1 -j SNAT --to-source 84.201.168.122
- -do źródła musi być adresem interfejsu, z którego planowane jest wydawanie pakietów IP do sieci zewnętrznej;
- -s 10.2.0.0/24 określono, że sieć wewnętrzna to 10.2.0.0/24, ale jest to parametr opcjonalny, jeśli go nie określisz, nie będzie żadnych ograniczeń dotyczących źródła interakcji.
Zobaczmy wynikową konfigurację tabeli filtruj i łańcuchy Do przodu (wyjście jest przycięte):
iptables -L -n -v
i konfiguracja tabeli nat i łańcuchy POSTROUTOWANIE (wyjście jest przycięte):
iptables -t nat -L -n -v
Aby sprawdzić, czy nasz serwer internetowy w sieci wewnętrznej uzyskał dostęp do Internetu, spróbujemy połączyć się przez telnet z adresem 1.1.1.1 (Cloudflare DNS) port 80:
telnet 1.1.1.1 80
Wyniki zespołu Połączono 1.1.1.1, wskazuje, że połączenie powiodło się.
Skonfiguruj docelowy NAT i przekierowanie portów: dostęp z Internetu do sieci lokalnej
Teraz rozważ sytuację odwrotną. Chcemy, aby klienci z zewnątrz mieli dostęp do naszej witryny w sieci wewnętrznej. Musimy także przejść do twojego osobistego serwera (lub stacji roboczej) z Internetu. Różnica w tym przypadku polega nie tylko na kierunku interakcji, ale także na tym, że musisz przekierowywać żądania do poszczególnych portów, 80 (TCP) i 3389 (TCP), jednocześnie zastępując serwer docelowy i ewentualnie port docelowy. Ta technika nazywa się przekierowanie portów (przekierowanie portów).
Przekierowanie portów w systemie Windows można ustawić za pomocą polecenianetsh interface portproxy.Najpierw włącz transmisję pakietów z interfejsu zewnętrznego (eth0) do interfejsu wewnętrznego (eth1):
iptables -A DO PRZODU -i eth0 -o eth1 -j AKCEPTUJĘ
Ta reguła pozwala na przesyłanie pakietów IP między interfejsami niezależnie od źródła. Możliwe jest jednak zabronienie połączenia przez NAT dla oddzielnych adresów IP lub podsieci jako oddzielnej reguły:
iptables-I DO PRZODU 1 -o eth1 -s 167,71.67.136 -j DROP
Teraz przekieruj wszystkie połączenia do portu 80 zewnętrznego interfejsu sieciowego (eth0) na adres IP serwera WWW w sieci wewnętrznej web-server01:
iptables -t nat -A PREROUTING -p tcp --port 80 -i eth0 -j DNAT --to-destination 192.168.0.11
-do miejsca docelowego - musi być adresem IP, na który docelowy adres IP musi zostać zastąpiony.
Aby to sprawdzić, spróbuj połączyć się z Internetem przez telnet z publicznym adresem IP serwera gw-server na porcie 80:
telnet 84.201.168.122 80
Rezultatem będzie odpowiedź serwera WWW web-server01 z naszej sieci wewnętrznej:
HTTP / 1.1 400 Nieprawidłowe żądanie serwera: nginx / 1.14.2 Data: śr., 31 lipca 2019 10:21:21 GMT Typ zawartości: tekst / html Długość treści: 173 Połączenie: zamknij
Podobnie możesz skonfigurować dostęp z Internetu do swojej stacji roboczej za pośrednictwem RDP. Ponieważ ograniczona liczba osób będzie potrzebowała dostępu RDP, bezpieczniej będzie użyć niestandardowego portu, na przykład 13389, podczas łączenia i przekierować go do portu 3389 na wewnętrznym serwerze sieciowym (lub zmienić numer portu RDP na komputerze z systemem Windows). Zmieniony port docelowy jest oznaczony dwukropkiem po adresie IP:
iptables -t nat -A WSTĘPNE -p tcp --port 13389 -i eth0 -j DNAT - do miejsca docelowego 192.168.0.12 ∗ 389
Aby to sprawdzić, spróbuj połączyć się z Internetem przez telnet (lub polecenie cmdlet PowerShell Test-NetConnection) z publicznym adresem IP serwera gw-server na porcie 13389:
telnet 84.201.168.122 13389
W odpowiedzi otrzymujemy pusty ekran i kursor, co oznacza, że połączenie działa.
Analiza dzienników połączeń sieciowych NAT w systemie Linux
Jednym z momentów zwiększenia poziomu bezpieczeństwa po skonfigurowaniu przekierowania portów do naszego osobistego serwera z sieci zewnętrznej będzie montaż i analiza dzienników połączeń zewnętrznych. Rzeczywiście, oprócz nas, atakujący może próbować skorzystać z tego dostępu.
Najpierw włącz wpis w pliku dziennika /var/ log / messages wszystkie próby połączenia z niestandardowym portem RDP, którego używamy:
iptables -I WEJŚCIE 1 -p tcp --port 13389 -m stan - stan NOWY -j LOG - prefiks dziennika „NOWA SESJA RDP”
Połącz się z naszym osobistym serwerem, aby dziennik pojawił się w dzienniku. Teraz odfiltrowujemy wszystkie potrzebne wpisy w pliku dziennika:
cat / var / log / messages | grep „NOWA SESJA PROW”
jądro: NOWA SESJA RDP IN = OUT = eth1 SRC = 167,71.67.79 DST = 84.201.168.122 LEN = 60 TOS = 0x00 PREC = 0x00 TTL = 64 ID = 16270 DF PROTO = TCP SPT = 60836 DPT = 13389 WINDOW = 29200 RES = 0x00 SYN URGP = 0
Czytanie takiego dziennika nie jest zbyt wygodne, zwłaszcza każdego dnia. Dlatego kolejnym krokiem jest zautomatyzowanie analizy dzienników, aby regularnie otrzymywać raporty w oparciu o nasz filtr. Aby to zrobić, użyj narzędzia Zegarek, instalowanie go za pomocą standardowego menedżera pakietów yum:
mniam zainstalować logwatch
Najpierw spróbuj wygenerować raport ręcznie:
/ usr / sbin / logwatch --detail low --service iptables - już dziś
tutaj,
- -usługa - ustawia określoną usługę, wiadomości, z których należy analizować, w naszym przypadku, tylko z iptables;
- -zasięg - wskazuje okres próbkowania danych, dziś - wszystkie zdarzenia na dziś;
- -szczegóły - poziom szczegółowości raportu (wysoki, średni, niski).
Domyślnie logwatch wyświetli raport na ekranie, otrzymujemy coś takiego:
--------------------- Zapora iptables Rozpocznij ------------------------ Wymienione przez hosty źródłowe: Zalogowano 2 pakiety w interfejsie eth1 Od 167.71.45.65 - 2 pakiety do TCP (13389) ---------------------- Zapora sieciowa iptables Koniec -------------------------
Raport działa, pozostaje go uruchomić zgodnie z harmonogramem, raz dziennie i wysłać go na e-mail, w tym celu aktualizujemy polecenie i zapisujemy go w pliku /etc/cron.daily/00logwatch:
/ usr / sbin / logwatch - poczta wyjściowa --mailto [email protected] - szczegóły niski - usługa iptables - wczoraj
Tutaj dodano opcje:
-wyjście - wskazuje metodę generowania raportu, poczta - wyślij na pocztę;
-mailto - adres e-mail odbiorcy raportu.
Przesyłając protokół RDP w sieci lokalnej, musisz także móc analizować dzienniki połączeń RDP bezpośrednio w systemie Windows.
