TCP Window Size Scaling

TCP (Transmission Control Protocol) is a connection oriented protocol which means that we keep track of how much data has been transmitted. The sender will transmit some data and the receiver has to acknowledge it. When we don’t receive the acknowledgment in time then the sender will re-transmit the data.

TCP uses “windowing” which means that a sender will send one or more data segments and the receiver will acknowledge one or all segments. When we start a TCP connection, the hosts will use a receive buffer where we temporarily store data before the application can process it.

When the receiver sends an acknowledgment, it will tell the sender how much data it can transmit before the receiver will send an acknowledgment. We call this the window size. Basically, the window size indicates the size of the receive buffer.

Typically the TCP connection will start with a small window size and every time when there is a successful acknowledgement, the window size will increase. Here’s an example:

Above we have two hosts, the host on the left side will send one segment and the host on the right side will send an acknowledgment in return. Since the acknowledgement was successful, the windows size will increase:

The host on the left side is now sending two segments and the host on the right side will return a single acknowledgment. Everything is working fine so the window size will increase even further:

The host is now sending four segments and the host on the right side responds with a single acknowledgment.

In the example above the window size keeps increasing as long as the receiver sends acknowledgments for all our segments or when the window size hits a certain maximum limit. When the receiver doesn’t send an acknowledgment within a certain time period (called the round-trip time) then the window size will be reduced.

When an interface has congestion then it’s possible that IP packets are dropped. To deal with this, TCP has a number of algorithms that deal with congestion control. One of them is called slow start.

With TCP slow start, the window size will initially grow exponentially (window size doubles) but once a packet is dropped, the window size will be reduced to one segment. It will then grow exponentially again until the window size is half of what it was when the congestion occurred. At that moment, the window size will grow linearly instead of exponentially.

When an interface gets congested, it’s possible that all your TCP connections will experience TCP slow start. Packets will be dropped and then all TCP connections will have a small window size. This is called TCP global synchronization. Here’s what it looks like:

The orange , blue and green lines are three different TCP connections. These TCP connections start at different times and after awhile, the interface gets congested and packets of all TCP connections are dropped. What happens is that the window size of all these TCP connections will drop to one and once the interface congestion is gone, all their window sizes will increase again.

The interface then gets congested again, the window size drops back to one and the story repeats itself. The result of this is that we don’t use all the available bandwidth that our interface has to offer. If you look at the dashed line you can see that we the average interface utilization isn’t very high.

To prevent global synchronization we can use RED (Random Early Detection). this is a feature that drops “random” packets from TCP flows based on the number of packets in a queue and the TOS (Type of Service) marking of the packets. When packets are dropped before a queue is full, we can avoid the global synchronization.

The end result will look similar to this:

When we use RED, our average interface utilization will improve.

Now you have an idea what the TCP window size is about, let’s take a look at a real example of how the window size is used. We can use wireshark for this.

Wireshark Captures

To examine the TCP window size I will use two devices:

The device on the left side is a modern computer with a gigabit interface. On the right side, we have a small raspberry pi which has a FastEthernet interface. The raspberry pi is a great little device but it’s cpu / memory / ethernet interface are limited. To get an interesting output, I will copy a large file through SSH from my computer to the raspberry pi which will be easily overburdened.

Here’s what happened, take a look at this picture:

In the graph above you can see the window size that was used during this connection. The file transfer started after about 6 seconds and you can see that the window size increased fast. It went up and down a bit but at around 30 seconds, it totally collapsed. After a few seconds it increased again and I was able to complete the file transfer. Let’s take a closer look at this file transfer, which starts with the three way handshake:

My fast computer uses 10.56.100.1 and the raspberry pi uses 10.56.100.164. Above you can see that in the SYN,ACK message that the raspberry pi wants to use a window size of 29200. My computer wants to use a window size of 8388480 (win=65535 * ws=128) which is irrelevant now since we are sending data to the raspberry pi.

After a few packets, the window size of the raspberry pi looks like this:

Above you can see that the window size has increased to 132480. Originally the window size is a 16 bit value so the largest window size would be 65535. Nowadays we use a scaling factor so that we can use larger window sizes.

At around the 10 second mark the window size decreased. Here’s what happened:

The raspberry pi seems to have trouble keeping up and its receive buffer is probably full. It tells the computer to use a window size of 26752 from now on. The computer sends 18 segments with 1460 bytes and one segment of 472 bytes (26752 bytes in total). The last packet shows us “TCP Window Full” message. This is something that wireshark reports to us, our computer has completely filled the receive buffer of the raspberry pi.

Once the raspberry pi has caught up a bit and around the 30 second mark, something bad happens. Take a look at the wireshark capture below:

Above you can see that the raspberry pi sends an ACK to the computer with a window size of 0. This means that the window size will remain at 0 for a specified amount of time, the raspberry pi is unable to receive any more data at this moment and the TCP transmission will be paused for awhile while the receive buffer is processed.

Here’s the actual packet:

Above you can see that the window size is now 0. Once the receive buffer has been processed, the raspberry pi will send an ACK with a new window size:

The window size is now only 25600 bytes but will grow again. The rest of the transmission went without any hiccups and the file transfer completed.

Conclusion

You have now seen how TCP uses the window size to tell the sender how much data to transmit before it will receive an acknowledgment. I also showed you an example of how the window size is used when the receiver is unable to process its receive buffer in time.

I hope you have enjoyed this lesson, if you have any more questions feel free to leave a comment in our forum.

Руководство и шпаргалка по Wireshark

Даже поверхностное знание программы Wireshark и её фильтров на порядок сэкономит время при устранении проблем сетевого или прикладного уровня. Wireshark полезен для многих задач в работе сетевого инженера, специалиста по безопасности или системного администратора. Вот несколько примеров использования:

Устранение неполадок сетевого подключения

Исследование сессий прикладного уровня (даже при шифровании с помощью SSL/TLS, см. ниже)

Устранение неполадок DHCP с данными на уровне пакетов

Извлечение файлов из сессий HTTP

Извлечение файлов из сессий SMB

Обнаружение и проверка вредоносных программ

Проверка сканирования портов и других типов сканирования на уязвимости

• Понимание, какой сетевой трафик поступает от сканеров
• Анализ процедур по проверке уязвимостей, чтобы различать ложноположительные и ложноотрицательные срабатывания

Эти примеры — только вершина айсберга. В руководстве мы расскажем, как использовать столь мощный инструмент.

Установка Wireshark

Wireshark работает на различных операционных системах и его несложно установить. Упомянем только Ubuntu Linux, Centos и Windows.

Установка на Ubuntu или Debian

Установка на Fedora или CentOS

Установка на Windows

На странице загрузки лежит исполняемый файл для установки. Довольно просто ставится и драйвер захвата пакетов, с помощью которого сетевая карта переходит в «неразборчивый» режим (promiscuous mode позволяет принимать все пакеты независимо от того, кому они адресованы).

Начало работы с фильтрами

С первым перехватом вы увидите в интерфейсе Wireshark стандартный шаблон и подробности о пакете.

Как только захватили сессию HTTP, остановите запись и поиграйте с основными фильтрами и настройками Analyze | Follow | HTTP Stream.

Названия фильтров говорят сами за себя. Просто вводите соответствующие выражения в строку фильтра (или в командную строку, если используете tshark). Основное преимущество фильтров — в удалении шума (трафик, который нам не интерестен). Можно фильтровать трафик по MAC-адресу, IP-адресу, подсети или протоколу. Самый простой фильтр — ввести http , так что будет отображаться только трафик HTTP (порт tcp 80).

Примеры фильтров по IP-адресам

Примеры фильтров по протоколу

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

Следуйте за потоком

Как только вы захватили несколько HTTP-пакетов, можно применить на одном из них пункт меню Analyze | Follow | HTTP Stream. Он покажет целиком сессию HTTP. В этом новом окне вы увидите HTTP-запрос от браузера и HTTP-ответ от сервера.

Резолвинг DNS в Wireshark

По умолчанию Wireshark не резолвит сетевые адреса в консоли. Это можно изменить в настройках.

Edit | Preferences | Name Resolution | Enable Network Name Resolution

Как и в случае tcpdump , процедура резолвинга замедлит отображение пакетов. Также важно понимать, что при оперативном захвате пакетов DNS-запросы с вашего хоста станут дополнительным трафиком, который могут перехватить.

Tshark для командной строки

Если вы ещё не баловались с tshark , взгляните на наше руководство с примерами фильтров. Эту программу часто игнорируют, хотя она отлично подходит для захвата сессий на удалённой системе. В отличие от tcpdump , она позволяет на лету захватывать и просматривать сессии прикладного уровня: декодеры протоколов Wireshark также доступны для tshark.

Составление правил для файрвола

Вот быстрый способ создания правил из командной строки, чтобы не искать в интернете конкретный синтаксис. Выберите подходящее правило — и перейдите в Tools | Firewall ACL Rules. Поддерживаются различные файрволы, такие как Cisco IOS, ipfilter , ipfw , iptables , pf и даже файрвол Windows через netsh .

Работа с географической базой GeoIP

Если Wireshark скомпилирован с поддержкой GeoIP и у вас есть бесплатные базы Maxmind, то программа может определять местоположение компьютеров по их IP-адресам. Проверьте в About | Wireshark, что программа скомпилирована с той версией, какая у вас в наличии. Если GeoIP присутствует в списке, то проверьте наличие на диске баз GeoLite City, Country и ASNum. Укажите расположение баз в меню Edit | Preferences | Name Resolution.

Проверьте систему на дампе трафика, выбрав опцию Statistics | Endpoints | IPv4. В колонках справа должна появиться информация о местоположении и ASN для IP-адреса.

Другая функция GeoIP — фильтрация трафика по местоположению с помощью фильтра ip.geoip . Например, так можно исключить трафик из конкретной ASN. Нижеуказанная команда исключает пакеты от сетевого блока ASN 63949 (Linode).

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

Расшифровка сессий SSL/TLS

Один из способов расшифровки сессий SSL/TLS — использовать закрытый ключ с сервера, к которому подключен клиент.

Конечно, у вас не всегда есть доступ к приватному ключу. Но есть другой вариант простого просмотра трафика SSL/TLS на локальной системе. Если Firefox или Chrome загружаются с помощью специальной переменной среды, то симметричные ключи отдельных сеансов SSL/TLS записаны в файл, который Wireshark может прочитать. С помощью этих ключей Wireshark покажет полностью расшифрованную сессию!

1. Настройка переменной среды

На вкладке System Properties | Advanced нажмите кнопку Environment Variables и добавьте имя переменной (SSLKEYLOGFILE), а в качестве значения — путь к файлу.

2. Настройка Wireshark

Из выпадающего меню выберите Edit | Preferences | Protocols | SSL | (Pre)-Master-Secret Log Filename — Browse, указав файл, который вы указали в переменную среды.

Начинайте захват трафика в локальной системе.

3. Перезапуск Firefox или Chrome

После перехода на сайт HTTPS лог-файл начнёт увеличиваться в размере, поскольку записывает симметричные ключи сессии.

Взгляните на ранее запущенную сессию Wireshark. Вы должны увидеть что-то похожее на скриншот внизу с расшифрованными сессиями. Расшифрованные пакеты — на вкладке в нижней панели.

Другой способ просмотра сеанса — через выпадающее меню Analysis | Follow | Stream | SSL. Если сеанс успешно расшифрован, вы увидите опцию для SSL.

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

Ещё один вариант выхода на базовый HTTP-трафика — использовать инструмент Burp Suite с загруженным сертификатом CA в браузере. В этом случае прокси расшифровывает соединение на стороне клиента, а затем устанавливает новый сеанс SSL/TLS на сервере. Есть много способов проведения такой MiTM-атаки на себя, это два самых простых.

Извлечение файлов из пакетов с помощью функции экспорта (HTTP или SMB)

Файлы легко извлекаются через меню экспорта.

File | Export Objects | HTTP

Все найденные файлы отобразятся в новом окне. Отсюда же можно сохранить отдельные файлы или сразу все. Аналогичный метод применяется для извлечения файлов из сессий SMB. Как мы уже упоминали, это протокол Microsoft Server Message Block, который используется для общего доступа к файлам под Windows.

Строка состояния

Строка состояния в правой части окна позволяет быстро перейти в нужное место сетевого дампа, щёлкнув по цветовому индикатору. Например, красным цветом в строке состояния помечены пакеты с ошибками.

Образец PCAP

Когда только начинаете работу с Wireshark, хочется посмотреть на какие-нибудь интересные дампы с пакетами. Их можно найти на странице Wireshark Samples. Примеров с разными протоколами там хватит вам на несколько месяцев анализа, есть даже образцы трафика червей и эксплоитов.

Настройка окружения

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

Столбцы настраиваются в меню Edit | Preferences | Appearance | Columns. Там же изменяется общий шаблон, шрифт и цвета.

На видео — полезные советы по настройке окружения, в том числе выявление неполадок по порядковым номерам последовательности TCP.

capinfos

В комплекте с Wireshark поставляется удобный инструмент командной строки capinfos . Эта утилита генерирует статистику пакетного дампа, с временем начала/окончания записи и другими подробностями. С опцией -T она выдаёт текст с табуляцией — он подходит для импорта в электронные таблицы или анализа в консоли.