Kali linux syn flood

Содержание

Моделируем и определяем DoS атаку типа TCP SYN Flood при помощи Wireshark
Принцип работы атаки TCP SYN Flood
Использование Kali Linux & hping3 для моделирования атаки TCP SYN Flood
Использование Wireshark для идентификации атаки TCP SYN Flood
Резюме
1 Introduction
2. syn flood attack
1. scapy constructs data packets
2. Script attack
1. Script attack linux server
2. Attack windows machine
3. Flooding attacks are often accompanied by IP address spoofing

Моделируем и определяем DoS атаку типа TCP SYN Flood при помощи Wireshark

В рамках данного руководства мы расскажем вам о сути атаки TCP SYN Flood. Кроме того, вы узнаете, как смоделировать данную DoS-атаку злоумышленников для тестовых целей с помощью предустановленной программы-генератора пакетов hping3 дистрибутива Kali Linux, а также как правильно и быстро идентифицировать атаку TCP SYN Flood, используя анализатор сетевых протоколов Wireshark. Данный материал содержит простые, интуитивно понятные инструкции, иллюстрации и скриншоты, что обеспечит комфортное обучение, как для начинающих, так и для опытных ИТ-специалистов.

Атаки «отказа в обслуживании» (Denial of Service), печально известные также как DoS-атаки, достаточно просты в проведении, далеко не всегда очевидны и способны стать причиной серьезных сбоев в работе вычислительной системы, что неминуемо приведет к увеличению времени простоя ваших системных ресурсов. При атаке с помощью переполнения SYN-пакетами (TCP SYN Flood) злоумышленники используют трехстороннее рукопожатие по протоколу TCP, чтобы вызвать сбои в работе сети и сервисов. Атаки такого типа могут легко застать вас врасплох, так как зачастую системным администраторам бывает сложно их быстро идентифицировать. К счастью, такие инструменты, как Wireshark, упрощают захват и проверку любых подозрительных активностей, которые могут оказаться DoS-атакой.

Данное руководство содержит довольно много интересной информации, которая для удобства разбита на следующие части:

Принцип работы атаки TCP SYN Flood.
Использование Kali Linux & hping3 для моделирования в тестовых целях атаки TCP SYN Flood.
Использование Wireshark для идентификации атаки TCP SYN Flood.

Принцип работы атаки TCP SYN Flood

Когда клиент пытается подключиться к серверу с использованием протокола TCP (например, при установлении HTTP- или HTTPS-соединения), он сразу должен пройти процедуру трехстороннего рукопожатия, прежде чем обмен данными между клиентом и сервером станет возможным. Поскольку инициатором трехстороннего рукопожатия TCP всегда является клиент, то он первым отправляет пакет с флагом SYN серверу.

Рисунок 1. Трехстороннее рукопожатие TCP.

Получив такой SYN-пакет, сервер отвечает, подтверждая получение запроса и отправляя при этом свой собственный запрос SYN — пакет с установленными флагами SYN и ACK. Клиент, в свою очередь, получив пакет с подтверждением и запросом от сервера, отправляет серверу пакет с установленным флагом ACK, который подтверждает, что оба хоста согласны создать соединение. После такого «обмена рукопожатиями» соединение считается установленным, и данные могут передаваться между хостами. (Более детально об использовании протокола TCP при установке соединения и процедуре трехстороннего рукопожатия читайте здесь).

При проведении TCP SYN Flood атаки злоумышленники интенсивно отправляют серверу большое количество SYN-пакетов с поддельными IP-адресами. Это заставляет сервер реагировать, отправляя в ответ на каждый такой ложный запрос пакет SYN-ACK, выделяя часть ресурсов и оставляя свои порты «полуоткрытыми» в ожидании многочисленных ответов (пакетов с установленным флагом ACK) от хостов, которых на самом деле не существует, и подтверждений они, соответственно, отправлять не будут.

Рисунок 2. Принцип осуществления злоумышленником атаки TCP SYN Flood.

При проведении более простой версии атаки TCP SYN Flood (прямой атаки без подмены IP-адреса) злоумышленники просто используют настройки брандмауэра, чтобы заблокировать получение обратных пакетов с установленными флагами SYN и ACK от сервера жертвы еще до того, как эти отправленные в ответ запросы достигнут их системы. Заваливая свою цель SYN-пакетами и не отвечая на запросы (не отправляя в ответ пакеты ACK), атакующие могут легко исчерпать ресурсы цели, при этом не слишком перегружая свои ресурсы. Ведь в это время сервер жертвы «изо всех сил» пытается справится с резко возросшим трафиком, что, как следствие, серьезно увеличивает использование ЦП и памяти. В конце концов, это может привести к исчерпанию всех его ресурсов (ЦП и ОЗУ), и сервер жертвы больше не сможет обслуживать любые клиентские запросы (в том числе и от добросовестных пользователей), то есть не предоставлять им доступ к системным ресурсам и сервисам.

Использование Kali Linux & hping3 для моделирования атаки TCP SYN Flood

Однако, для того, чтобы провести аудит безопасности и проверить, можете ли вы обнаружить этот тип DoS-атаки, прежде всего вы должны научиться ее сами проводить. Пожалуй, самый простой способ достижения этой цели базируется на использовании дистрибутива Kali Linux, а точнее — программы hping3, популярного TCP-инструмента тестирования проникновения, включенного в набор Kali Linux.

Пользователи Linux в качестве альтернативной возможности могут установить инструментарий hping3 в свой существующий дистрибутив Linux с помощью следующей команды:

«# sudo apt-get install hping3»

Так как в большинстве случаев злоумышленники будут использовать генератор пакетов hping или другой инструментарий с подобной функциональностью для подмены реальных IP-адресов случайными, мы также обратим фокус нашего внимания на этот момент. Следующая строка позволяет нам начать и направить атаку TCP SYN Flood на нашу цель (192.168.1.159):

«# hping3 -c 15000 -d 120 -S -w 64 -p 80 —flood —rand-source 192.168.1.159»

Рисунок 3. Реализация атаки TCP SYN Flood с помощью предустановленной программы hping3 дистрибутива Kali Linux.

А теперь давайте детально разберем приведенную чуть выше команду. Мы отправляем 15000 пакетов («-c 15000») размером 120 байт («-d 120») каждый. Мы также указываем, что флаг SYN («-S») должен быть включен, а размер TCP-окна имеет значение 64 («-w 64»). Чтобы направить атаку на HTTP-веб-сервер нашей жертвы, мы указываем порт 80 («-p 80») и используем флаг («—flood») для максимально быстрой отправки пакетов. Как вы, наверное, уже поняли, флаг («—rand-source») используется для генерирования поддельных IP-адресов, чтобы замаскировать реальный источник и избежать обнаружения, а также в то же самое время не дать системе злоумышленника получать ответные пакеты с установленными флагами SYN и ACK от сервера жертвы.

Использование Wireshark для идентификации атаки TCP SYN Flood

Теперь, когда мы научились моделировать атаку злоумышленников, мы можем попытаться обнаружить ее. Наиболее часто профессионалы выбирают для этих целей Wireshark. Для новичка при первом взгляде Wireshark может показаться довольно сложным инструментом. Однако он обладает рядом уникальных преимуществ, которых нет ни у одного другого инструментария, который вы можете использовать в качестве альтернативы для решения этой проблемы. Его функциональность подходит для решения огромного количества задач, он полностью бесплатный, с открытым исходным кодом и доступен на многих платформах.

Для лучшего иллюстрирования нашего руководства мы создали тестовую среду, в которой мы использовали ноутбук с установленным дистрибутивом Kali Linux для проведения атаки через сетевой коммутатор на стационарный компьютер под управлением ОС Windows 10. Несмотря на то, что подобная структура защищена намного хуже, чем многие корпоративные сети, для нашего тестового испытания это не имеет значения, так как злоумышленники могут реализовать подобные атаки после получения несанкционированного доступа и проникновения в сеть. Также как вы могли видеть из приведенной выше команды hping3 (детальнее смотрите на рисунке 3), мы использовали случайные IP-адреса, так как именно этот метод атаки TCP SYN Flood будут использовать опытные злоумышленники.

Осуществляемую атаку TCP SYN Flood довольно легко обнаружить, если вы знаете, что ищете. Ее начало администраторы сразу же должны идентифицировать по резко возросшему потоку TCP-трафика. Как и следовало ожидать, основным признаком именно этой атаки является огромное количество пакетов с флагом SYN, получаемых атакуемым сервером (в нашей тестовой демонстрации — ПК с Windows 10). При анализе трафика для их идентификации нам потребуются определенные фильтры. Так, мы можем отфильтровать трафик по полученным пакетам с установленным флагом SYN без последующего подтверждения (получения пакетов с установленным флагом ACK), используя следующий фильтр:

«tcp.flags.syn == 1 and tcp.flags.ack == 0»

Как вы можете убедиться, взглянув на рисунок 4, мы обнаружили большое количество TCP-пакетов с установленным флагом SYN без последующего подтверждения на запрос сервера, полученных с очень малой разницей во времени. Источники каждого такого SYN-пакета отличаются (все пакеты отправлены с различных IP-адресов), но все они имеют идентичный порт назначения 80 (HTTP), идентичную длину (120) и размер TCP окна (64). Если мы зададим фильтр «tcp.flags.syn == 1 and tcp.flags.ack == 1», то увидим, что количество полученных пар пакетов от клиентов (сразу с установленным флагом SYN, а затем — с флагом ACK) относительно небольшое (детальнее на рисунке 5). Это верный признак атаки TCP SYN Flood на вашу систему.

Мы также можем посмотреть графики Wireshark для визуального представления о росте трафика. График полученных/отправленных пакетов можно получить с помощью выбора меню «Statistics —> I/O Graph». Для нашего тестового примера этот график демонстрирует огромный всплеск количества пакетов от 0 до примерно 2400 пакетов в секунду (детально проиллюстрировано на рисунке 6).

Рисунок 6. Иллюстрация атаки TCP SYN Flood с помощью графика Wireshark.

Удалив наш фильтр и открыв статистические данные иерархии протоколов («Protocol hierarchy statistics»), мы также можем убедиться, что нами был зафиксирован необычно большой объем TCP-пакетов (детальнее на рисунке 7).

Рисунок 7. Иллюстрация атаки TCP SYN Flood с помощью статистических данных иерархии протоколов Wireshark.

Все приведенные нами в рамках данного руководства наблюдения за резким изменением показателей с большой долей вероятности указывают именно на обнаружение атаки TCP SYN Flood, оставляя очень мизерные шансы для другой интерпретации. Таким образом, используя Wireshark, мы можем убедиться в осуществлении противоправных действий с использованием трехстороннего рукопожатия по протоколу TCP со стороны злоумышленников против наших сетевых ресурсов, и вовремя принять меры для исправления ситуации.

Резюме

В рамках данного руководства мы показали, как в тестовых целях смоделировать атаку TCP SYN Flood с помощью дистрибутива Kali Linux (предустановленного инструментария hping3), а также как обнаружить эту DoS-атаку, используя фильтры и графики анализатора сетевых протоколов Wireshark, и своевременно принять меру для ее нейтрализации.

Появились вопросы или нужна консультация? Обращайтесь!

Источник

1 Introduction

TCP connection and port process

TCP connection establishment

The first handshake: When establishing a connection, the client sends a syn packet (syn=j) to the server, and enters the SYN_SENT state, waiting for the server to confirm; SYN: Synchronize Sequence Numbers.

The second handshake: the server receives the syn packet, it must confirm the client’s SYN (ack=j+1), and at the same time send a SYN packet (syn=k), that is, the SYN+ACK packet, and the server enters the SYN_RECV state;

The third handshake: The client receives the SYN+ACK packet from the server, and sends an acknowledgment packet ACK (ack=k+1) to the server. After the packet is sent, the client and the server enter the ESTABLISHED (TCP connection successful) state, which is completed three times shake hands.

After completing the three-way handshake, the client and server begin to transmit data. In the above process, there are some important concepts:

Unconnected queue
In the three-way handshake protocol, the server maintains an unconnected queue, which opens an entry for each client’s SYN packet (syn=j), which indicates that the server has received the SYN packet , And send a confirmation to the customer, waiting for the customer’s confirmation package. The connection identified by these entries is in the SYN_RECV state on the server. When the server receives the client’s confirmation packet, it deletes the entry and the server enters the ESTABLISHED state.

Close TCP connection

For an established connection, TCP uses an improved three-way handshake to release the connection (using a segment with a FIN additional mark). The steps for TCP to close the connection are as follows:

In the first step, when the application of host A informs that the TCP data has been sent, TCP sends a message segment with the FIN additional mark to host B (FIN stands for English finish).

In the second step, after host B receives this FIN segment, it does not immediately reply to host A with the FIN segment, but first sends an acknowledgment sequence number ACK to host A, and at the same time informs its corresponding application: the other party requested to close Connection (the purpose of sending ACK first is to prevent the other party from retransmitting the FIN segment during this time).

In the third step, the application program of host B tells TCP: I want to completely close the connection, and TCP sends a FIN segment to host A.

In the fourth step, after host A receives this FIN segment, it sends an ACK to host B to indicate that the connection is completely released.

TCP connection status

Two serial numbers and three flag bits:

Sequence number: seq sequence number, occupies 32 bits, used to identify the byte stream sent from the TCP source to the destination, and the initiator will mark this when sending data.
Acknowledgement sequence number: ack sequence number, occupying 32 bits, only when the ACK flag bit is 1, the acknowledgment sequence number field is valid, ack=seq+1.

Flag bits: 6 in total, namely URG, ACK, PSH, RST, SYN, FIN, etc. The specific meanings are as follows:

URG: Urgent pointer is valid.
ACK: Confirm that the serial number is valid.
PSH: The receiver should deliver this message to the application layer as soon as possible.
RST: Reset the connection.
SYN: initiate a new connection.
FIN: Release a connection.

have to be aware of is:

Don’t confuse the acknowledgment number ack with the ACK in the flag bit.
Confirming party ack=initiating party req+1, both ends are paired.

In the first message sending, A randomly selects a sequence number as its initial sequence number and sends it to B; the second message B uses ack to confirm A’s data packet.

Because the data packet with sequence number x has been received and is ready to receive the packet with sequence number x+1, ack=x+1, and B tells A its initial sequence number, which is seq=y;

The third message A tells B that it has received the confirmation message from B and is ready to establish a connection. The sequence number of this message of A itself is x+1, so seq=x+1, and ack=y+1 means that A is preparing to receive B has a data packet whose sequence number is y+1.

Wave four times:

Since the TCP connection is full-duplex, each direction must be closed separately. This principle is that when one party completes the data sending task, it sends a FIN to terminate the connection in this direction.

Receiving a FIN only means that there is no data flow in this direction, that is, no more data will be received, but data can still be sent on this TCP connection until the FIN is also sent in this direction.

The first party to shut down will perform active shut down, while the other will perform passive shut down, as described in the figure above.

(1) First wave: Client sends a FIN to close the data transfer from Client to Server, and Client enters FIN_WAIT_1 state.

(2) The second wave: After receiving the FIN, the Server sends an ACK to the Client to confirm that the serial number is the received serial number +1 (same as SYN, one FIN occupies a serial number), and the Server enters the CLOSE_WAIT state.

(3) The third wave: Server sends a FIN to close the data transfer from Server to Client, and Server enters the LAST_ACK state.

(4) The fourth wave: After the client receives the FIN, the client enters the TIME_WAIT state, and then sends an ACK to the server, confirming that the serial number is the received serial number +1, the server enters the CLOSED state, and completes four waves.

2. syn flood attack

1. scapy constructs data packets

1. Construct an IP packet

2. Construct a TCP packet

3. Sending data packets need to be constructed in the form of IP()/TCP(): i/t

4. Since the reset data packet will be sent to the server when the connection request is reestablished, the connection request is not achieved. You can set the firewall rules locally: