2.10. Чтение пакетов.

Как известно, прежде чем сетевой трафик попадает в сеть, он разбивается на пакеты. Большинство пакетов в сети обычно приходится на TCP; однако могут встречаться и другие типы пакетов, например DNS, ICMP, NetBIOS over TCPIP (NBT) и UDP. Каждый пакет имеет специальный TCP-флаг в секции заголовка пакета и другие флаги, которые перечислены ниже в том порядке, в каком они появляются в заголовке.

• U (URG) — срочность; данные передаются вне очереди.

• A (ACK) — уведомление об успешном приеме данных; сообщает о том, что отправитель знает о получении пакета. Получатель пакета посылает ACK-пакет, в который включен порядковый номер отправителя плюс длина пакета данных, чтобы проконтролировать, что информация пакета была принята правильно.

• P (PSH) — принудительная доставка данных до того, как буфер будет заполнен. Этот флаг обычно используется для интерактивного трафика.

• *R (RST) — сброс; аварийное завершение сессии. Присутствие большого числа пакетов с флагом RST говорит о проблемах в сети.

• S (SYN) — применяется для открытия сессии и получения начального номера последовательности. Часто используется для атак типа «отказ в обслуживании» (Denial of Service, DoS). Хакеры могут попытаться инициировать большое число сессий с неверного IP-адреса, вынудив сервер отвечать пакетами ACK на несуществующий адрес IP. В большинстве брандмауэров предусмотрены меры по защите от DoS-атак.

• F (FIN) — штатное завершение сессии TCP. Пакет FIN означает, что отправитель закончил передачу данных.

2.11. Наблюдение за флагами.

Большинство сетей имеют трафик, состоящий в основном из ACK- и PSH-пакетов. Если сервер не генерирует постоянно новых сессий, то пакетов SYN должно быть относительно немного. Серверы с огромным числом SYN-пакетов, вероятно, подверглись одной из разновидностей DoS-атаки (иначе называемой SYN flood). Число FIN-пакетов и SYN-пакетов должно быть примерно одинаковым. RST бывает немного. Большое число пакетов RST может быть симптомом неустойчивых сетевых соединений, неисправных адаптеров, высокого сетевого трафика, сбоев в работе коммутаторов или хабов либо сбоев в работе иного сетевого оборудования.

Рисунок 6. Детальная информация из фрейма.

2.12. Номера портов.

Как мы знаем, пакеты TCP/IP идентифицируют порт источника и приемника пакета. При чтении информации о пакете нужно вести журнал принимающих и передающих портов сервера. Следует также хорошо разбираться в номерах общепринятых портов и портов, используемых в Windows. Если в перехваченном трафике обнаружится неизвестный порт, это может быть признаком активности хакеров.

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

2.13. Повторные передачи пакетов.

Network Monitor может использоваться для решения проблем на уровне взаимодействия компьютеров. Обратите внимание на пакеты повторной передачи (т. е. пакеты с флагом R в заголовке пакета), которые имеют более продолжительные тайм-ауты и статические порядковые номера на множестве пакетов. Ретрансмиссии возникают в том случае, когда обмен данными между двумя компьютерами был по какой-либо причине прерван — например, из-за неисправного оборудования или задержек WAN. При появлении ретрансмиссии тайм-аут увеличивается вдвое, пока число повторных попыток не достигнет 5 (по умолчанию). На Рисуноке 7 показан перехваченный трафик в ситуации, когда во время передачи файла по FTP от компьютера-клиента отсоединили сетевой кабель. Номера фреймов с 834 по 992 (левая колонка в верхней части) имеют одинаковые порядковые номера для всех пакетов, что указывает на неполадки в соединении. Во фреймах с 1172 по 1385 снова встречается тот же самый порядковый номер. При нормальном FTP-трафике порядковый номер в каждом пакете должен возрастать, а не оставаться прежним. Обратите внимание, что потребовалось в общей сложности 10 пакетов для аварийного завершения передачи по FTP — пять повторных попыток передать данные и еще пять повторных попыток закрыть соединение. Заметьте метку времени 77.012668 в 834-м фрейме. Временной интервал между 834-м и 845-м фреймами (77,668893-77,012668) составляет 0,656225. Между 845-м и 868-м фреймами — 1,312449, что вдвое больше 0,656225. Для каждого следующего пакета время удваивается, пока не будет достигнут максимум числа повторных попыток (в данном случае пять).

При использовании медленного соединения с WAN или линии с большим разбросом скорости соединения максимальное число попыток, возможно, потребуется увеличить. Для этого на сервере, где запускается Network Monitor, нужно найти раздел реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesTcpipParameters и добавить параметр (тип DWORD) TcpMaxDataRetransmissions. Установите значение decimal и укажите число больше 5.

Наблюдение за пакетом может подсказать оптимальное значение этого параметра для конкретной среды работы. Например, в случае проблемы ретрансмиссий следует увеличить TcpMaxDataRetransmissions до заведомо большего значения, например 20, и посмотреть, сколько соединений восстанавливают передачу данных. Если окажется, что большинство сессий FTP удовлетворяется, скажем, восемью ретрансмиссиями, требуется переустановить TcpMaxDataRetransmissions на сервере в значение 9. Это несколько затормозит работу сервера, если сеть WAN перестала работать, но соединение с клиентом по-прежнему будет активным.

Рисунок 7. Увеличение значений тайм-аутов при трассировке пакетов.

Изначально величина тайм-аута для любой сессии равна 3 секундам, а затем она настраивается в зависимости от скорости соединения. Мы рассматривали пример с LAN, поэтому самая первая повторная попытка соединения была предпринята через очень короткий промежуток времени — 0,65 с. Для медленного WAN-соединения увеличение максимума ретрансмиссий может привести к продолжительной задержке в работе сервера, прежде чем соединение будет оборвано по тайм-ауту. Если используется медленный канал связи и начальное значение тайм-аута равно пяти секундам, сколько времени соединение будет «висеть» при максимальной ретрансмиссии 6? Ответ — 315 секунд, или дольше 5 минут (5+10+20+40+80+160).