Статья является переводом. Оригинал находится
Я думаю, что есть одно предложение, которое вы никогда не захотите услышать как сетевой инженер или админ: "Веб-сайт работает везде, кроме нашей сети, это должно быть проблема фаерволла". Ну, в некоторых случаях это может быть так, а в других - проблема другой сети.
Недавно я решал эту задачу для одного из моих клиентов, заявившего именно о такой проблеме. Некоторые веб-сайты загружались только через другие соединения вне сети, но иногда в их сетях веб-страницы не загружались, либо загрузка была довольно прерывистой; но, в конце концов, стали длиться несколько дней. Ниже я описал, что мне удалось найти, и как я решил эту проблему, а так же обсужу некоторые моменты, связанные с этим вопросом, включая несколько советов по использованию Wireshark.
Предыстория
При устранении неисправностей такого рода с помощью фаерволла, одной из лучших действий, которые вы можете сделать, является настройка захвата пакетов. Иногда вам даже придется настраивать несколько захватов: один - на стороне клиента, другой – на стороне фаерволла, третий - на стороне сервера либо за его пределами. Это позволяет вам наблюдать за трафиком и замечать, например, происходит ли сброс или изменение пакетов по пути. Однако, в моем случае стало совершенно ясно, почему определенные веб-страницы не загружаются после того, как я перехватил пакеты на стороне фаерволла.
Во-первых, при нормальных условиях TCP-соединения устанавливается трехстороннее рукопожатие. Клиент отправит TCP пакет с установленным флагом SYN (Синхронизация). Во-вторых, принимающий сервер отправит свой собственный SYN с установленным флагом ACK (Подтверждение). Это делается для того, чтобы он мог подтвердить предыдущий SYN от клиента. Наконец, во время 3-го шага клиент ответит ACK на SYN, отправленный сервером. После этого два компьютера могут обмениваться любыми данными. Также в течение срока действия TCP соединения есть числа, называемые "порядковыми номерами", которые используются для отслеживания обмена информацией, этот факт прошу запомнить, так как он будет важным в дальнейшем.
Хорошее рукопожатие TCP 3-Way
Просто верно, ты, наверное, слышал это 100 раз. Но что делать, если вы видите, что происходит во время трехстороннего рукопожатия, которое вызывает недоумение? В этом случае захваченные пакеты показывали, что сервер посылал ACK во второй части 3-way handshake без установки флага SYN, что заставляло клиента посылать TCP RST (сброс) и, следовательно, не устанавливать соединение, как должно.
Случай с вызовом ACK
Проблема заключалась в том, что некоторые сайты, размещенные одним провайдером (имена которых я, по разумным причинам, указывать не буду), не могли загружаться или перенаправляться на другую страницу. Оказалось, что многие сайты имеют один и тот же IP, т.е. запросы отправлялись на один и тот же IP-адрес. Я предполагаю, что это связано с каким-то видом прокси или балансировщиком нагрузки, получающим соединения до веб серверов. Другим делом, что некоторые сайты сообщили, что на самом деле нуждаются в перенаправлении, поэтому без установленного TCP соединения HTTP 301 перенаправление никогда не приходит на клиентский компьютер.
Первое, что я проверил, это внутренний и внешним DNS - потому что, знаете, виноват всегда DNS. Проверка прошла успешно. После нескольких попыток в течение 2 дней вебсайты перестали быть доступными, поэтому я начал проверять журналы фаерволла на наличие IP-адреса моей тестовой машины, а затем перехватывал пакеты. Тогда я и заметил, что трехстороннее рукопожатие не завершается.
По сути, я столкнулся с тем, что серверная сторона отправила "Challenge ACK" или Arbitrary ACK response или слепая атака TCP Reset. Это изложено в
Как вы можете заметить на скриншоте ниже, клиент отправлял типичный SYN, однако ответ с сервера содержал только флаг ACK (второй пакет выделен с информацией в нижней панеле), а номер подтверждения даже не соответствовал исходному порядковому номеру SYN. Если вы посмотрите на первый снимок, вы увидите, как порядковый acknowledged number совпадает с тем, что отправил клиент.
Первым пакетом - является клиентский SYN, так же можно заметить, что его порядковый номер 532176398, однако во втором пакете, который является вызовом ACK с сервера, можно увидеть , что порядковый acknowledged number 149490383838, который, кажется, не соответствует потоку. Acknowledged number должен был быть 532176399 с установленным флагом SYN. Затем клиент посылает сброс, соответствующий этому порядковому номеру.
Позже я выяснил, что это правильное поведение в соответствии с RFC:
Также обратите внимание, что wireshark предупреждает о [TCP ACKed unseen segment]. Причина, по которой wireshark показывает это сообщение, заключается в том, что когда прилетел вызов ACK в acknowledgment number, были данные, которые не присутствовали при захвате. Иногда вы увидите, есть ли потеря пакетов, перехватывают ли их, и не перехватили ли вы их.
Кроме того, wireshark любит «окрашивать» определенные пакеты. Как правило, такие проблемы, как невидимый сегмент ACK, ретрансляции, неупорядоченные пакеты и другие сообщения выделяются красным текстом и черными линиями. Это то, на что стоит обратить внимание при сканировании в первый раз.
Назад к нашему брандмауэру. После того, как брандмауэр увидел сброс со стороны клиента, он отметит соединение как завершенное и прервет последующие попытки клиента установить соединение. Следующая диаграмма описывает это более просто:
Из моих исследований видно, что многие механизмы отслеживания сеансов блокируют это. Например, Cisco ASA скорее всего сбросит его из-за "TCP Reset-I", либо сбросит с внутреннего узла, а в моем случае брандмауэр Palo Alto сбросил его из-за "out-of-window-packet-drop (вне-пакететные дропы)". Более того, кажется, что некоторые брандмауэры, выполняющие перехват TCP, могут потенциально пропустить вызов ACK до его передачи клиенту. Пример ниже демонстрирует, что перезагрузка была отправлена непосредственно из-за разрыва соединения до того, как оно было установлено между клиентом и сервером. Это будет зависеть от платформы, конфигурации поставщика и т.д.
Я предполагаю, что эта проблема ACK решалась хостинговой компанией из-за механизма типа DDoS-смягчений для предотвращения чрезмерного количества SYN с одного и того же IP или для проверки законности клиентов, поскольку в случае атаки много исходных адресов были бы подделаны. Я говорил об этом немного в предыдущем посте об "
Альтернативным вариантом может быть то, что, возможно, у сервера заканчиваются доступные TCP сокеты, поэтому он использует клиентские RST для освобождения соединений на повторно используемых портах. Это применимо, если сервер все еще считает соединение активным, он ответит какой порядковый acknowledgment number он ожидает следующим, т.е. в случае NAT вы можете потенциально получить большое количество запросов, приходящих с нескольких IP адресов, если крупное предприятие имеет доступ к тому же сайту/IP или к чему-то подобному.
Я не очень хорошо знаком с балансировкой нагрузки или веб-хостингом, и мое исследование не очень-то помогло в настройке этого механизма. Я видел, как кто-то говорил об этой уязвимости TCP, которая была исправлена в linux около 8 лет назад, и я нашел заплатку Redatch примерно в то же время, поэтому я предполагаю, что некоторые установки оборудования linux будут демонстрировать такое поведение.
Защита
После нескольких звонков от команды, пытавшейся нарастить цепь поддержки, у низ все таки ничего и не вышло - поскольку падения брандмауэра, очевидно, были вызваны ответами TCP сервера; я смог активировать функцию "разрешить вызов ACK" на брандмауэре Palo, чтобы позволить программе понять поведение соединения и завершить соединение. Эта статья в Palo Alto KB (
Мои навыки гуглинга были определенно проверены, пока я искал информацию о RFC и о словах "вызов ACK". Мне удалось подтвердить, что другие люди
Атака
Предупреждением при включении некоторых из этих функций является то, что они могут позволить злоумышленнику, выполняющему атаку sequence number guess (угадывание порядкового номера), проще вставить пакет RST, чтобы разорвать соединение. Для быстро растущих потоков, которые имеют короткую продолжительность, это не является проблемой, но для длительных соединений с известными портами, такими как BGP, это может быть проблемой. MD5 аутентификация всегда рекомендуется с протоколами маршрутизации и является средством устранения этой проблемы в сценарии атаки.
Хотя, угадывание порядкового номера обычно возможно независимо от разрешения вызова ACK или нет. В другой
Проведение и исследование атаки выходило за рамки этой статьи, но, по моему мнению, это было связано с большими затратами на низкое вознаграждение. Например, чтобы точно угадать 4 кортежа, вам нужно будет снифить трафик или выполнять атаку MITM, чтобы получить точную информацию, что требует определенных усилий, плюс вам нужно будет успешно предсказать, какие именно подтверждения вы получили. Мне кажется, что атака starvation или фишинг будет легче и с большей вероятностью даст результаты, в зависимости от того, какая цель, конечно, поставлена.
Очевидно, провайдеры интернет-услуг и различные правительства также использовали похожие методы отправки RST, которые, по сути, представляют собой этот
Советы по wireshark
Что касается wireshark, то для того, чтобы полностью рассмотреть эту проблему, вам необходимо отключить порядковые номера, чтобы вы могли оценить их в истинном виде. В версии для “окон “ это можно найти в меню Edit > Preferences > Protocols > TCP. По умолчанию эта функция включена, что заставляет wireshark показывать порядковые номера, которые более понятны человеку; однако иногда они могут не совпасть, поэтому рекомендуется отключить эту функцию для данного сценария.
Другой совет заключается в создании столбцов для каждого из порядковых номеров. Для этого нажмите на любой тип TCP пакета и откройте его, затем щелкните на нужные данные, затем щелкните правой кнопкой мыши и выберите "Apply as column ". Поэтому в этом случае мы хотели бы создать столбец для порядкового номера, номера подтверждения и последующего порядкового номера. Обычно я всегда запускаю эти столбцы в своих снимках при поиске и устранении различных проблем. Примечание: Вы можете сделать это для многих параметров – просто попробуйте.
При перехвате пакетов на брандмауэре вы, скорее всего, настроите фильтры. Это позволит вам захватить только нужный трафик. Хоть и есть способ сделать это в wireshark, но при съемке на клиентской тачке у вас может не быть такой «роскоши», поэтому быстрый способ найти нужный вам поток, окажется нужным навыком. И так: зайдите во вкладку "Беседы" и отфильтруйте его там. Statistics > Conversations > щелкните на поток, над которым вы хотите производить операции после всплывающего окна > затем щелкните следующий поток.
Примечание: это можно также использовать, чтобы найти самый крупный поток, отсортировав по #, ну или по номеру пакета, по байтам и т.д.
Заключительные примечания
С тем, как сейчас обстоят дела с интернетом, неудивительно, что вы можете столкнуться с чем-то подобным. Понятно, что серверная сторона захотела бы защитить себя от различных атак different transport или иметь механизм для освобождения пространства сокетов в стеке TCP при получении большого количества запросов. Однако если вы используете решение, подобное этому, где проблема ACK явно настроена, либо проблема в что-то вроде балансировщика нагрузки, то, на мой взгляд, у вас должна быть какая-то статья или заметка в вашей системе обслуживания, чтобы ваша служба поддержки могла помочь в определении а также дальнейшему устранению этой проблемы. Также эта статья, может быть полезной для оказания помощи пользователю/клиенту.
Тот факт, что мы никуда не смогли добраться с поддержкой - несколько разочаровывает, так что надеюсь, что операторы смогут добавить дополнительную информацию для этого в будущем, даже если этой уязвимости больше 10 лет. Как я уже говорил, попробуйте погуглить чтобы решить эту проблему, и вы получите неоднозначный результат.
Хотя есть некоторые аргументы в пользу того, чтобы не включать функции, которые допускают нестандартное поведение TCP. Так как атака данного типа проводиться с большим неудобством, по сравнению с некоторыми другими, да и угроза иногда присутствует при включенной либо не включенной функции. Определенно, есть конфигурации, связанные с TCP, которые я бы никогда не включил в интерфейсах с выходом в Интернет, даже с полным state байпассом. В моем случае поведение уже было разрешено, но после обновления брандмауэра до более высокой версии необходимо было включить и настроить новую функцию, чтобы устранить новую проблему. Сначала были некоторые head scratching, но, как вы можете заметить из перехвата пакетов и ссылок, в некоторых случаях можно предугадать «природу» потока.
Хоть первопричина таких странных ошибок была определена, в данном случае остались некоторые вещи, на которые я не получил ответа; однако без дальнейшего ознакомления с сетью поставщиков услуг или помощи со стороны службы поддержки я, скорее всего, не буду копать дальше для анализа. Плюс теперь клиент доволен тем, что может зайти на страницу сайта - еще одно дело в шляпе.
Надеюсь, эта статья поможет вам, если вы столкнетесь с подобными проблемами или чем-то подобным. Если у вас есть какая-либо дополнительная информация о RFC 5961, пожалуйста, поделитесь ею здесь в образовательных целях, а также в Интернете, чтобы улучшить результаты Google.
Спасибо !
Больше материала на эту тему:
Ссылка скрыта от гостей
Я думаю, что есть одно предложение, которое вы никогда не захотите услышать как сетевой инженер или админ: "Веб-сайт работает везде, кроме нашей сети, это должно быть проблема фаерволла". Ну, в некоторых случаях это может быть так, а в других - проблема другой сети.
Недавно я решал эту задачу для одного из моих клиентов, заявившего именно о такой проблеме. Некоторые веб-сайты загружались только через другие соединения вне сети, но иногда в их сетях веб-страницы не загружались, либо загрузка была довольно прерывистой; но, в конце концов, стали длиться несколько дней. Ниже я описал, что мне удалось найти, и как я решил эту проблему, а так же обсужу некоторые моменты, связанные с этим вопросом, включая несколько советов по использованию Wireshark.
Предыстория
При устранении неисправностей такого рода с помощью фаерволла, одной из лучших действий, которые вы можете сделать, является настройка захвата пакетов. Иногда вам даже придется настраивать несколько захватов: один - на стороне клиента, другой – на стороне фаерволла, третий - на стороне сервера либо за его пределами. Это позволяет вам наблюдать за трафиком и замечать, например, происходит ли сброс или изменение пакетов по пути. Однако, в моем случае стало совершенно ясно, почему определенные веб-страницы не загружаются после того, как я перехватил пакеты на стороне фаерволла.
Во-первых, при нормальных условиях TCP-соединения устанавливается трехстороннее рукопожатие. Клиент отправит TCP пакет с установленным флагом SYN (Синхронизация). Во-вторых, принимающий сервер отправит свой собственный SYN с установленным флагом ACK (Подтверждение). Это делается для того, чтобы он мог подтвердить предыдущий SYN от клиента. Наконец, во время 3-го шага клиент ответит ACK на SYN, отправленный сервером. После этого два компьютера могут обмениваться любыми данными. Также в течение срока действия TCP соединения есть числа, называемые "порядковыми номерами", которые используются для отслеживания обмена информацией, этот факт прошу запомнить, так как он будет важным в дальнейшем.
Хорошее рукопожатие TCP 3-Way
Просто верно, ты, наверное, слышал это 100 раз. Но что делать, если вы видите, что происходит во время трехстороннего рукопожатия, которое вызывает недоумение? В этом случае захваченные пакеты показывали, что сервер посылал ACK во второй части 3-way handshake без установки флага SYN, что заставляло клиента посылать TCP RST (сброс) и, следовательно, не устанавливать соединение, как должно.
Случай с вызовом ACK
Проблема заключалась в том, что некоторые сайты, размещенные одним провайдером (имена которых я, по разумным причинам, указывать не буду), не могли загружаться или перенаправляться на другую страницу. Оказалось, что многие сайты имеют один и тот же IP, т.е. запросы отправлялись на один и тот же IP-адрес. Я предполагаю, что это связано с каким-то видом прокси или балансировщиком нагрузки, получающим соединения до веб серверов. Другим делом, что некоторые сайты сообщили, что на самом деле нуждаются в перенаправлении, поэтому без установленного TCP соединения HTTP 301 перенаправление никогда не приходит на клиентский компьютер.
Первое, что я проверил, это внутренний и внешним DNS - потому что, знаете, виноват всегда DNS. Проверка прошла успешно. После нескольких попыток в течение 2 дней вебсайты перестали быть доступными, поэтому я начал проверять журналы фаерволла на наличие IP-адреса моей тестовой машины, а затем перехватывал пакеты. Тогда я и заметил, что трехстороннее рукопожатие не завершается.
По сути, я столкнулся с тем, что серверная сторона отправила "Challenge ACK" или Arbitrary ACK response или слепая атака TCP Reset. Это изложено в
Ссылка скрыта от гостей
.Как вы можете заметить на скриншоте ниже, клиент отправлял типичный SYN, однако ответ с сервера содержал только флаг ACK (второй пакет выделен с информацией в нижней панеле), а номер подтверждения даже не соответствовал исходному порядковому номеру SYN. Если вы посмотрите на первый снимок, вы увидите, как порядковый acknowledged number совпадает с тем, что отправил клиент.
Первым пакетом - является клиентский SYN, так же можно заметить, что его порядковый номер 532176398, однако во втором пакете, который является вызовом ACK с сервера, можно увидеть , что порядковый acknowledged number 149490383838, который, кажется, не соответствует потоку. Acknowledged number должен был быть 532176399 с установленным флагом SYN. Затем клиент посылает сброс, соответствующий этому порядковому номеру.
Позже я выяснил, что это правильное поведение в соответствии с RFC:
Когда клиент посылает сброс, часто он закрывает то соединение на сервере, которое может быть открыто из предыдущего потока с теми же параметрами. Поэтому, когда клиент повторно передает и пытается открыть соединение, сервер отвечает ожидаемым SYN/ACK.
Также обратите внимание, что wireshark предупреждает о [TCP ACKed unseen segment]. Причина, по которой wireshark показывает это сообщение, заключается в том, что когда прилетел вызов ACK в acknowledgment number, были данные, которые не присутствовали при захвате. Иногда вы увидите, есть ли потеря пакетов, перехватывают ли их, и не перехватили ли вы их.
Кроме того, wireshark любит «окрашивать» определенные пакеты. Как правило, такие проблемы, как невидимый сегмент ACK, ретрансляции, неупорядоченные пакеты и другие сообщения выделяются красным текстом и черными линиями. Это то, на что стоит обратить внимание при сканировании в первый раз.
Назад к нашему брандмауэру. После того, как брандмауэр увидел сброс со стороны клиента, он отметит соединение как завершенное и прервет последующие попытки клиента установить соединение. Следующая диаграмма описывает это более просто:
Из моих исследований видно, что многие механизмы отслеживания сеансов блокируют это. Например, Cisco ASA скорее всего сбросит его из-за "TCP Reset-I", либо сбросит с внутреннего узла, а в моем случае брандмауэр Palo Alto сбросил его из-за "out-of-window-packet-drop (вне-пакететные дропы)". Более того, кажется, что некоторые брандмауэры, выполняющие перехват TCP, могут потенциально пропустить вызов ACK до его передачи клиенту. Пример ниже демонстрирует, что перезагрузка была отправлена непосредственно из-за разрыва соединения до того, как оно было установлено между клиентом и сервером. Это будет зависеть от платформы, конфигурации поставщика и т.д.
Я предполагаю, что эта проблема ACK решалась хостинговой компанией из-за механизма типа DDoS-смягчений для предотвращения чрезмерного количества SYN с одного и того же IP или для проверки законности клиентов, поскольку в случае атаки много исходных адресов были бы подделаны. Я говорил об этом немного в предыдущем посте об "
Ссылка скрыта от гостей
".Альтернативным вариантом может быть то, что, возможно, у сервера заканчиваются доступные TCP сокеты, поэтому он использует клиентские RST для освобождения соединений на повторно используемых портах. Это применимо, если сервер все еще считает соединение активным, он ответит какой порядковый acknowledgment number он ожидает следующим, т.е. в случае NAT вы можете потенциально получить большое количество запросов, приходящих с нескольких IP адресов, если крупное предприятие имеет доступ к тому же сайту/IP или к чему-то подобному.
Я не очень хорошо знаком с балансировкой нагрузки или веб-хостингом, и мое исследование не очень-то помогло в настройке этого механизма. Я видел, как кто-то говорил об этой уязвимости TCP, которая была исправлена в linux около 8 лет назад, и я нашел заплатку Redatch примерно в то же время, поэтому я предполагаю, что некоторые установки оборудования linux будут демонстрировать такое поведение.
Защита
После нескольких звонков от команды, пытавшейся нарастить цепь поддержки, у низ все таки ничего и не вышло - поскольку падения брандмауэра, очевидно, были вызваны ответами TCP сервера; я смог активировать функцию "разрешить вызов ACK" на брандмауэре Palo, чтобы позволить программе понять поведение соединения и завершить соединение. Эта статья в Palo Alto KB (
Ссылка скрыта от гостей
) подводит меня к резолюции. Благословите документацию продавца! Начиная с версии Pan OS 8.0.7 и выше, вам нужно включить эту функцию, прежде чем она была разрешена автоматически. Этот тип изменений следует иметь в виду при обновлении до более новых версий программного обеспечения. Но, конечно, если это действительно есть в примечаниях к статье.Мои навыки гуглинга были определенно проверены, пока я искал информацию о RFC и о словах "вызов ACK". Мне удалось подтвердить, что другие люди
Ссылка скрыта от гостей
в прошлом, хотя в ответах, возможно, указывалось на то, что корнем всех бед было нечто иное. В поисках других исправлений, если бы у меня был другой производитель брандмауэра, я обнаружил, что Checkpoint имел функцию под названием
Ссылка скрыта от гостей
, которая выглядела многообещающе. Еще одно исправление, касающееся ASA, было найдено в
Ссылка скрыта от гостей
по настройке TCP нормализации и оказалось, что может быть "разрешить недействительный ACK", но я не подтвердил это.Атака
Предупреждением при включении некоторых из этих функций является то, что они могут позволить злоумышленнику, выполняющему атаку sequence number guess (угадывание порядкового номера), проще вставить пакет RST, чтобы разорвать соединение. Для быстро растущих потоков, которые имеют короткую продолжительность, это не является проблемой, но для длительных соединений с известными портами, такими как BGP, это может быть проблемой. MD5 аутентификация всегда рекомендуется с протоколами маршрутизации и является средством устранения этой проблемы в сценарии атаки.
Хотя, угадывание порядкового номера обычно возможно независимо от разрешения вызова ACK или нет. В другой
Ссылка скрыта от гостей
говорилось, что эти элементы необходимы для осуществления атаки:Тем не менее, некоторые исправления, предложенные (наряду с результатами поиска), заключались в том, чтобы разрешить TCP не-SYN байпас, также известный как TCP-state байпасс, или разрешить соединение без полного просмотра 3-полосного рукопожатия, чтобы установить. Обычно это рекомендуется для сценариев, где асимметричная маршрутизация выполняется с несколькими брандмауэрами и/или путями, но если у вас нет таких проблем, я бы не рекомендовал включать эту функцию, если только это необходимо из-за проблем безопасности, связанных с разрешением несанкционированных соединений. (В режиме Palo эта конфигурация отображается в профиле защиты зоны).
Проведение и исследование атаки выходило за рамки этой статьи, но, по моему мнению, это было связано с большими затратами на низкое вознаграждение. Например, чтобы точно угадать 4 кортежа, вам нужно будет снифить трафик или выполнять атаку MITM, чтобы получить точную информацию, что требует определенных усилий, плюс вам нужно будет успешно предсказать, какие именно подтверждения вы получили. Мне кажется, что атака starvation или фишинг будет легче и с большей вероятностью даст результаты, в зависимости от того, какая цель, конечно, поставлена.
Очевидно, провайдеры интернет-услуг и различные правительства также использовали похожие методы отправки RST, которые, по сути, представляют собой этот
Ссылка скрыта от гостей
. Это то, о чем следует помнить при возникновении проблем со связью в международном масштабе.Советы по wireshark
Что касается wireshark, то для того, чтобы полностью рассмотреть эту проблему, вам необходимо отключить порядковые номера, чтобы вы могли оценить их в истинном виде. В версии для “окон “ это можно найти в меню Edit > Preferences > Protocols > TCP. По умолчанию эта функция включена, что заставляет wireshark показывать порядковые номера, которые более понятны человеку; однако иногда они могут не совпасть, поэтому рекомендуется отключить эту функцию для данного сценария.
Другой совет заключается в создании столбцов для каждого из порядковых номеров. Для этого нажмите на любой тип TCP пакета и откройте его, затем щелкните на нужные данные, затем щелкните правой кнопкой мыши и выберите "Apply as column ". Поэтому в этом случае мы хотели бы создать столбец для порядкового номера, номера подтверждения и последующего порядкового номера. Обычно я всегда запускаю эти столбцы в своих снимках при поиске и устранении различных проблем. Примечание: Вы можете сделать это для многих параметров – просто попробуйте.
При перехвате пакетов на брандмауэре вы, скорее всего, настроите фильтры. Это позволит вам захватить только нужный трафик. Хоть и есть способ сделать это в wireshark, но при съемке на клиентской тачке у вас может не быть такой «роскоши», поэтому быстрый способ найти нужный вам поток, окажется нужным навыком. И так: зайдите во вкладку "Беседы" и отфильтруйте его там. Statistics > Conversations > щелкните на поток, над которым вы хотите производить операции после всплывающего окна > затем щелкните следующий поток.
Примечание: это можно также использовать, чтобы найти самый крупный поток, отсортировав по #, ну или по номеру пакета, по байтам и т.д.
Заключительные примечания
С тем, как сейчас обстоят дела с интернетом, неудивительно, что вы можете столкнуться с чем-то подобным. Понятно, что серверная сторона захотела бы защитить себя от различных атак different transport или иметь механизм для освобождения пространства сокетов в стеке TCP при получении большого количества запросов. Однако если вы используете решение, подобное этому, где проблема ACK явно настроена, либо проблема в что-то вроде балансировщика нагрузки, то, на мой взгляд, у вас должна быть какая-то статья или заметка в вашей системе обслуживания, чтобы ваша служба поддержки могла помочь в определении а также дальнейшему устранению этой проблемы. Также эта статья, может быть полезной для оказания помощи пользователю/клиенту.
Тот факт, что мы никуда не смогли добраться с поддержкой - несколько разочаровывает, так что надеюсь, что операторы смогут добавить дополнительную информацию для этого в будущем, даже если этой уязвимости больше 10 лет. Как я уже говорил, попробуйте погуглить чтобы решить эту проблему, и вы получите неоднозначный результат.
Хотя есть некоторые аргументы в пользу того, чтобы не включать функции, которые допускают нестандартное поведение TCP. Так как атака данного типа проводиться с большим неудобством, по сравнению с некоторыми другими, да и угроза иногда присутствует при включенной либо не включенной функции. Определенно, есть конфигурации, связанные с TCP, которые я бы никогда не включил в интерфейсах с выходом в Интернет, даже с полным state байпассом. В моем случае поведение уже было разрешено, но после обновления брандмауэра до более высокой версии необходимо было включить и настроить новую функцию, чтобы устранить новую проблему. Сначала были некоторые head scratching, но, как вы можете заметить из перехвата пакетов и ссылок, в некоторых случаях можно предугадать «природу» потока.
Хоть первопричина таких странных ошибок была определена, в данном случае остались некоторые вещи, на которые я не получил ответа; однако без дальнейшего ознакомления с сетью поставщиков услуг или помощи со стороны службы поддержки я, скорее всего, не буду копать дальше для анализа. Плюс теперь клиент доволен тем, что может зайти на страницу сайта - еще одно дело в шляпе.
Надеюсь, эта статья поможет вам, если вы столкнетесь с подобными проблемами или чем-то подобным. Если у вас есть какая-либо дополнительная информация о RFC 5961, пожалуйста, поделитесь ею здесь в образовательных целях, а также в Интернете, чтобы улучшить результаты Google.
Спасибо !
Больше материала на эту тему:
-
Ссылка скрыта от гостей
-
Ссылка скрыта от гостей
-
Ссылка скрыта от гостей
-
Ссылка скрыта от гостей
