11.11.2012
Pod powodzią oznacza ogromny przepływ danych w postaci wiadomości, które są wysyłane do publikowania na wszelkiego rodzaju forach i czatach. Z technicznego punktu widzenia powódź jest jednym z najczęstszych rodzaje ataków komputerowych, a jego celem jest wysłanie takiej liczby żądań, że sprzęt serwera będzie zmuszony wykonać odmowa usługi usługi dla użytkowników. Jeśli atak komputerowy przeprowadzone z duża liczba komputery, to masz do czynienia z .
Istnieje kilka rodzajów ataków DDoS flooding, główne z nich wymieniono poniżej:
- Powódź SYN-ACK
- Powódź HTTP
- Powódź ICMP
- Powódź UDP
Powódź SYN-ACK
Powódź SYN-ACK- jeden z typów ataki sieciowe, który polega na wysyłaniu ogromnej liczby żądań SYN na jednostkę czasu. Efektem będzie wyłączenie usługi, której działanie zostało oparte na protokole TCP. Najpierw klient wysyła do serwera pakiet zawierający flagę SYN, której obecność wskazuje, że klient chce nawiązać połączenie. Serwer z kolei wysyła pakiet odpowiedzi. Oprócz flagi SYN zawiera również flagę ACK, która zwraca uwagę klienta na to, że żądanie zostało zaakceptowane i oczekuje się potwierdzenia połączenia od klienta. Odpowiada pakietem z flagą ACK o udanym połączeniu. Serwer przechowuje wszystkie żądania „połączenia” od klientów w kolejce o określonym rozmiarze. Żądania są umieszczane w kolejce do momentu zwrócenia flagi ACK od klienta. Atak SYN polega na wysyłaniu do serwera pakietów z nieistniejącego źródła w ilości przekraczającej rozmiar kolejki. Serwer po prostu nie będzie w stanie odpowiedzieć na pakiet pod fikcyjnym adresem. Kolejka nie zmniejszy się, a usługa przestanie działać.
Powódź HTTP
Powódź HTTP- dotyczy, gdy usługa współpracuje z Baza danych. Atak jest wycelowany albo w serwer internetowy lub do skryptu współpracującego z bazą danych. Ogromna liczba żądań GET jest wysyłana do portu 80, więc serwer sieciowy nie może zwracać należytej uwagi na żądania innego typu. Pliki dziennika rosną, a praca z bazą danych staje się niemożliwa.
Powódź ICMP
Powódź ICMP- łatwy sposób redukcja przepustowości oraz wzrost obciążenia na stosie poprzez wysyłanie podobnych żądań ICMP PING. Niebezpieczne, jeśli niewiele uwagi poświęca się zaporom ogniowym, ponieważ serwer, który odpowiada na niekończące się żądania ECHO, jest skazany na zagładę. Więc w przypadku takiej samej ilości ruchu przychodzącego i wychodzącego wystarczy wpisać zasady w iptables.
Powódź UDP
Powódź UDP- Inny sposób bałagan w przepustowości, który opiera się na pracy z protokołem niewymagającym synchronizacji przed wysłaniem danych. Atak sprowadza się do zwykłego wysłania pakietu na port UDP serwera. Po otrzymaniu pakietu serwer zaczyna go intensywnie przetwarzać. Następnie klient wysyła jeden po drugim zniekształcone pakiety Udp. W rezultacie porty przestaną działać, a system ulegnie awarii.
Zasadniczo definicja rodzaj ataku DDoS często nie trzeba spędzać dużo czasu. Wystarczy znać kilka znaków. Jeśli znacznie zwiększył rozmiar plików dziennika- Masz do czynienia z Powódź HTTP. Jeśli ograniczony dostęp do usługi w wyniku przekroczenia liczby dozwolonych połączeń jest Powódź SYN-ACK. Jeśli wychodzące i ruch przychodzący w przybliżeniu równa- Masz do czynienia z Powódź ICMP. Najważniejsze, żeby nie zapomnieć o utrzymaniu bezpieczeństwo twojego serwera przed atakami DDoS i zwróć na to należytą uwagę. Najlepiej o to zadbać
DoS (skrót Denial of Service „odmowa usługi”) - atak hakerski na system obliczeniowy w celu doprowadzenia go do awarii, czyli stworzenia takich warunków, w których sumienni użytkownicy systemu nie mogą uzyskać dostępu do udostępnionych zasobów systemowych (serwerów) lub dostęp ten będzie utrudniony.
Istnieją dwa rodzaje ataków DoS/DDoS, a najczęstszy opiera się na idei floodingu, czyli zalania ofiary ogromną liczbą pakietów. Flood może być różne: ICMP flood, SYN flood, UDP flood i HTTP flood. Współczesne boty DoS potrafią stosować wszystkie tego typu ataki jednocześnie, dlatego warto wcześniej zadbać o odpowiednią ochronę przed każdym z nich.
Wykrywanie ataków DoS
SYN powodzi
Obecność powodzi SYN można łatwo ustalić - licząc liczbę „półotwartych” połączeń TCP. W normalnej sytuacji nie powinno ich być wcale (lub bardzo mała ilość: maksymalnie 1-3).
Ochrona przed atakami DoS
Fragmenty bloków - pakiety. Ponieważ ze względu na funkcjonalne przeznaczenie protokołu pakiety ICMP muszą być bardzo małe i normalnie mieścić się w MTU, obecność ich fragmentów zwykle wskazuje na błąd lub próbę ataku. iptables -A WEJŚCIE -p icmp -f -j DROP
Zapobiegaj podszywaniu się w Twoim imieniu. iptables -A INPUT -m conntrack --ctstate NOWE, NIEPRAWIDŁOWE -p tcp --tcp-flags SYN,ACK SYN,ACK -j LOG --informacje o poziomie dziennika --log-prefix "DROP SYN,ACK:" iptables - A INPUT -m conntrack --ctstate NOWE, NIEPRAWIDŁOWE -p tcp --tcp-flags SYN,ACK SYN,ACK -j REJECT --reject-with tcp-reset
W końcu jeśli otrzymamy pakiet z ustawionymi flagami SYN i ACK (tylko odpowiedź na pakiet SYN ma taką kombinację flag) na połączeniu, które nie jest jeszcze otwarte, oznacza to, że ktoś wysłał pakiet SYN do innego hosta w naszym imieniu, a odpowiedź przyszła do nas. Oczywiście napastnik i tak będzie musiał odgadnąć numer kolejny, ale lepiej nie dawać mu takiej szansy. Zgodnie z powyższą zasadą nasz host odpowie pakietem RST, po odebraniu którego atakowany host zakończy połączenie. Dodanie takiej reguły do konfiguracji zapory jest wysoce zalecane, ponieważ jeśli atakującemu uda się sfałszować w Twoim imieniu, ślad zaprowadzi Cię do Ciebie podczas badania tego odcinka.
SYN powodzi
Jeden z powszechnych sposobów nie tylko blokowania kanału komunikacji, ale także wejścia stos sieciowy system operacyjny do stanu, w którym nie może już akceptować nowych żądań połączeń. Na podstawie próby zainicjowania dużej liczby jednoczesnych połączeń TCP przez wysłanie pakietu SYN z nieistniejącym adresem zwrotnym. Po kilku próbach wysłania pakietu odpowiedzi ACK na nieosiągalny adres większość systemów operacyjnych kolejkuje nieustanowione połączenie. I dopiero po n-tej próbie połączenie zostaje zamknięte. Ponieważ przepływ pakietów ACK jest bardzo duży, wkrótce kolejka staje się pełna, a jądro odmawia próby otwarcia nowego połączenia. Najmądrzejsze boty DoS analizują również system przed rozpoczęciem ataku, aby wysyłać żądania tylko do otwarcia ważnych portów. Identyfikacja takiego ataku jest prosta: wystarczy spróbować połączyć się z jedną z usług. Środki obronne zazwyczaj obejmują:
Zwiększ kolejkę „półotwartych” połączeń TCP:
# sysctl -w net.ipv4.tcp_max_syn_backlog=1024Zmniejszenie czasu retencji połączeń „półotwartych”:
# sysctl -w net.ipv4.tcp_synack_retries=1Włączenie mechanizmu syncookies TCP:
# sysctl -w net.ipv4.tcp_syncookies=1Powódź UDP
Metoda bałaganu pasma. Oparta na niekończącym się wysyłaniu pakietów UDP do portów różnych usług UDP. Łatwo eliminowane poprzez odcięcie takich usług od świata zewnętrznego i ustalenie limitu liczby połączeń na jednostkę czasu.
#Ustaw limit 5 połączeń na porcie 80. iptables -A WEJŚCIE -p tcp --syn --dport 80 -m connlimit --connlimit-above 5 -j ODRZUĆ # Zezwalaj tylko na jedno współbieżne połączenie z jednego adresu IP do smtp iptables -A DO PRZODU -p tcp --syn --dport smtp -m connlimit --connlimit-above 1 -j DROP # Ustaw limit 200 połączeń na porcie 1720. iptables -A WEJŚCIE -p tcp --syn --dport 1720 -m connlimit --connlimit-above 200 -j REJECT # udp 5060 $IPT -A INPUT -p udp --dport 5060 -m connlimit --connlimit-above 60 -j DZIENNIK --informacje o poziomie dziennika --log-prefix "REJECT 5060:" $IPT -A INPUT -p udp --dport 5060 -m connlimit --connlimit-above 60 -j ODRZUCENIE # tcp 1720 $IPT -A WEJŚCIE -p tcp --syn --dport 1720 -m connlimit --connlimit-above 60 -j DZIENNIK --log-level info --log-prefix "REJECT 1720:" $IPT -A INPUT -p tcp --syn --dport 1720 -m connlimit --connlimit-above 60 -j ODRZUCENIE
Powódź ICMP
Bardzo prymitywną metodą ograniczania przepustowości i tworzenia obciążeń na stosie sieciowym poprzez monotonne wysyłanie żądań ICMP jest protokół diagnostyczny przeciążenia sieci ECHO (ping). Łatwo wykrywalne poprzez analizę przepływów ruchu w obu kierunkach: podczas ataku powodziowego ICMP są one prawie identyczne. Niemal bezbolesny sposób absolutnej ochrony polega na wyłączeniu odpowiedzi na żądania ICMP ECHO:
sysctl net.ipv4.icmp_echo_ignore_all=1
Lub z zaporą:
Iptables -A INPUT -p icmp -j DROP --icmp-type 8
Powódź HTTP
Liczba procesów ps aux | grep apache | wc-l
Liczba połączeń na porcie 80 netstat -na | grep ":80" | wc-l
Zobacz listę Adresy IP z którego wysyłane są żądania połączenia: netstat -na | grep ":80" | sortuj | uniq -c | sort-nr
sysctl
Ochrona przed fałszowaniem net.ipv4.conf.default.rp_filter = 1
Sprawdzaj połączenie TCP co minutę. Jeśli po drugiej stronie znajduje się legalny samochód, natychmiast zareaguje. Wartość domyślna to 2 godziny. net.ipv4.tcp_keepalive_time = 60
Spróbuj ponownie za dziesięć sekund net.ipv4.tcp_keepalive_intvl = 10
Liczba sprawdzeń przed zamknięciem połączenia net.ipv4.tcp_keepalive_probes = 5
Debian: Walka z DDoS
Domyślnie system Debian i inne systemy operacyjne nie są w stanie obsługiwać ogromnej liczby połączeń tworzonych przez botnet. Należy wprowadzić zmiany w konfiguracji jądra, aby wzmocnić stos TCP/IP. Przykład takiej konfiguracji:
net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.eth0.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.core.rmem_max = 996777216 net.core.wmem_max = 996777216 net.ipv4 .tcp_rmem = 4096 87380 4194304 net.ipv4.tcp_mem= 786432 1048576 996777216 net.ipv4.tcp_wmem = 4096 87380 4194304 net.ipv4.tcp_max_orphans = 2255360 net.core.netdev_max_pvtcfin.4.ptime netto. = 15 net.ipv4.tcp_max_syn_backlog = 2048 net.ipv4.tcp_synack_retries = 1 kernel.msgmnb = 65536 kernel.msgmax = 65536 kernel.shmmax = 494967295 kernel.shmall = 268435456 net.core.somaxconn= 16096
Ostrożnie zmień konfigurację jądra i zrestartuj serwer...
FreeBSD: walka z DDoS
Skracamy czas oczekiwania na pakiet odpowiedzi na żądanie SYN-ACK (zabezpieczenie przed SYN flood):
# sysctl net.inet.tcp.msl=7500Zamieniamy serwer w czarną dziurę. Czyli jądro nie wyśle pakietów odpowiedzi podczas próby połączenia się z niezajętymi portami (zmniejsza obciążenie maszyny podczas DDoS "ale na losowych portach):
# sysctl net.inet.tcp.blackhole=2 # sysctl net.inet.udp.blackhole=1Ograniczamy liczbę odpowiedzi na wiadomości ICMP do 50 na sekundę (zabezpieczenie przed zalaniem ICMP):
# sysctl net.inet.icmp.icmplim=50Zwiększamy maksymalna ilość połączenia z serwerem (ochrona przed wszystkimi typami DDoS):
# sysctl kern.ipc.somaxconn=32768Włączamy DEVICE_POLLING - samoodpytywanie sterownika sieciowego przez jądro przy dużych obciążeniach (znacznie zmniejsza obciążenie systemu podczas DDoS "a):
Odbuduj jądro z opcją "options DEVICE_POLLING"; Aktywuj mechanizm odpytywania: "sysctl kern.polling.enable=1"; Dodaj wpis "kern.polling.enable=1" do /etc/sysctl.conf.
Aby nie znaleźć się w sytuacji patowej podczas załamania się burzy DDoS na systemy, trzeba je dokładnie przygotować na taką sytuację:
Wszystkie serwery, które mają bezpośredni dostęp do sieci zewnętrznej, powinny być przygotowane na prosty i szybki zdalny restart (sshd uratuje ojca rosyjskiej demokracji). Dużym plusem będzie obecność drugiego, administracyjnego interfejsu sieciowego, przez który można uzyskać dostęp do serwera w przypadku zatkania głównego kanału.
Oprogramowanie używane na serwerze musi być zawsze aktualne. Wszystkie dziury są załatane, aktualizacje są zainstalowane (proste jak rozruch, porady, których wielu nie stosuje). To ochroni Cię przed atakami DoS, które wykorzystują błędy w usługach.
Wszystkie nasłuchujące usługi sieciowe przeznaczone do użytku administracyjnego powinny być ukryte za zaporą ogniową przed każdym, kto nie powinien mieć do nich dostępu. Wtedy atakujący nie będzie mógł ich użyć do przeprowadzenia ataku DoS lub brute force.
Na podejściach do serwera (najbliższego routera) należy zainstalować system analizy ruchu (pomoc NetFlow), który pozwoli w porę dowiedzieć się o rozpoczynającym się ataku i podjąć na czas środki, aby mu zapobiec.
Atak typu SYN flood to forma ataku typu „odmowa usługi”, w którym atakujący wysyła dużą liczbę żądań SYN do usług systemu docelowego korzystających z protokołu TCP. Zużywa to zasoby serwera, aby system nie odpowiadał nawet na uzasadniony ruch. Atak ten może wystąpić na dowolnych usługach korzystających z protokołu TCP, ale głównie na usługach internetowych. W tym samouczku szczegółowo omówimy podstawy ataków typu SYN flood oraz kroki łagodzące.
Atak SYN Flood wykorzystuje charakterystykę implementacji protokołu TCP (Transmission Control Protocol), który nazywa się uzgadnianiem trójstronnym. Poniżej przedstawiono kroki, które występują w normalnym trójetapowym uścisku dłoni:
1. Klient żąda połączenia, wysyłając komunikat SYN (synchronizacja) do serwera.
2. Serwer potwierdza to żądanie, wysyłając SYN-ACK z powrotem do klienta.
3. Klient odpowiada ACK i nawiązuje połączenie.
Atak typu SYN flood polega na tym, że serwer nie odpowiada oczekiwanym kodem ACK. Przez te półotwarte połączenia, zaległości TCP maszyn docelowych zostaną zapełnione, a zatem wszystkie nowe połączenia mogą zostać zignorowane. Spowoduje to, że legalni użytkownicy również zostaną zignorowani.
Atak ten może się odbyć na dwa sposoby:
1. Bezpośredni atak
W tego rodzaju ataku napastnicy szybko wysyłają segmenty SYN bez fałszowania swojego źródłowego adresu IP. Po wykryciu tego typu atak jest bardzo łatwy do obrony, ponieważ możemy dodać prostą regułę zapory, aby blokować pakiety ze źródłowym adresem IP atakującego, który będzie atakował.
2. Korzystanie z fałszowania adresu IP
Jest to bardziej złożona forma ataku niż atak bezpośredni. W tej metodzie złośliwa maszyna wyśle powodzie żądań SYN do maszyny docelowej z sfałszowanych adresów IP, powodując, że serwer wyśle pakiet SYN-ACK na sfałszowany adres IP - który nie wyśle ACK, ponieważ „wie”, że nigdy wysłał SYN.
Wykrywanie ataku powodziowego SYN
Ogólnym objawem ataku SYN Flood na odwiedzającego witrynę internetową jest to, że ładowanie witryny trwa długo lub ładowanie niektórych elementów strony, ale nie innych. Jeśli podejrzewasz atak SYN Flood na serwer WWW, możesz służy do sprawdzania żądań połączenia z serwerem WWW, które są w stanie „SYN_RECEIVED”.
netstat -tuńczyk | grep:80 | grep SYN_RECV
Jeśli pokazuje wiele połączeń w tym stanie, serwer może być atakowany przez SYN Flood. Jeśli atak jest bezpośredni z dużą liczbą pakietów SYN_RECV z pojedynczego adresu IP, możesz powstrzymać ten atak, dodając ten adres IP w zaporze. Jeśli masz zainstalowany APF lub zaporę ogniową na swoim serwerze, możesz to zrobić, wykonując następujące polecenie:
apf -d ADRESIP
csf -dIPADRES
Obrona SYN Flood Attack
Korzystanie z plików cookie SYN
Jest to najskuteczniejsza metoda obrony przed atakiem SYN Flood. Korzystanie z plików cookie SYN pozwala serwerowi uniknąć zrywania połączeń, gdy kolejka SYN się zapełni. Zamiast tego serwer zachowuje się tak, jakby kolejka SYN została powiększona. Serwer odsyła odpowiednią odpowiedź SYN+ACK do klienta, ale odrzuca wpis kolejki SYN. Jeśli serwer następnie otrzyma kolejną odpowiedź ACK od klienta, jest w stanie zrekonstruować wpis kolejki SYN przy użyciu informacji zakodowanych w numerze sekwencyjnym TCP.
Pliki cookie SYN można włączyć, dodając następujące elementy do /etc/sysctl.conf
net.ipv4.tcp_synccookies=1
Po zmodyfikowaniu pliku konfiguracyjnego sysctl należy wykonać następujące polecenie, aby załadować ustawienia sysctl z pliku /etc/sysctl.conf
Zwiększenie kolejki zaległości SYN
Opcjonalną techniką obrony jest zwiększenie rozmiaru kolejki zaległości SYS. Domyślny rozmiar to 1024. Można to zrobić, dodając następujący plik do /etc/sysctl.conf
net.ipv4.tcp_max_syn_backlog=2048
Zmniejszenie ponownych prób SYN_ACK
Poprawienie parametru jądra tcp_synack_retries powoduje, że jądro wcześniej zamyka połączenia stanu SYN_RECV. Wartość domyślna to 5.
net.ipv4.tcp_synack_retries = 3
Ustawianie limitu czasu SYN_RECV
Obniżenie wartości limitu czasu dla SYN_RECV pomoże w ograniczeniu ataku SYN flood. Domyślna wartość to 60 i możemy ją zmniejszyć do 40 lub 45. Można to zrobić dodając następującą linię do sysctl.conf.
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv=45
Zapobieganie fałszowaniu adresów IP
Poniższy parametr sysctl pomoże chronić przed fałszowaniem adresów IP, które jest używane w atakach typu SYN flood.
net.ipv4.conf.all.rp_filter = 1
Wiele firm hostingowych zapewnia ochronę przed atakiem SYN, wdrażając zapory sieciowe, które wykorzystują ochronę przed powodzią SYN, takie jak Netscreen lub Appsafe.
Ataki DoS/DDoS mają na celu zakłócenie podstawowej usługi dostępności. Głównym celem ataków DoS/DDoS jest wyłączenie zaatakowanego obiektu i uniemożliwienie dostępu do jego zasobów uprawnionym użytkownikom. Atak typu „odmowa usługi” można przeprowadzić na dwa sposoby: wykorzystując podatności w oprogramowanie atakowany system i wysyłanie dużej liczby specjalnie skomponowanych pakietów sieciowych (flood).
Pierwsza metoda jest trudniejsza i wymaga wyższych kwalifikacji napastnika. Druga metoda opiera się na użyciu „brutalnej siły”. Pomysł polega na obciążeniu zasobów obliczeniowych serwera poprzez przetworzenie ogromnej liczby pakietów wysyłanych przez atakującego. Takie obciążenie serwera może w najlepszym wypadku doprowadzić do tego, że serwer nie będzie w stanie przyjąć żądań od legalnych użytkowników do przetwarzania, a w najgorszym może doprowadzić do zawieszenia i wyłączenia serwera.
Warto w tym miejscu zauważyć, że można wyróżnić dwa rodzaje ataków mających na celu obciążenie zasobów systemowych: w pierwszym przypadku obciążone są zasoby obliczeniowe serwera, a w drugim przepustowość kanału komunikacyjnego. Opracowana technika jest ukierunkowana na ochronę przed atakami pierwszego typu, więc będziemy dalej zakładać, że przepustowość jest wystarczająca, aby serwer mógł przyjąć cały adresowany do niego ruch.
Dla wielu DoS/ Ataki DDoS wyniki przetwarzania przez serwer pakietów wysłanych przez atakującego nie są dla niego interesujące. Oznacza to, że atakujący może wysyłać strumień fałszywych oświadczeń z fałszywych adresów IP (to pojęcie nazywa się spoofingiem), co uniemożliwia jego wykrycie i skuteczne przeciwdziałanie takim atakom.
Aby przeprowadzić udany atak DoS, wymagana jest dość duża przepustowość kanału. Dlatego w większości przypadków atak typu „odmowa usługi” jest przeprowadzany z kilku komputerów jednocześnie. Atak z udziałem dużej liczby maszyn nazywa się DDoS. Warto zauważyć, że do ataku rozproszonego można wykorzystać maszyny zainfekowane specjalnym oprogramowaniem, które nie należy do atakującego. Takie zainfekowane maszyny nazywane są „zombiami”. Jednym ze sposobów na zdobycie „zombie” jest masowe wprowadzanie „trojanów” na komputery pokojowych użytkowników. Po otrzymaniu polecenia z zewnątrz taki „trojan” zamienia „spokojny” komputer z dostępem do Internetu w źródło fałszywych żądań mających na celu przeciążenie zasobów serwera.
Najczęstsze ataki DoS to:
TCP SYN Flood lub po prostu TCP SYN
Ping śmierci
Przyjrzyjmy się bliżej atakowi TCP SYN (tcp syn flood), który jest wymierzony w usługi aplikacji korzystające z protokołu warstwy transportowej TCP. Protokół ten stał się powszechny w systemach informatycznych, ponieważ gwarantuje 100% dostarczenie wszystkich przesyłanych danych. Współdziałające węzły sieciowe, które używają tego protokołu jako transportu, ustanawiają między sobą połączenia TCP, w ramach których kontroluje się, czy odbiorca otrzyma wszystkie pakiety wysłane przez nadawcę. Osiąga się to dzięki temu, że odbiorca powiadamia nadawcę o odebranych pakietach. Jeśli nie wszystkie przeznaczone dla niego pakiety dotarły do odbiorcy, nadawca wyśle je ponownie. Jak widać zaletą tego protokołu jest możliwość nawiązania połączenia. Do przechowywania informacji o aktualnym stanie połączenia wykorzystywane jest w szczególności pole flag bitowych w pakietach wykorzystywanych przez protokół. Dla tego pola zarezerwowanych jest 8 bitów, jednak 2 z nich są zarezerwowane i obecnie używanych jest tylko 6 flag: URG (flaga pilna), ACK (flaga potwierdzenia), PSH (flaga funkcji push), RST (flaga resetu), SYN (flaga synchronizacji) i FIN (flaga końca). Niestety mechanizm ustanawiania połączenia ustanowiony przez standard nie jest doskonały, a rozważany atak wykorzystuje tylko jego wady.
Głównym celem tego ataku TCP SYN jest przekroczenie limitu liczby połączeń TCP, które są w stanie konfiguracji. Rozważ procedurę nawiązywania połączenia TCP. Najpierw klient inicjujący połączenie wysyła żądanie TCP-SYN do serwera. Po otrzymaniu takiego żądania serwer alokuje pamięć na parametry połączenia w specjalnie zaprojektowanym buforze. Następnie wysyła pakiet z flagami SYN+ACK do klienta TCP. Po odebraniu pakietu SYN+ACK klient musi wysłać pakiet potwierdzenia do serwera, tj. pakiet z ustawioną flagą ACK. Gdy serwer odbierze i przetworzy ten pakiet, połączenie zostanie nawiązane. Opisane powyżej
procedurę pokazano na ryc. 1,1
Ryż. 1,1
Atak TCP SYN przeprowadza się w następujący sposób: atakujący generuje dużą liczbę pakietów z ustawionymi flagami SYN protokołu TCP. Odbierając pakiety, atakowana maszyna alokuje pamięć do przechowywania parametrów połączenia i wysyła odpowiedź - pakiet ze znacznikami SYN+ACK i oczekuje pakietu ze znacznikiem ACK. Oczywiście nie otrzyma oczekiwanej odpowiedzi, a pamięć zostanie zwolniona dopiero po upływie ustawionego limitu czasu. Po pewnym czasie bufor przeznaczony do przechowywania parametrów TCP połączeń zostanie całkowicie zajęty, w wyniku czego system nie będzie mógł nawiązywać nowych połączeń. Potem każdy dodatkowe żądanie dodatkowo zwiększa obciążenie. Takie ataki nie są potrzebne informacja zwrotna z atakującym, dzięki czemu atakujący może wygenerować pakiet z dowolnymi adresami IP nadawcy.
Brak informacji zwrotnej od atakującego sprawia, że wykrycie i odparcie ataku TCP-SYN jest sporym wyzwaniem.
Wyznaczanie celów ochrony przed zagrożeniami
Obecnie w otwartej literaturze nie są znane żadne skuteczne metody wykrywania ataków TCP SYN. Współczesne systemy operacyjne posiadają mechanizmy chroniące atakowany serwer, takie jak pliki cookie SYN. System operacyjny automatycznie włącza ochronę, gdy wykryje przekroczenie niektórych parametrów. Na przykład Windows 2000 monitoruje wartości trzech parametrów: TcpMaxHalfOpen, TcpMaxHalfOpenRetried, TcpMaxPortsExhausted . Progi dla tych ustawień mają wartości domyślne i mogą być zmieniane przez administratora. Jeśli początkowe wartości nie są odpowiednie dla konkretnego serwera, administrator ma trudne zadanie, aby skutecznie skonfigurować ochronę. Ponadto metoda ta wymaga odpowiednich zmian w implementacji stosu TCP/IP, co niektórzy eksperci sieciowi uważają za „poważne naruszenie” protokołu TCP.
Inną wadą narzędzi do wykrywania ataków TCP zintegrowanych z systemem operacyjnym jest to, że po przeciążeniu (co oznacza brak zasobów procesora i pamięci) lub zawieszeniu się samego systemu, środki zaradcze również przestają działać.
Celem pracy mistrza jest stworzenie matematycznie poprawnej metody wykrywania ataków TCP SYN. W tym celu konieczne jest zbudowanie modelu matematycznego opisującego interakcję serwera TCP z klientami. Parametrami początkowymi takiego modelu powinna być charakterystyka serwera i kanału komunikacji, a parametrem wyjściowym stwierdzenie o obecności lub braku ataku TCP-SYN.
Umiejętność wykorzystania proponowanej metodologii w praktyce do ochrony krytycznych zasobów sieć korporacyjna potrzebne są również narzędzia do określenia rzeczywistych wartości parametrów wejściowych modelu dla konkretnego serwera i sieci, do której jest podłączony.
Zastrzeżenie 1: Proszę wybaczyć, że artykuł jest dość zmięty, a wiele tematów nie jest w pełni omówionych. Zapraszam do zadawania pytań w komentarzach. Ja z kolei postaram się ujawnić jak najwięcej ciekawe tematy w przyszłych artykułach.
Zastrzeżenie 2: Istnieje wiele artykułów w sieci zatytułowanych „Jak chronić serwer przed atakami SYN” lub „Ochrona przed atakami DDoS dla systemu Linux”. Muszę cię ostrzec, że wielu z nich nie należy ślepo ufać! Często pisane są przez osoby, które nie rozumieją dobrze, co się dzieje podczas ataku, i zalecają robienie szalonych rzeczy – ktoś „optymalizuje” sysctl tak, aby nawet normalny ruch przestał chodzić na serwer, a większość radzi też włączyć syncookies, co jest kategorycznie zrobienie tego jest niemożliwe z większością prawdziwych ataków!
Ten artykuł ma 3 cele:
Co to jest atak SYN?
SYN flood lub atak SYN to technika odmowy usługi, która wpływa na hosty, na których działają procesy serwera TCP. Atak wykorzystuje fakt, że TCP przechowuje stan sesji po odebraniu segmentu SYN na porcie będącym w stanie LISTEN. Główną ideą jest wykorzystanie tego zachowania poprzez nadanie hostowi takiego stanu dla fałszywych półotwartych sesji, że nie ma już zasobów do nawiązania nowych połączeń (RFC4987).
SYN flooding jest stosunkowo trudny do pokonania, dlatego ten rodzaj ataku jest tak popularny. Czemu?
1) Zwykle używane są adresy IP z losowego źródła, które są bezużyteczne do banowania, ponieważ są generowane ponownie w każdym pakiecie;
2) Atak SYN zużywa niewiele zasobów po stronie atakującego i dużo po stronie ofiary;
3) Ochrona przed tego typu atakami jest dość złożona, pełna niuansów, a jej zrozumienie i wdrożenie wymaga czasu.
Uważam, że serwery, które mogą być potencjalnie atakowane (w rzeczywistości wszystkie serwery, które mają publiczne adresy IP, zwłaszcza serwery WWW) powinny być wcześniej chronione przed atakami SYN.
Rysunek 1: Atak SYN
Jak przeprowadzane są ataki SYN?
Przykładem narzędzia często wykorzystywanego do przeprowadzania ataków jest hping3. Możesz go użyć do testów obciążeniowych serwera, zanim atakujący zrobią to za Ciebie.
hping3 to bogate w funkcje narzędzie, które może przeprowadzać wiele rodzajów ataków o różnych parametrach. Nie dam klasy mistrzowskiej z jego użytkowania, pokażę tylko przykład jak można sprawdzić serwer pod kątem podatności na mały atak SYN:
# hping3 -S<--fast|--faster|--flood>-p 80 xx.xx.xx.xx
80 (HTTP) w tym przykładzie jest portem docelowym. Spójrz na inne opcje (hping3 --help), aby zobaczyć, jak ataki mogą się od siebie różnić.
Używaj tego narzędzia ostrożnie i tylko do testowania własnych zasobów! Szczerze mówiąc, większość Internetu jest podatna na te proste operacje, nawet jeśli atakujący ma znacznie mniejszy kanał niż atakowany.
Jak zidentyfikować i zmierzyć atak SYN?
1) Podczas ataku SYN atakujący otwiera wiele połączeń z serwerem, ale nigdy ich nie zamyka, a połączenia nadal zawieszają się w stanie SYN_RECV. Można je obliczyć w następujący sposób:
# netstat -anutp | grep SYN_RECV | wc-l
Jeśli ta liczba jest >30, prawdopodobnie jesteś pod atakiem SYN.
2) Możesz monitorować bieżące obciążenie sieci za pomocą vnstat:
# vnstat -l -i eth0
To bardzo przydatne narzędzie, które pomoże Ci zrozumieć, jak silny jest atak.
Naciśnij F2, przejdź do „Opcje wyświetlania” i wybierz „Wyświetl nici w innym kolorze”. W kolorze różowym widać obciążenie przerwaniami systemowymi.
4) Przejrzyj pliki SYN otrzymywane przez serwer – co mają ze sobą wspólnego? "-c 100" mówi tcpdumpowi, aby ograniczył się do 100 pakietów.
# tcpdump -i eth0 -nn "port tcp 80" i "tcp == 2" -c 100
Na koniec pamiętaj, że wiele ataków SYN nie jest „jednolitych”, mają szczyty i spadki, które należy wziąć pod uwagę w procesie analizy.
Rysunek 2. Dynamika typowego ataku
Najpierw najważniejsze rzeczy
Karta sieciowa, przerwania, kolejki...
Pierwszą rzeczą do pracy jest sterownik karta sieciowa. Kiedy ramka dociera do karty sieciowej, musi zainicjować przerwanie systemowe, które mówi procesorowi, aby zawiesił bieżące zadanie i przetworzył przychodzącą część ruchu. Jeśli jednak każda ramka powodowała natychmiastowe przerwanie i „odwracała” uwagę procesora od bieżącego zadania, zauważalne pogorszenie wydajności można było zaobserwować nawet w przypadku najprostszych operacji sieciowych, takich jak przesyłanie plików przez FTP. Dlatego te przerwania są zorganizowane w kolejkę, która gromadzi się na karcie sieciowej i jest jednocześnie przetwarzana przez procesor. Zwykle dzieje się to 250-1000 razy na sekundę, im rzadziej - im mniejsze obciążenie procesora, tym większe opóźnienie.
Z drugiej strony większość nowoczesnych komputerów stacjonarnych i serwerów ma wiele rdzeni procesorów. Ponieważ każdy z nich pracuje jako osobny procesor dla systemu operacyjnego, możemy równomiernie rozłożyć obciążenie przerwaniami między nimi. Można to zrobić na 2 sposoby.
1) Pierwszym i zalecanym jest korzystanie z kolejek sprzętowych. Nowoczesne karty sieciowe mają wiele kolejek przerwań, zwykle 4-16. Z jakiegoś powodu w Linuksie często są domyślnie wyłączone. Musimy je włączyć, a następnie równomiernie rozłożyć na procesory.
2) Druga metoda nazywa się RPS - Receive Packet Steering. To jest ładne nowy mechanizm jądra, które automatycznie rozdziela obciążenie między wszystkie rdzenie, nie ma znaczenia, czy karta ma kilka kolejek sprzętowych, czy nie. Użyj tej metody tylko jeśli masz więcej rdzeni niż kolejek sprzętowych (przy okazji rozważ wyłączenie SMT/HyperThreading - przyda się podczas ataku).
Rysunek 3. Karta sieciowa Intel 10 Gb
Kroki do podjęcia:
1) Określ producenta i model karty sieciowej (byłoby lepiej, gdyby był to Intel)
# ethtool -i eth0
2) Zainstaluj najnowsze sterowniki. Przejdź do witryny producenta chipa karty sieciowej i pobierz Ostatnia wersja sterowniki dla Linuksa (do zbudowania potrzebne są źródła aktualnego jądra)
3) Skonfiguruj kolejki sprzętowe. Aby to zrobić, musisz skorzystać z dokumentacji sterownika karty sieciowej, która jest z nim dołączona. dla igb( Sterowniki Intel) z 8 kolejkami i 4 portami wygląda to tak:
# rmmod igb
# modprobe igb QueuePairs=1,1,1,1 RSS=8,8,8,8 IntMode=3,3,3,3 InterruptThrottleRate=3000,3000,3000,3000
W przypadku sterownika igb w RHEL/CentOS wystarczy dodać wiersz opcji sterownika do /etc/modprobe.conf i uruchomić ponownie:
opcje igb QueuePairs=1,1,1,1 RSS=8,8,8,8 IntMode=3,3,3,3 InterruptThrottleRate=3000,3000,3000,3000
4) Rozmieść obciążenia przerwania równomiernie między rdzeniami.
Konieczne będzie określenie, z jakich numerów przerwań korzysta karta (w naszym przypadku eth0).
# cat /proc/interrupts | grep eth0
Tutaj możesz zobaczyć wszystkie numery przerwań używane przez twoją kartę sieciową i jak faktycznie są one obecnie rozłożone w rdzeniach. Zapisz te liczby. Teraz musimy zmienić powinowactwo SMP, aby przypisać każdemu przerwaniu jego własny rdzeń (przerwanie 1 > procesor 1, przerwanie 2 > procesor 2 itd.). Oto jak to się robi:
# Echo
5) OPCJONALNIE: Włącz RPS (może to nie być potrzebne, patrz wyżej)
# echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus
Wybierz odpowiednie urządzenie (jeśli nie jest to eth0) i wszystkie obsługiwane przez nie kolejki odbiorcze (rx-0..n).
sysctl
Następna rzecz nazywa się sysctl. Jest to interfejs oprogramowania, który pozwala na konfigurację wielu ustawień systemowych w locie. Jednak w tym artykule powstrzymamy się od omawiania tego, jak je wykorzystać do ochrony przed atakami SYN - zbyt wiele na ten temat napisano już w Internecie.
Wbrew temu, co myśli większość "doradców", NIE MA ŻADNYCH "uniwersalnych optymalizacji", które pasowałyby do każdego, kto posiada serwer. Każda tak zwana optymalizacja ma konsekwencje w postaci zwiększonego zużycia pamięci lub zmniejszonej dostępności/funkcjonalności. Oczywiście pewne zmiany muszą zostać zastosowane, ale ten temat zasługuje na osobny artykuł, obszerniejszy niż ten.
Jedyną rzeczą, na którą chcę zwrócić uwagę jako ważną i często nadużywaną, są tzw. syncookies. Krótko mówiąc, jest to ogólnosystemowy mechanizm zwalczania ataków SYN poprzez wysyłanie plików cookie w odpowiedzi na każde żądanie SYN w celu potwierdzenia legalności połączenia. Faktem jest, że może to być naprawdę przydatne, jeśli współczynnik ataków wynosi 40% efektywnej przepustowości serwera lub mniej (przez efektywne rozumiem to wydajność, które serwer faktycznie jest w stanie przetworzyć). W innych przypadkach użycie syncookies prowadzi do zwiększenia obciążenia sieci, procesora, a tym samym do odmowy usługi.
Osobiście w większości przypadków wyłączam syncookies.
Podstawowe techniki bezpieczeństwa z iptables
Nie zapomnij "wzmocnić" swojego firewalla: blokuj cały ruch przychodzący z wyjątkiem tego, co jest NAPRAWDĘ potrzebne na twoim serwerze. Zezwalaj na zarządzanie tylko z zaufanych sieci.
Najprostszym przypadkiem jest atak z 1 IP bez podmiany adresu (spoofing). Łatwo sobie z nimi poradzić:
# iptables -A WEJŚCIE -p tcp -m stan -- stan NOWOŚĆ -m niedawne --update --sekundy 60 --hitcount 20 -j DROP
# iptables -A INPUT -p tcp -m stan --state NOWY -m ostatnie --set -j AKCEPTUJ
Reguły te ograniczają liczbę pakietów SYN na adres do 20 na minutę. Tylko nie używaj go cały czas! Możesz zablokować legalny ruch spoza NAT.
Wiele ataków SYN można odfiltrować za pomocą „nietypowych” i powtarzalnych parametrów nagłówka TCP, które atakują narzędzia „sin”.
Pierwszym takim parametrem jest MSS (Maximum Segment Size) - maksymalny rozmiar segmentu, na który host inicjujący połączenie chce zezwolić. Większość narzędzi ataku (w tym hping) domyślnie nie włącza tej opcji. Z drugiej strony nie widziałem jeszcze legalnych klientów, którzy by go nie zainstalowali. „Normalne” wartości wahają się od 536 do 65535, użyjmy tego:
# iptables -t mangle -I PREROUTING -p tcp -m tcp --dport 80 -m stan --state NOWOŚĆ -m tcpmss ! --mss 536:65535 -j DROP
Nawiasem mówiąc, tabela maglowania jest szybsza niż filtr, ponieważ jest przetwarzana wcześniej, ale cały ruch przez nią przechodzi i nie ma możliwości oddzielenia INPUT, OUTPUT i FORWARD.
Kolejny niezwykle przydatny parametr to rozmiar okna TCP. Większość atakujących nie generuje go za każdym razem i pozostaje on taki sam przez cały atak. Aby filtrować i blokować segmenty według rozmiaru okna, potrzebujesz modułu u32 dla iptables. Gdy już znasz rozmiar okna ataku (na przykład 512), przekonwertuj je na szesnastkowy (w naszym przypadku 0x200) i uruchom następujące polecenie:
# iptables -t mangle -I PREROUTING -d xx.xx.xx.xx -p tcp -m u32 --u32 "6&0xFF=0x6 && 32&0xFFFF=0x200" -j DROP
Ale bądź ostrożny! Nie blokuj dobrze znanych rozmiarów okien używanych przez popularne systemy operacyjne: 14600, 1892, 65535, 62240, 5840, 32120, 5720, 4128, 8760, 16384, 62920, 64380 i 17820.
Na koniec wspomnimy o parametrze TTL (Time To Live). Chcę, aby był to ostatni parametr, na którym opierają się twoje kontrole, ponieważ zakres wartości jest niewielki i prawie na pewno zablokujesz niewłaściwą osobę. Ale kiedy widzisz dużo pakietów ataku i pasują one tylko do TTL - to może pomóc.
# iptables -A FORWARD -p tcp -m ttl --ttl-eq=55 -m state --state NOWE -j DROP
Jeśli nic nie pomaga
Skontaktuj się z profesjonalistami! Jestem poważny. To, co tutaj opisano, to tylko wierzchołek góry lodowej. Pamiętaj, że istnieją dwie strategie obrony, których należy używać razem:
1) Zwiększenie/optymalizacja zasobów obliczeniowych/sieciowych w celu przetworzenia większej liczby żądań;
2) Odseparowanie ruchu niepożądanego od ruchu legalnego w celu jego dalszego blokowania.
Masz więc 3 powody, by poprosić o pomoc z zewnątrz:
1) Nie masz wystarczającej przepustowości lub zasobów obliczeniowych, aby oddzielić niechciany ruch od legalnego;
2) Atak jest złożony, a niechciane pakiety nie różnią się lub prawie nie różnią się od prawdziwych. Profesjonaliści stosują bardziej zaawansowane metody filtrowania i czasami drogi specjalistyczny sprzęt i oprogramowanie.
I w końcu
