Tcp split handshake что это

Распространенные файрволы содержат уязвимости, позволяющие вторжение в сеть

Linux для хакера

Некоторые из наиболее распространенных брандмауэров подвержены уязвимостям,
которые дают атакующим возможность обмануть файрвол и пробраться во внутреннюю
сеть на основе доверенного IP-соединения.

В NSS Labs недавно протестировали полдюжины сетевых брандмауэров для того,
чтобы выявить слабые места в системах безопасности и выяснили, что все, кроме
одного из них, являются уязвимыми для типа атаки, которая называется «TCP Split
Handshake Attack», которая позволяет хакеру, находясь на расстоянии, обманывать
брандмауэр и заставлять его считать, что то или иное IP-соединение является
доверенным.

На этой неделе
NSS Labs
опубликовала документ об исследовании «Network
Firewall 2011 Comparative Test Results», содержащий его результаты. NSS Labs
– хорошо известная организация, занимающаяся тестированием продуктов,
оценивающая широкий спектр систем безопасности, проводящая как спонсируемые
производителями сравнительные тесты, так и совершенно независимые тесты по
собственной инициативе. Network Firewall 2011 Comparative Test, опубликованный
на этой неделе, принадлежит к независимой группе тестов, поэтому NSS Labs взяла
все расходы на себя.

NSS Labs провели независимые тесты Check Point Power-1 11065, Cisco ASA
5585-40, Fortinet Fortigate 3950, Juniper SRX 5800, Palo Alto Networks PA-4020 и
SonicWall NSA E8500.

Мой отметил, что производители неохотно принимают участие в тестах, которые
проводит NSS Labs и что на самом деле около половины файрволов были
предоставлены конечными пользователями, такими, например, как фирмы,
занимающиеся предоставлением финансовых услуг, которые поддержали тест, потому
что хотели узнать о возможных уязвимостях в используемых ими брандмауэрах.

В докладе NSS Labs сказано: «Пять из шести продуктов позволили удаленным
атакующим обойти брандмауэр и стать внутренним доверенным компьютером».
Единственный брандмауэр из протестированных NSS Labs, который не позволил этого
сделать, был Check Point.

Производители, чье оборудование не прошло тест «TCP Split Handshake»,
находятся на различных стадиях исправления проблемы, указывает доклад.

Говорят, что Cisco в настоящее время работает с NSS Labs над этим делом и
«рекомендации будут предоставлены как только они будут готовы».

«По умолчанию, Juniper не задействует защиту от TCP Split Handshake attack»,
но NSS labs рекомендует, чтобы клиенты Juniper изучили конфигурации своих
файрволов и следовали рекомендациям, представленным в докладе. Эксперты NSS Labs
предупреждают, что «защита может негативно повлиять на производительность и/или
привести к сбоям в работе приложений, которые не используют TCP должным
образом».

Доклад NSS Labs также включает анализ цен всего протестированного
программного обеспечения, а также количество средств, необходимых для
пользования им.

Источник

Внутренние механизмы ТСР, влияющие на скорость загрузки: часть 1

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

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

Протоколы TCP/IP были предложены Винтом Серфом и Бобом Каном в статье «Протокол связи для сети на основе пакетов», опубликованной в 1974 году. Исходное предложение, зарегистрированное как RFC 675, было несколько раз отредактировано и в 1981 году 4-я версия спецификации TCP/IP была опубликована как два разных RFC:

TCP обеспечивает нужную абстракцию сетевых соединений, чтобы приложениям не пришлось решать различные связанные с этим задачи, такие как: повторная передача потерянных данных, доставка данных в определенном порядке, целостность данных и тому подобное. Когда вы работаете с потоком TCP, вы знаете, что отправленные байты будут идентичны полученным, и что они придут в одинаковом порядке. Можно сказать, что TCP больше «заточен» на корректность доставки данных, а не на скорость. Этот факт создает ряд проблем, когда дело доходит до оптимизации производительности сайтов.

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

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

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

Все TCP-соединения начинаются с тройного рукопожатия (рис. 1). До того как клиент и сервер могут обменяться любыми данными приложения, они должны «договориться» о начальном числе последовательности пакетов, а также о ряде других переменных, связанных с этим соединением. Числа последовательностей выбираются случайно на обоих сторонах ради безопасности.

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

SYN ACK

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

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

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

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

Например, если клиент в Нью-Йорке, сервер – в Лондоне, и мы создаем новое TCP-соединение, это займет 56 миллисекунд. 28 миллисекунд, чтобы пакет прошел в одном направлении и столько же, чтобы вернуться в Нью-Йорк. Ширина канала не играет здесь никакой роли. Создание TCP-соединений оказывается «дорогим удовольствием», поэтому повторное использование соединений является важной возможностью оптимизации любых приложений, работающих по TCP.

TCP Fast Open (TFO)

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

TCP Fast Open (TFO) – это механизм, который позволяет снизить задержку за счет того, что позволяет отправку данных внутри SYN-пакета. Однако и у него есть свои ограничения: в частности, на максимальный размер данных внутри SYN-пакета. Кроме того, только некоторые типы HTTP-запросов могут использовать TFO, и это работает только для повторных соединений, поскольку использует cookie-файл.

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

Специалисты компании Google определили, что TFO может снизить сетевую задержку при HTTP-запросах на 15%, ускорить загрузку страниц на 10% в среднем и в отдельных случаях – до 40%.

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

В начале 1984 года Джон Нейгл описал состояние сети, названное им как «коллапс перегрузки», которое может сформироваться в любой сети, где ширина каналов между узлами неодинакова.

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

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

Чтобы справиться с этой проблемой, в TCP были применены несколько механизмов: контроль потока, контроль перегрузки, предотвращение перегрузки. Они определяли скорость, с которой данные могут передаваться в обоих направлениях.

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

Контроль потока предотвращает отправку слишком большого количества данных получателю, которые он не сможет обработать. Чтобы этого не происходило, каждая сторона TCP-соединения сообщает размер доступного места в буфере для поступающих данных. Этот параметр — «окно приема» (receive window – rwnd).

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

Если по каким-то причинам одна сторона не может справиться с поступающим потоком данных, она должна сообщить уменьшенное значение своего окна приема. Если окно приема достигает значения 0, это служит сигналом отправителю, что не нужно более отправлять данные, пока буфер получателя не будет очищен на уровне приложения. Эта последовательность повторяется постоянно в каждом TCP-соединении: каждый АСК-пакет несет в себе свежее значение rwnd для обеих сторон, позволяя им динамически корректировать скорость потока данных в соответствии с возможностями получателя и отправителя.

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

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

Исходная спецификация TCP ограничивала 16-ю битами размер передаваемого значения окна приема. Это серьезно ограничило его сверху, поскольку окно приема не могло быть более 2^16 или 65 535 байт. Оказалось, что это зачастую недостаточно для оптимальной производительности, особенно в сетях с большим «произведением ширины канала на задержку» (BDP – bandwidth-delay product).

Чтобы справиться с этой проблемой в RFC 1323 была введена опция масштабирования TCP-окна, которая позволяла увеличить размер окна приема с 65 535 байт до 1 гигабайта. Параметр масштабирования окна передается при тройном рукопожатии и представляет количество бит для сдвига влево 16-битного размера окна приема в следующих АСК-пакетах.

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

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

Источник

Tcp split handshake что это

Last Updated on October 1, 2018

Few days ago, independent security research and testing NSS Labs, issued a comparative report among six network security technologies. The controversial results created a comprehensible turmoil among the security vendors involved in the tests, and more in general inside the infosec landscape. As a matter of fact it turned out that that five of the six tested platforms were susceptible to TCP Split handshake attack.

As a security professional, I am pretty much involved with at least five of the six tested technologies, consequently, although I never heard about TCP Split Handshake before, I must confess I was really curious to learn which was the only platform capable of surviving the test (the answer is indirectly provided by the vendor – Checkpoint – missing from the list contained on the remediation report subsequently released). Fortunately the scientific side of me took over and instead of making judgments and drawing conclusions about the results, I decided to learn more about TCP Split Handshake and the reasons why a security equipment may be vulnerable.

TCP Split Handshake in RFC 793

Since TCP is a connection-oriented protocol, every connection begins with a “handshake” defined in RFC 793. The handshake defines three well defined steps and for this reason it is called “TCP Three Way Handshake.”

The host initiating the connection, referred as the client, send to its peer, referred as the server, a synchronization packet, or SYN. In order to correctly identify the beginning (and the subsequent “state” of the session, the SYN packet contains an initial Sequence Number (ISN) which corresponds to a pseudo-random number.

Upon reception of the SYN packet, the server acknowledges that, and generates its own SYN. This “SYN/ACK” packet contains both the server’s Initial Sequence Number, as well as an acknowledgment number equal to the client’s Sequence Number plus 1. The fact that the server sends a single packet to initiate the connection on its side and to acknowledge the initial SYN sent from the client is known as piggy-backing and, as explained later, is the fundamental aspect in which TCP Split Handshake differs from Three Way Handshake.

At this point, in order to establish the session, the client concludes the Three Way Handshake and acknowledges the server’s SYN/ACK, sending a packet with its own ISN incremented by one, as well as its acknowledgement number equal to the server’s ISN plus 1.

As mentioned above, in the second phase of the handshake, the piggy-backing allows the server to use a single packet to send its own SYN and to acknowledge the SYN packet received from the client (ACK). However, let us assume that the server could decide to split the second phase of the handshake and send a dedicated ACK packet to acknowledge the client SYN, and a further dedicated packet with its own SYN. This is exactly what is stated at section 3.3, page 27, of RFC 793, which introduces an intriguing four-step process:

As a consequence, one might expect that an RFC 793 perfectly compliant client be capable to silently accept packet two, explicitly ACK packet 3, and hence complete the handshake more-or-less normally. At least in theory…

In reality, in such similar circumstances, NSS test have shown that some network security devices, with the sole firewall function enabled, get confused and behaves in a stateless manner. In few words, if even the client behaves as stated in the RFC, that is it is able to correctly establish the session even if it accepts separated ACK and SYN packets from the server, the network security device, on receiving the SYN from the server (packet 2), loses the awareness of the session and lets the traffic flow without enforcing any security control as if it belongs to an uncontrolled session (in theory an unknown or out-of-state session should be blocked). This means that a malicious payload conveyed through a TCP Split Handshake intiated session could go through the firewall and as a consequence, an attack scenario is quite straightforward: an attacker could think to use a server-side malicious script to establish the session by mean of a TCP Split Handshake and consequently install an executable on the client (a very fashionable event in the last days), for instance, by mean of an ActiveX Buffer Overflow on the target client browser.

The bad news is that this kind of attack is not new, and a similar attack scenario was reported for the first time approximately one year ago (with different behaviours reported for clients and security devices). The strange side of the story relies on the fact that this behaviour may not be considered a real vulnerability, but rather an occurrence covered by RFC not correctly implemented or not enabled on the default configuration by security vendors (please consider that RFC 793 also includes a further method for establishing a TCP connection dubbed “TCP Simultaneous Open” in which two TCP hosts simultaneously attempt to open a connection to each other via a SYN packet).

Last but not least…

For the record, as previously stated, NSS Labs released a remediation report containing the indications needed to mitigate (where necessary) the occurrence of the TCP Split Handshake for the affected technologies. Moreover two vendors (Cisco and Fortinet) added some indications as reported in the following:

Источник

Многие аппаратные межсетевые экраны не защищают от атак с использованием TCP Split Handshake

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

Хотя возможность обхода некоторых систем обнаружения вторжения и правил межсетевых экранов с помощью так называемого TCP Split Handshake была найдена и опубликована больше года назад, многие из широко используемых аппаратных межсетевых экранов все еще неспособны распознать и блокировать ее. Такой вывод делают специалисты NSS Labs, протестировавшие шесть аппаратных межсетевых экранов разных производителей: Check Point Power-1 11065, Cisco ASA 5585, Fortinet Fortigate 3950, Juniper SRX 5800, Palo Alto Networks PA-4020, и SonicWall NSA E8500. В экспериментах NSS Labs только экран Check Point смог предотвратить установление соединения посредством TCP Split Handshake.

Атака с использованием TCP Split Handshake осуществляется со стороны сервера, который при установке соединения посылает клиенту нетрадиционным образом сконфигурированные пакеты TCP. В результате межсетевой экран может «не заметить», что клиент общается с сервером, расположенным за пределами локальной сети.

Не все производители согласны с выводами NSS Labs. В Fortinet и SonicWall утверждают, что их межсетевые экраны при правильной настройке защищают от TCP Split Handshake.

Поделитесь материалом с коллегами и друзьями

Источник

What is the TCP Split-Handshake Attack and Does It Affect Me?

If you’ve followed security news over the past few days, you’ve probably seen a lot of hoopla about a TCP split-handshake vulnerability that can affect firewalls and other networking and security devices. Many of the Media’s articles characterize this complicated TCP connection attack as, “a hacker exploit that lets an attacker trick a firewall and get into an internal network as a trusted IP connection” or as a “hole” in firewalls. I’m not sure that these descriptions properly characterize this vulnerability, and I suspect many administrators may not really understand how this attack works (let alone what it does and doesn’t allow an attacker to accomplish). I hope to try and rectify that in this post.

Before I jump into a description of this attack, WatchGuard XTM owners probably want to know if they are vulnerable to this attack. The answers is, No. Our XTM appliances do not allow TCP split-handshake connections. Furthermore, we also enable a feature called TCP SYN checking by default on our devices, which further protects against TCP state-based attacks. Later in this post, I’ll go into more detail on how we tested this, but for now, know that our appliances are not susceptible to this attack. With that out of the way, let’s look at this attack.

What is the TCP Split-Handshake Attack?

To understand the TCP split-handshake attack you need to understand how network devices build TCP connections. I’m going to assume you are familiar with the TCP three-way handshake. If not, this guide will walk you through it. Most network administrator understand this three-way handshake technique quite well, and many gateway security devices (like stateful firewalls) are designed to enforce it. However, less people know about another legitimate way to build TCP connections, called the simultaneous-open handshake. With a simultaneous open connection, both a client and server send a SYN packet to each other at about the same time. Then both sides also send ACK packets to each other in response. This slightly different variant of the TCP handshake doesn’t happen much in the real world, however, it’s a perfectly legitimate way to start a TCP connection (according to RFC 793).

This brings us to the TCP split-handshake (also sometimes called a Sneak ACK attack). As the name suggests, the split-handshake combines aspects of the normal three-way handshake with the simultaneous-open handshake. Essentially, a client sends a SYN packet to a server, intending to complete a normal three-way handshake. However, rather than completing the client’s three-way handshake, a malicious server starts by replying as though it were doing a simultaneous-open connection, and then starts its own three-way handshake in the other direction — from server to client. So in essence, even though the client started the connection to the server, the logical direction of this connection gets reversed.

This is a fairly quick and high-level description of this attack. If you are a technically oriented person that wants to know the nitty-gritty details, I highly recommend you read, The TCP Split Handshake: Practical Effects on Modern Network Equipment. It is the defacto document describing this attack. If you just want the highlights, I also recommend this article. It characterizes the attack well, without diving too deep into the technical detail.

So What Can an Attacker Accomplish with this Attack?

OK. At a high-level, you now know that the TCP split-handshake attack is a sneaky way that a malicious server can reverse the logical direction of a connection that a client initiates. But what exactly does that mean? What can an attacker do with that, and how bad is it?

First, you should know that this attack cannot punch holes in your firewall, willy-nilly, without user interaction. A key mitigating factor to the attack is that a client within your network must first make a connection to a malicious server on the internet, before this attack can even start. Some of the descriptions of the attack, which claim an external attacker can trick a firewall into giving them access as a trusted IP, seem to leave this fact out. So if you were worried that external attackers can just hop through your firewall on their own, don’t be.

Furthermore, when this attack succeeds, the attacker isn’t even getting free reign on the victim computer or your network either, instead the attacker has only reversed the logical direction of your client’s initial connection. This could be bad, as I will explain in a second, but it is not immediate full access to the victim computer or your network.

What this attack really comes down to is an IPS (or other security content-filtering) evasion attack. The key issue is this attack logically reverses the direction of a perfectly legitimate connection your client initiated. This doesn’t really mean the attacker can do anything new on the victim computer, but it may confuse gateway security scanning services that protect your client. Many security systems, like IPS, antivirus (AV), and other content-filtering systems rely on the direction of traffic to decide how to scan it, or even if they will scan it. If an attacker can confuse the gateway devices as to the direction of traffic, it may be able to evade security scanning or IPS policies.

Let’s look at a real world example. Say an unpatched client in your network connects to a malicious drive-by download web server that is not leveraging the split-handshake attack. The malicious web site tries to get your client to execute some javascript that forces your client to download malware. If you have gateway IPS and AV, your IPS may detect the malicious javascript, or your AV may catch the malware. In either case, your security scanning would block the attack.

However, if the malicious web server adds the TCP split-handshake connection to the same attack, your IPS and AV systems may be confused by the direction of the traffic, and not scan the web server’s content. Now the malicious drive-by download would succeed, despite your gateway security protection.

So to summarize, the TCP split-handshake attack may help malicious servers to bypass security scanning services on your gateway security devices. However, it will not allow external attackers to bypass your firewall policies, and it requires an internal client start the connection in the first place.

Is My X-brand Network Device at Risk?

Now you know the true impact of TCP split-handshake attacks. They don’t allow attackers to totally bypass firewalls without user interaction, but they could help attackers evade your security services, assuming your clients connect to them. The next question is, are my network devices vulnerable?

To help you answer that question, I’m going to share how I tested WatchGuard’s XTM appliances.

The authors of the paper I mentioned earlier (The TCP Split Handshake: Practical Effects on Modern Network Equipment) included a special Ruby script in their paper called fakestack.rb. This script sets up a server on port 8080, that listens for incoming connections, and replies to those connection using the TCP split-handshake connection method. If this malicious connection succeeds, the script reports, “The handshake’s a LIE!” You can use this script to test your network equipment, and see whether or not it allows TCP split-handshake connections to complete.

I recommend you use fakestack.rb with a Linux computer. I used my Backtrack 4 installation. Fakestack.rb requires another ruby script called PacketFu, which in turn requires something called PcapRub. The whitepaper above explains these dependencies. Once your have all this installed, you simply have to disable your computer’s local host firewall (on 8080 at least), and run fakestack.rb (sudo fakestack.rb eth0 8080).

Once you have fakestack running, I recommend you first get a client to connect to it directly, without any firewall or gateway device in the mix. This way you can see what happens when the split-handshake connection succeeds. Open a web browser (IE or Firefox) on a Windows computer that is on the same network, and try to connect to the IP of the computer running fakestack, on port 8080 (http://x.x.x.x:8080). You will not see anything in the web browser. However, if you look at fakestack’s output, you will see it generating packets, sending certain replies, and if the attack works, it returns that “handshake’s a lie” message.

Once you have fakestack working, testing your own network gear is simple. Simply put the fakestack computer on the external side of your firewall, IPS, or security appliance, and get an internal client to try to connect to fakestack. If fakestack returns the handshake is a lie message, then you know your security gear may be vulnerable to this attack. However, if you don’t get the handshake is a lie message, fakestack wasn’t able to complete the split-handshake connection, and your device must be doing something to prevent it.

This is the test I did with our XTM appliances. When a client behind an XTM appliance tries to connect to fakestack, the connection never completes. Meanwhile, the XTM logs report:

Our packet handling engine does not recognize split-handshake connections as legitimate connections. Furthermore, split-handshakes trigger our TCP syn checking feature too, which is enabled by default.

This test shows that WatchGuard devices don’t allow split-handshake connections. You can use the same test to figure out whether or not your other network security devices handle TCP split-handshake connections properly.

Summary

I hope this post helped clear up some potential misinterpretations about this complex vulnerability, and has shown you its true severity and impact. Feel free to share your thoughts and ideas about this flaw in the comments section. I find it quite interesting and would love to discuss it. — Corey Nachreiner, CISSP. (@SecAdept)

Источник