Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



20.07.2020

Baramundi

Pomoc w czasie pandemii.
20.07.2020

Stop infekcjom

CloudGuard
17.07.2020

Analiza zagrożeń

Kaspersky Threat Attribution Engine
17.07.2020

Strażnik danych

QGD-1602P
16.07.2020

Dysk przemysłowy

Transcend MTE352T
16.07.2020

Połączenie sił

Fugaku
16.07.2020

Brama bezpieczeństwa

Check Point 1570R
23.06.2020

PLNOG Online

PLNOG Online
23.06.2020

Nowe zagrożenie

Ramsay

Szyfrowanie transmisji pomiędzy klientem a serwerem

Data publikacji: 26-06-2018 Autor: Tomasz Bielas
RYS. 1. PRZYKŁAD UŻYCIA IPSEC...

Na rynku dostępne są różne technologie pozwalające na szyfrowanie ruchu pomiędzy hostami czy lokalizacjami. Są to rozwiązania softwarowe VPN działające w modelu klient-serwer lub gotowe transparentne urządzenia szyfrujące ruch pomiędzy urządzeniami sieciowymi, komputerami klienckimi i serwerami. W artykule opisujemy proste, darmowe rozwiązanie IPSec.

W  momencie gdy szukamy elastycznego rozwiązania, które będzie oferować dobre możliwości automatyzacji, szybko dochodzimy do problemu skali oraz kosztu utrzymania całego rozwiązania. Omawiane darmowe rozwiązanie IPSec dla dystrybucji Red Hat Enterprise Linux 7 udostępniane jest w postaci pakietów .rpm w repozytorium EPEL. Natomiast po stronie systemu Windows użyjemy wbudowanego klienta IPSec, konfigurowanego przez regułę zabezpieczeń zapory systemowej.

 
Po stronie Linuksa używane będzie oprogramowania strongswan, ponieważ libreswan, na którego firma Red Hat zdecydowała się w siódmej wersji dystrybucji, to naszym zdaniem produkt niedopracowany, niekompletny i posiadający kiepską dokumentację. Dla wygody w omawianym przykładzie szyfrowane połączenie zostanie zestawione w trybie transport mode, które jest całkowicie transparentne dla użytkownika. Z kolei stacja kliencka do połączeń z serwerem Linux będzie używać swojego certyfikatu. Certyfikat serwera został podpisany za pomocą tego samego CA. Wszystko, co trzeba zrobić, to wygenerować certyfikat dla hosta Linux, a po stronie Windows dodać odpowiednią regułę firewall. Zakładamy, że komputer z Windows znajduje się w domenie AD, gdyż wtedy automatycznie będzie on posiadał certyfikat hosta, którym może się autoryzować, przesyłając dane w stronę serwera Linux.
 
Tak jak wcześniej wspomniano, host kliencki i serwer muszą mieć zainstalowane certyfikaty podpisane tym samym CA (zazwyczaj tak jest, jeżeli stacje/serwery pracują w jednej organizacji, w przeciwnym wypadku należy to zrobić samodzielnie, aby zautomatyzować cały proces).
 
> KRÓTKO O IPSEC
 
Internet Protocol Security nie jest pojedynczym protokołem – w naszym rozumieniu to oprogramowanie działające na hostach, będące zbiorem serwisów oraz protokołów, które posłużą do bezpiecznej transmisji i szyfrowania ruchu pomiędzy różnymi końcówkami. 
 
IPSec używa dwóch protokołów do zabezpieczania transmisji – Authentication Header (AH) oraz Encapsulating Security Payload (ESP). AH/ESP można uznać za swojego rodzaju nagłówki wspomagające. Na rys. 1 pokazano przykład użycia IPSec w trybie transport mode (stan, do którego będziemy dążyć w omawianym przypadku).
 
Zdecydowaną zaletą IPSec jest to, że chroni dane przesyłane za pomocą protokołu IP. Jako że działamy na tak niskim poziomie, oznacza to, że zabezpieczamy bardzo dużo informacji. Wadą IPSec może być fakt, że poprawnie będzie on działał tylko wtedy, gdy wszystkie urządzenia biorące udział w transmisji będą obsługiwać ten protokół. 
 
Dlatego aby zapewnić poprawną i pełną implementację IPSec w naszej organizacji, musimy upewnić się, że wszystkie urządzenia po drodze będą zezwalały na ruch na portach 500/UDP, 4500/UDP oraz wcześniej już wspomnianych protokołach 50/ESP oraz 51/AH. Należy również pamiętać, że zestawienie tunelu pomiędzy hostami omija segmentację sieci. Mówiąc wprost – zapory ogniowe, które są po drodze i zezwalają nam na ruch IPSec są ślepe na to, co jest enkapsulowane w tym ruchu. W urządzeniach klasy enterprise istnieje możliwość wykrywania w takim ruchu pewnych anomalii na podstawie wyuczonych wzorców, niestety nie wszystkie tego typu rozwiązania są wystarczająco skuteczne. Nie bez powodu tunelowanie jest często stosowane w celu ominięcia zabezpieczeń sieci. Dla przykładu na rys. 2 pokazano podgląd ruchu na hoście (użyto tcpdump na hoście w trakcie pracy IPSec). Analiza ruchu na urządzeniach sieciowych biorących udział w transmisji będzie wyglądać bardzo podobnie.
 
Na koniec MTU (Maximum Transmission Unit) – należy pamiętać, że IPSec powoduje pewien narzut i zwiększa tę wartość. Jeśli polityka w danej firmie jest dość restrykcyjna i nie zezwala na większe niż założone wartości MTU, może generować to różne problemy – najczęściej będą to losowe rozłączenia w trakcie pracy tunelu.
 
> IMPLEMENTACJA
 
Zaczynamy od instalacji z EPEL oprogramowania strongswan w systemie Linux (rys. 3). Plusem jest to, że wszystko, czego będziemy potrzebować, strongswan ma już w sobie – nie ma potrzeby instalowania żadnych dodatkowych narzędzi po stronie hosta Linux. Oprogramowanie to zajmuje też niewiele zasobów. Oczywiście istnieją inne pakiety do implementacji IPSec, lecz strongswan oferuje nie tylko dużą funkcjonalność, ale i jest jednym z najlepiej opisanych w sieci rozwiązań, a dokumentacja tego oprogramowania jest cały czas aktualizowana. Próba uruchomienia libreswan w zakładanej konfiguracji host-to-host, w trybie transport mode na certyfikatach z tego samego urzędu CA zakończyła się niepowodzeniem.
 
[...]
 
Certyfikowany administrator Linuksa. Pracuje jako administrator systemowy RHEL dużego, rozproszonego środowiska IT, gdzie zajmuje się zagadnieniami dot. automatyzacji crossplatformowych procesów oraz technologii w dynamicznym środowisku IT. Entuzjasta open source od czasów Slackware 7.0

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"