Если узел получит по протоколу tcp сообщение без флага syn и предшествующего тройного рукопожатия

Обновлено: 17.05.2024

Применяя программу - анализатор трафика и используемых протоколов - Wireshark , Вы можете наблюдать работу трехэтапного квитирования TCP:

Клиент TCP начинает трехэтапное квитирование, отправляя сегмент с установленным контрольным флагом SYN (Синхронизировать Номер Последовательности), указывая первоначальное значение в поле номера последовательности в заголовке. Это первоначальное значение номера последовательности, известное как Начальный Номер Последовательности (ISN), выбирается случайным образом и используется, чтобы начать отслеживание потока данных от клиента на сервер для этой сессии. ISN в заголовке каждого сегмента увеличивается на единицу для каждого байта данных, отправленных от клиента серверу, пока продолжается обмен данными.

Из рисунка видно, как вывод анализатора протоколов показывает флаг управления SYN и относительный номер последовательности.

Контрольный Флаг SYN установлен, и относительный номер последовательности равен 0. Хотя анализатор протоколов на графике указывает относительные значения для номеров последовательности и подтверждения, истинные значения является двоичными 32-битными числами. Мы можем определить фактические номера, отправляемые в заголовках сегментов, исследуя область "Packet Bytes" (Байты Пакета). Здесь можно видеть четыре байта, представленные в шестнадцатеричной форме.

TCP сервер должен подтвердить получение сегмента SYN от клиента, чтобы установить сеанс от клиента к серверу. Чтобы это сделать, сервер отсылает сегмент назад к клиенту с установленным флагом ACK, указывающим, что поле номера подтверждения задействовано. С этим флагом, установленным в сегменте, клиент распознает это как подтверждение, что сервер получил SYN от TCP клиента.

Значение поля номера подтверждения равно начальному номеру последовательности клиента, увеличенному на единицу. Таким образом устанавливается сессия от клиента на сервер. Флаг ACK останется установленным для балансировки сессии. Вспомните, что диалог между клиентом и сервером - фактически два однонаправленных сеанса: один от клиента к серверу, и другой от сервера клиенту. На этом втором шаге трехэтапного квитирования сервер должен инициировать ответ от сервера клиенту. Чтобы запустить этот сеанс, сервер использует флаг SYN таким же образом, как это делал клиент. Он устанавливает флаг управления SYN в заголовке, чтобы установить сеанс от сервера клиенту. Флаг SYN указывает, что первоначальное значение поля номера последовательности присутствует в заголовке. Это значение будет использоваться, чтобы отслеживать поток данных в этом сеансе от сервера назад к клиенту.

Как видно из рисунка, вывод анализатора протоколов показывает, что контрольные флаги ACK и SYN установлены, а также показаны относительные номера последовательности и подтверждения.

Наконец, TCP клиент отвечает сегментом, содержащим ACK, что является реакцией на TCP SYN, отправленный сервером. В этом сегменте нет никакой пользовательской информации. Значение в поле номера подтверждения содержит значение на единицу больше, чем начальный номер последовательности, полученный с сервера. Как только оба сеанса устанавливаются между клиентом и сервером, все дополнительные сегменты, которыми обмениваются в этой сессии, будут иметь установленный флаг ACK.

Как видно из рисунка, вывод анализатора протоколов показывает установленный контрольный флаг ACK и относительные номера последовательности и подтверждения.

Усилить безопасность сети можно следующими способами:

Запрет на создание сеансов TCP
Разрешение установки сессий только для определенных служб
Разрешение только того трафика, который является частью уже установленных сессий

Эта безопасность может быть реализована для всех сеансов TCP или только для выбранных сессий.

Ускорение каких-либо процессов невозможно без детального представления их внутреннего устройства. Ускорение интернета невозможно без понимания (и соответствующей настройки) основополагающих протоколов — IP и TCP. Давайте разбираться с особенностями протоколов, влияющих на скорость интернета.

IP (Internet Protocol) обеспечивает маршрутизацию между хостами и адресацию. TCP (Transmission Control Protocol) обеспечивает абстракцию, в которой сеть надежно работает по ненадежному по своей сути каналу.

RFC 791 – Internet Protocol
RFC 793 – Transmission Control Protocol

Стандарт НТТР не требует использования именно TCP как транспортного протокола. Если мы захотим, мы можем передавать НТТР через датаграммный сокет (UDP – User Datagram Protocol) или через любой другой. Но на практике весь НТТР трафик передается через TCP, благодаря удобству последнего.

Поэтому необходимо понимать некоторые внутренние механизмы TCP, чтобы оптимизировать сайты. Скорее всего, вы не будете работать с сокетами TCP напрямую в своем приложении, но некоторые ваши решения в части проектирования приложения будут диктовать производительность TCP, через который будет работать ваше приложение.

Тройное рукопожатие

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

SYN ACK

Сервер выбирает свое собственное случайное число Y, прибавляет 1 к значению Х, добавляет свои флаги и опции и отправляет ответ.

Клиент прибавляет 1 к значениям Х и Y и завершает хэндшейк, отправляя АСК-пакет.

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

TCP Fast Open (TFO)

Загрузка страницы может означать скачивание сотен ее составляющих с разных хостов. Это может потребовать создания браузером десятков новых TCP-соединений, каждое из которых будет давать задержку из-за хэндшейка. Стоит ли говорить, что это может ухудшить скорость загрузки такой страницы, особенно для мобильных пользователей.

Использование TFO требует явной поддержки этого механизма на клиенте, сервере и в приложении. Это работает на сервере с ядром Linux версии 3.7 и выше и с совместимым клиентом (Linux, iOS9 и выше, OSX 10.11 и выше), а также потребуется включить соответствующие флаги сокетов внутри приложения.

Контроль за перегрузкой

Нейгл показал, что коллапс перегрузки не представлял в то время проблемы для ARPANETN, поскольку у узлов была одинаковая ширина каналов, а у бэкбона (высокоскоростной магистрали) была избыточная пропускная способность. Однако это уже давно не так в современном интернете. Еще в 1986 году, когда число узлов в сети превысило 5000, произошла серия коллапсов перегрузки. В некоторых случаях это привело к тому, что скорость работы сети падала в 1000 раз, что означало фактическую неработоспособность.

Контроль потока

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

Рис. 2. Передача значения окна приема.

Масштабирование окна (RFC 1323)

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

В следующей части мы разберемся, что такое TCP Slow Start, как оптимизировать скорость передачи данных и увеличить начальное окно, а также соберем все рекомендации по оптимизации TCP/IP стека воедино.

TCP трехстороннее рукопожатие и четырехстороннее рукопожатие

Прежде всего, мы должны сначала знать несколько состояний TCP (SYN, FIN, ACK, PSH, RST, URG)
На уровне TCP есть поле FLAGS, в котором есть следующие идентификаторы: SYN, FIN, ACK, PSH, RST, URG.
Среди них пять приведенных выше полей полезны для нашего ежедневного анализа.
Их значение таково:
SYNСредства для установления связи,

FINЗначит закрыть соединение,

ACKВыразить ответ,

PSHУказывает, что есть передача данных DATA,

RSTУказывает на сброс соединения.

Среди них, ACK может использоваться одновременно с SYN, FIN и т. Д. Например, SYN и ACK могут быть оба одновременно, он представляет ответ после установления соединения
Если это только один SYN, это означает только установление соединения.
Несколько квитирований TCP выражаются через такой ACK.
Но SYN и FIN не будут оба одновременно, потому что первый означает установление соединения, а второй означает разъединение.

Обычно RST отображается как 1 после FIN, что указывает на сброс соединения.

Обычно, когда появляется пакет FIN или пакет RST, мы думаем, что клиент и сервер отключены, а когда появляются пакеты SYN и SYN + ACK, мы думаем, что клиент и сервер устанавливают соединение.

Установление TCP-соединения и закрытие соединения осуществляются в режиме запрос-ответ.

Концепция дополнения-TCP трехстороннего рукопожатия:

TCP (протокол управления передачей) протокол управления передачей

TCP - это протокол управления передачей уровня хост-хост, который обеспечивает надежные сервисы соединения. Трехстороннее рукопожатие используется для подтверждения установления соединения:

Битовый код является флагом tcp, и существует 6 видов знаков: SYN (синхронное установление соединения) ACK (подтверждение подтверждения) PSH (принудительная передача) FIN (окончание окончания) RST (сброс сброса) URG (экстренная аварийная ситуация) Порядковый номер (порядковый номер) Подтвердить номер

Первое рукопожатие: хост A отправляет битовый код с syn = 1 и случайным образом генерирует на сервер пакет данных с номером seq = 1234567. Хост B знает по SYN = 1 и A запрашивает установление соединения;

Второе рукопожатие: хост B подтверждает информацию в Интернете после получения запроса и отправляет номер подтверждения = (seq + 1 для узла A), syn = 1, ack = 1 и случайным образом генерирует seq = 7654321;

Третье подтверждение: хост A проверяет правильность номера подтверждения после его получения, то есть, seq номер + 1, отправленный в первый раз, и если битовый код подтверждения равен 1, если он верный, хост A отправит номер подтверждения = (хост B seq + 1), ack = 1, после получения хоста B подтверждает, что значение seq и ack = 1, тогда соединение установлено успешно.

После завершения трехстороннего рукопожатия хост A и хост B начинают передавать данные.

Процесс трехстороннего рукопожатия TCP для установления соединения и процесс четырехстороннего рукопожатия для закрытия соединения

Разместите телнет для установления соединения, отключите скриншот пакета, снятый с помощью wireshark.

То же, что SYN. FIN будет занимать серийный номер.
(3) Сервер закрывает соединение с клиентом и отправляет FIN клиенту (сегмент 6).

ЗАКРЫТИЕ: Это состояние особенное. Это должно быть очень редко в реальной ситуации и относится к относительно редкому состоянию исключения.

Когда один конец соединения находится в состоянии TIME_WAIT. Соединение больше не будет использоваться. На самом деле, для нас более реалистично то, что этот порт больше нельзя использовать. Когда порт находится в состоянии TIME_WAIT (фактически это должно быть это соединение), это означает, что соединение TCP не было отключено (полностью отключено). Предполагая, что вы свяжете этот порт, он не сможет. Для сервера, предполагая, что сервер внезапно потерпел крах, он не запустится снова в 2MSL, потому что связывание не удастся. Одним из способов решения этой проблемы является установка опции сокета SO_REUSEADDR. Эта опция означает, что вы можете повторно использовать адрес.

При установлении TCP-соединения. Сервер будет продолжать использовать исходный порт для мониторинга и одновременно использовать этот порт для связи с клиентом.

По умолчанию клиент использует случайный порт для связи с портом прослушивания на стороне сервера.

Иногда для обеспечения безопасности сервера нам необходимо проверять клиента, то есть ограничивать клиент конкретным портом определенного IP.

Клиент может использовать связывание для использования определенного порта.

Для серверной стороны, когда установлена опция SO_REUSEADDR. Его можно запустить в пределах 2MSL и успешно прослушать. Но для клиента. При использовании связывания и установке SO_REUSEADDR предполагается, что он запускается в пределах 2MSL, хотя связывание будет успешным, но на платформе Windows произойдет сбой соединения. Эта проблема не существует в Linux. (Моя экспериментальная платформа: winxp, ubuntu7.10)

Как видите. Несмотря на это, проблема преодолена. Но это не безопасно. Установка состояния SO_LINGER вышеописанным способом эквивалентна установке состояния SO_DONTLINGER.

Похоже, что это можно решить, установив параметр SO_KEEPALIVE, но я не знаю, подходит ли этот параметр для всех платформ.

Почему я не могу использовать два рукопожатия для подключения?
Мы знаем. Трехстороннее рукопожатие выполняет две важные функции. Обе стороны должны подготовиться к отправке данных (обе стороны знают, что они готовы), но также соглашаются с обеими сторонами согласовать начальный порядковый номер, который отправляется и подтверждается в процессе рукопожатия.
Теперь трехстороннее рукопожатие изменено и теперь требует только двустороннего рукопожатия. Возможен тупик.

Как пример. Рассмотрим связь между компьютерами S и C. Предположим, что C отправляет пакет запроса соединения в S. S принимает этот пакет и отправляет пакет подтверждения. В соответствии с соглашением о двустороннем рукопожатии S чувствует, что соединение успешно установлено, и может начать отправку пакетов данных. Однако C не будет знать, готов ли S, если ответный пакет S потерян во время передачи. Я не знаю, какой серийный номер S устанавливает. C даже сомневается, получил ли S свой собственный пакет запроса соединения. В этом случае C чувствует, что соединение не было успешно установлено, и игнорирует любые пакеты данных, отправленные S, и просто ожидает ответный пакет подтверждения соединения. Однако после истечения времени ожидания отправленного пакета S повторно отправляет один и тот же пакет. Это создает тупик.

4. Почему ISN является случайным

DoS-атака

DoS-атака была самой ранней, ее методом атаки была атака один на один. Она была лучше, чем кто-либо другой, по производительности и скорости. Но современные технологии быстро развиваются. В целом хостах сайтов более десятка хостов, и вычислительная мощность, объем памяти и скорость сети каждого хоста быстро развиваются, а некоторые пропускные способности сети даже превышают гигабитные уровни.

Таким образом, наша атака один на один не дает эффекта. Если вы не можете преуспеть, вы умрете.

В качестве примера такого рода атак, если ваша машина может отправлять 10 пакетов атаки в секунду, а машина, на которую вы напали (производительность и пропускная способность сети - на высшем уровне), может получать и обрабатывать 100 пакетов атаки в секунду В этом случае ваша атака будет бесполезной, и есть вероятность сбоя. Вы знаете Если вы отправите эту атаку 1Vs1, загрузка ЦП вашей машины превысит 90%. Если конфигурация вашей машины недостаточно высока, значит вы мертвы.
Тем не менее, технологии развиваются, и хакерские технологии также развиваются. Как говорится, одна нога высокая, а магия высокая.

Эти ответы должны быть обработаны принимающим компьютером, и каждая обработка займет часть системных ресурсов. При условии, что все компьютеры в сети получают ответы одновременно, система получателя может не перегружаться. Это было похоже на нападение со стороны DDoS. Просто никто не настолько глуп, чтобы атаковать себя. Просто такой метод обладает большой силой, будучи улучшенным хакерами.

Объяснение:
SYN: (Синхронизировать порядковые номера) используется для установления соединения. В запросе на соединение SYN = 1 и ACK = 0. Когда соединение отвечает, SYN = 1. ACK = 1. То есть. SYN и ACK, чтобы различать запрос соединения и соединение принято.
RST: (Сбросить соединение) используется для сброса неправильного соединения, вызванного какой-либо причиной, а также для отклонения недопустимых данных и запросов.

Предположим, что при получении бита RST обычно возникают некоторые ошибки.

ACK: (поле подтверждения значимо) Если установлено значение 1, номер подтверждения является допустимым. Когда оно равно 0, это означает, что сегмент данных не включает в себя информацию подтверждения, и номер подтверждения игнорируется.

Предположим, мы готовы установить соединение. Сервер находится в нормальном состоянии ответа.
Шаг 1. Мы, клиент, отправляем запрос с битом SYN на сервер, чтобы указать необходимость подключения. Если порядковый номер пакета запроса равен 10, то: SYN = 10, ACK = 0. Затем дождитесь ответа сервера.
Шаг 2. После получения этого пакета запроса сервер проверяет, отвечает ли указанный порт. Если это не так, он отправляет ответ RST = 1. Отказаться от установления связи. Предполагая, что пакет запроса получен, сервер отправляет ответ с подтверждением. SYN - это внутренний код сервера, который предполагается равным 100. Бит ACK - это номер запроса клиента плюс 1. Данные, отправленные в этом примере: SYN = 100. ACK = 11, ответьте нам с этими данными. Сообщите нам, что соединение с сервером готово, ожидая нашего подтверждения. После того как мы получили ответ в это время. Проанализируйте полученную информацию и подготовьтесь к отправке подтверждающего сигнала подключения на сервер.

То есть: SYN = 11. ACK = 101.

Итак, наша связь установлена.

Как именно DDoS атакует?

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

Просто это не значит, что мы не можем остановить DDoS-атаки. Мы можем сделать все возможное, чтобы уменьшить DDoS-атаки.

Вот несколько способов защиты:
1. Убедитесь, что системный файл сервера имеет номер последней версии. И своевременно обновлять системный патч.
2. Отключите ненужные службы.
3. Ограничить количество открытых половинных соединений SYN одновременно.
4. Сократите время ожидания полусоединения SYN.
5. Правильно настройте брандмауэр
6. Запретить доступ к закрытым сервисам хоста
7. Ограничить доступ к определенным IP-адресам
8. Включите анти-DDoS-свойства брандмауэра
9. Строго ограничьте внешний доступ сервера, открытый для внешнего мира.
10. При выполнении программы сопоставления портов и сканера портов мы должны тщательно проверить привилегированные порты и непривилегированные порты.
11. Внимательно проверьте журналы сетевого оборудования и системы хост / сервер. Пока в журнале есть дыра или изменение времени, машина может быть атакована.
12. Ограничьте общий доступ к сетевым файлам за пределами брандмауэра.

Это даст хакеру возможность перехватывать системные файлы.Хост-информация подвергается хакеру, что, несомненно, дает другой стороне возможность вторжения.

1. Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN.

Сервер получает сегмент, запоминает номер последовательности и пытается создать сокет (буферы и управляющие структуры памяти) для обслуживания нового клиента;

В случае успеха сервер посылает клиенту сегмент с номером последовательности и флагами SYN и ACK, и переходит в состояние SYN-RECEIVED;

2. Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK.

Если он одновременно получает и флаг ACK (что обычно и происходит), то он переходит в состояние ESTABLISHED;

Если клиент получает сегмент с флагом RST, то он прекращает попытки соединиться;

Если клиент не получает ответа в течение 10 секунд, то он повторяет процесс соединения заново.

3. Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED.

В противном случае после тайм-аута он закрывает сокет и переходит в состояние CLOSED.

Читайте также: