Сетевая контрразведка: как обнаружить сканирование узлов и портов

Алексей Лукацкий,
заместитель технического директора Научно-инженерного предприятия "Информзащита",

luka@infosec.ru

Если вы хотите приобрести журнал "BYTE/Россия", то первое, что вы делаете, — это ищете магазин, киоск или лоток, где продается это издание. Выражаясь научно, вы осуществляете процесс идентификации (поиск) цели (магазин), позволяющей решить поставленную задачу (приобретение журнала). Также и с атаками на информационную систему: первое, что делает злоумышленник, — это выбирает себе жертву и собирает подробную информацию о ней. Этот этап называется сбором информации (information gathering). Именно эффективность работы злоумышленника на данном этапе — залог успешной атаки. В первую очередь выбирается цель атаки и собирается информация о ней (ОС, сервисы, конфигурация и т.д.). Затем идентифицируются наиболее уязвимые места атакуемой системы, воздействие на которые может привести к нужному результату.

На первом этапе злоумышленник пытается выявить все каналы, посредством которых цель атаки взаимодействует с другими узлами. Это позволит не только выбрать тип атаки, но и источник ее реализации. Например, атакуемый узел взаимодействует с двумя серверами под управлением ОС UNIX и Windows NT. С одним сервером атакуемый узел имеет доверенные отношения, а с другим — нет. От того, через какой сервер произойдет нападение, зависит то, какая атака будет задействована, какая утилита будет ее реализовывать, и т.д. Затем, в зависимости от полученной информации и желаемого результата, выбирается атака, дающая наибольший эффект. Например, для нарушения функционирования узла можно использовать SYN Flood, Teardrop, UDP Bomb и т.д., а для проникновения на узел и кражи информации — PHF-скрипт для кражи файла паролей, удаленный подбор пароля и т.п. Только после сбора подробной информации о жертве наступает второй этап — реализация выбранной атаки.

Процесс сбора информации включает следующие действия:

• изучение окружения жертвы и сетевой топологии;
• определение типа и версии ОС атакуемого узла, доступных сетевых и иных сервисов
  и т.п.

В данной статье я остановлюсь только на трех действиях, которые злоумышленник выполняет первыми. Это идентификация атакуемых узлов, их сетевых сервисов и операционных систем.

Идентификация узлов

Для идентификации узла (host detection), как правило, при помощи утилиты ping (или аналогичных программ) ему посылается команда ECHO_REQUEST протокола ICMP. Ответное сообщение ECHO_REPLY говорит о том, что узел доступен. Это самый простой и часто используемый метод идентификации узлов, который используется всеми (не только начинающими) злоумышленниками. Существуют программы, например fping или nmap, которые автоматизируют и ускоряют процесс параллельной идентификации большого числа узлов. Данный метод опасен тем, что стандартными средствами узла запросы ECHO_REQUEST не фиксируются. Для этого необходимо применять средства анализа трафика, межсетевые экраны или системы обнаружения атак.

01:00:38.861865 200.0.0.200 > 200.0.0.1: icmp: echo request
01:00:51.903375 200.0.0.200 > 200.0.0.2: icmp: echo request
01:01:04.925395 200.0.0.200 > 200.0.0.3: icmp: echo request
01:01:18.014343 200.0.0.200 > 200.0.0.4: icmp: echo request
01:01:31.035095 200.0.0.200 > 200.0.0.5: icmp: echo request
01:01:44.078728 200.0.0.200 > 200.0.0.6: icmp: echo request
01:01:57.098411 200.0.0.200 > 200.0.0.7: icmp: echo request
...

Обычные сканеры узлов, доступные в Интернете, приводят к появлению именно такой череды событий, так как они последовательно проверяют активность каждого узла в атакуемой сети. Более сложные сканеры (например, Nmap) изменяют стандартную последовательность опроса узлов и могут случайным образом выбирать их из заданного списка.

07:11:38.123565 200.0.0.200 > 200.0.0.34: icmp: echo request
07:11:51.456342 200.0.0.200 > 200.0.0.47: icmp: echo request
07:11:04.678432 200.0.0.200 > 200.0.0.3: icmp: echo request
07:12:18.985667 200.0.0.200 > 200.0.0.12: icmp: echo request
07:12:31.024657 200.0.0.200 > 200.0.0.11: icmp: echo request
07:12:44.044567 200.0.0.200 > 200.0.0.9: icmp: echo request
07:12:57.071234 200.0.0.200 > 200.0.0.104: icmp: echo request
...

Еще один вариант сканирования узлов, осложняющий его обнаружение, — увеличение интервала времени, в течение которого происходит сканирование. Обычно сканеры узлов шлют запросы со скоростью 5 — 10 портов в секунду. Однако если заданные по умолчанию временные значения меняются, то многие средства сетевой защиты пропускают такого рода действия.

12:01:38.234455 200.0.0.200 > 200.0.0.67: icmp: echo request
12:03:51.543524 200.0.0.200 > 200.0.0.87: icmp: echo request
12:05:04.655342 200.0.0.200 > 200.0.0.134: icmp: echo request
12:07:18.573256 200.0.0.200 > 200.0.0.23: icmp: echo request
12:09:31.676899 200.0.0.200 > 200.0.0.11: icmp: echo request
12:11:44.896754 200.0.0.200 > 200.0.0.104: icmp: echo request
12:13:57.075356 200.0.0.200 > 200.0.0.2: icmp: echo request
...

Для обнаружения такого рода действий можно использовать различные утилиты, например TCPdump, которая предназначена для получения вывода (на экран, в файл и т.д.) заголовков сетевых пакетов, получаемых/посылаемых через заданный сетевой интерфейс и соответствующих определенному условию. Данная утилита очень часто используется как самостоятельное средство для сбора информации о сетевом трафике, фиксируемом в сегменте корпоративной сети. На базе данной системы часто строят системы обнаружения атак и другие средства сетевой безопасности. Утилиту можно загрузить с сервера ftp://ftp.ee.lbl.gov/TCPDump.tar.Z или http://netgroup-serv.polito.it/windump/.

Можно поступить проще — не обнаруживать такие действия, а запретить их, как делают многие сетевые устройства и программы, которые блокируют ICMP-пакеты и не пропускают их во внутреннюю сеть (или, наоборот, не пропускают наружу). Например, MS Proxy Server 2.0 не разрешает прохождение пакетов по протоколу ICMP. В результате злоумышленник не может эффективно идентифицировать узлы, установленные за сервером-посредником (proxy). С другой стороны, блокировка ICMP-пакета говорит злоумышленнику о наличии "первой линии обороны" — маршрутизаторов, межсетевых экранов и т.д.

Существуют и другие методы идентификации узлов в сети: например, использование "смешанного" (promiscuous) режима сетевой карты, который позволяет определить различные узлы в сегменте сети, или разведка DNS, которая позволяет идентифицировать узлы корпоративной сети при помощи службы имен. Но рассмотрение этих методов и способов их обнаружения выходит за рамки данной статьи.

Идентификация сервисов или сканирование портов

Идентификация сервисов (service detection), как правило, осуществляется путем обнаружения открытых портов (port scanning). Такие порты очень часто связаны с сервисами, основанными на протоколах TCP или UDP. Например, открытый 80-й порт подразумевает наличие Web-сервера, 25-й порт — почтового SMTP-сервера, 31337-й — сервера троянского коня BackOrifice, 12345 или 12346-й — сервера троянского коня NetBus и т.д. Для идентификации сервисов и сканирования портов можно использовать различные программы, такие как nmap или netcat.

Выбрав цель атаки, злоумышленник определяет запущенные на ней сервисы и открытые порты, что позволит определить потенциально уязвимые места на атакуемом узле и сузить число возможных атак. Для сканирования портов используются различные программы, отличающиеся реализацией данного механизма. Самые простые программы (например, Haktek) просто пытаются установить обычное соединение с портом, начиная с первого и заканчивая тем, который задан пользователем.

17:17:21.966870 WS_LUKICH.2876 > WS_LUKA.1: S 713310:713310(0) 
	win 8192 <mss 1460> (DF)
17:17:21.967698 WS_LUKICH.2877 > WS_LUKA.2: S 713329:713329(0) 
	win 8192 <mss 1460> (DF)
17:17:21.968612 WS_LUKICH.2878 > WS_LUKA.3: S 713349:713349(0) 
	win 8192 <mss 1460> (DF)
17:17:21.969095 WS_LUKICH.2879 > WS_LUKA.4: S 713364:713364(0) 
	win 8192 <mss 1460> (DF)
17:17:21.969574 WS_LUKICH.2880 > WS_LUKA.5: S 713372:713372(0) 
	win 8192 <mss 1460> (DF)
17:17:21.970041 WS_LUKICH.2881 > WS_LUKA.6: S 713381:713381(0) 
	win 8192 <mss 1460> (DF)
17:17:21.970523 WS_LUKICH.2882 > WS_LUKA.7: S 713391:713391(0) 
	win 8192 <mss 1460> (DF)
17:17:21.971031 WS_LUKICH.2883 > WS_LUKA.8: S 713402:713402(0) 
	win 8192 <mss 1460> (DF)
17:17:21.971539 WS_LUKICH.2884 > WS_LUKA.9: S 713414:713414(0) 
	win 8192 <mss 1460> (DF)
17:17:21.972014 WS_LUKICH.2885 > WS_LUKA.10: S 713427:713427(0) 
	win 8192 <mss 1460> (DF)
17:17:21.973780 WS_LUKICH.2886 > WS_LUKA.11: S 713441:713441(0) 
	win 8192 <mss 1460> (DF)
17:17:21.973814 WS_LUKICH.2887 > WS_LUKA.12: S 713455:713455(0) 
	win 8192 <mss 1460> (DF)
17:17:21.973834 WS_LUKICH.2888 > WS_LUKA.13: S 713469:713469(0) 
	win 8192 <mss 1460> (DF)

Обнаружить такого рода деятельность достаточно легко с помощью простого фильтра TCPdump. Однако такие программы используются достаточно редко и только теми пользователями, которые не имеют представления о наличии более изощренных утилит, проявляющих при сканировании портов некоторый интеллект. К таким утилитам относится Nmap (http://www.nmap.org), функционирующая под управлением большинства клонов UNIX и даже Windows (http://www.eeye.com/html/tools/nmapnt.html). Данная утилита реализует большое число различных типов сканирования (в версии 2.53 этих типов 14), в том числе и сканирование портов.

17:26:48.031721 WS_LUKA.2797 > WS_LUKICH.371: S 26274004:26274004(0) 
	win 8192 <mss 1460> (DF)
17:26:48.034533 WS_LUKA.2798 > WS_LUKICH.344: S 26330728:26330728(0) 
	win 8192 <mss 1460> (DF)
17:26:48.035510 WS_LUKA.2799 > WS_LUKICH.919: S 26396113:26396113(0) 
	win 8192 <mss 1460> (DF)
17:26:48.036466 WS_LUKA.2800 > WS_LUKICH.1155: S 26439772:26439772(0) 
	win 8192 <mss 1460> (DF)
17:26:48.037421 WS_LUKA.2801 > WS_LUKICH.117: S 26476417:26476417(0) 
	win 8192 <mss 1460> (DF)
17:26:48.038372 WS_LUKA.2802 > WS_LUKICH.625: S 26518671:26518671(0) 
	win 8192 <mss 1460> (DF)
17:26:48.039338 WS_LUKA.2803 > WS_LUKICH.220: S 26552575:26552575(0) 
	win 8192 <mss 1460> (DF)
17:26:48.040281 WS_LUKA.2804 > WS_LUKICH.770: S 26588454:26588454(0) 
	win 8192 <mss 1460> (DF)
17:26:48.041235 WS_LUKA.2805 > WS_LUKICH.619: S 26633584:26633584(0) 
	win 8192 <mss 1460> (DF)
17:26:48.042170 WS_LUKA.2806 > WS_LUKICH.1652: S 26670889:26670889(0) 
	win 8192 <mss 1460> (DF)
17:26:48.043264 WS_LUKA.2807 > WS_LUKICH.403: S 26734852:26734852(0) 
	win 8192 <mss 1460> (DF)

17:22:32.224567 WS_LUKA.52753 > WS_LUKICH.1544:
	S 866284386:866284386(0) win 1024
17:22:32.225413 WS_LUKA.52753 > WS_LUKICH.427: 
	S 866284386:866284386(0) win 1024
17:22:32.225413 WS_LUKA.52753 > WS_LUKICH.447: 
	S 866284386:866284386(0) win 1024
17:22:32.224845 WS_LUKA.52753 > WS_LUKICH.496: 
	S 866284386:866284386(0) win 1024
17:22:32.225009 WS_LUKA.52753 > WS_LUKICH.597: 
	S 866284386:866284386(0) win 1024
17:22:32.225207 WS_LUKA.52753 > WS_LUKICH.659: 
	S 866284386:866284386(0) win 1024
17:22:32.225413 WS_LUKA.52753 > WS_LUKICH.159: 
	S 866284386:866284386(0) win 1024
17:22:32.225582 WS_LUKA.52753 > WS_LUKICH.529: 
	S 866284386:866284386(0) win 1024
17:22:32.225782 WS_LUKA.52753 > WS_LUKICH.2017: 
	S 866284386:866284386(0) win 1024
17:22:32.225413 WS_LUKA.52753 > WS_LUKICH.427: 
	S 866284386:866284386(0) win 1024
17:22:32.225945 WS_LUKA.52753 > WS_LUKICH.1380
	S 866284386:866284386(0) win 1024
17:22:32.226153 WS_LUKA.52753 > WS_LUKICH.1522: 
	S 866284386:866284386(0) win 1024
17:22:32.226356 WS_LUKA.52753 > WS_LUKICH.1109: 
	S 866284386:866284386(0) win 1024
17:22:32.231078 WS_LUKA.52753 > WS_LUKICH.306: 
	S 866284386:866284386(0) win 1024
17:22:32.233200 WS_LUKA.52753 > WS_LUKICH.274: 
	S 866284386:866284386(0) win 1024
17:22:32.225413 WS_LUKA.52753 > WS_LUKICH.447: 
	S 866284386:866284386(0) win 1024
17:22:32.235295 WS_LUKA.52753 > WS_LUKICH.1663: 
	S 866284386:866284386(0) win 1024

17:30:03.034865 WS_LUKA.48796 > WS_LUKICH.670: udp 0
17:30:03.035066 WS_LUKA.48796 > WS_LUKICH.1248: udp 0
17:30:03.035269 WS_LUKA.48796 > WS_LUKICH.25: udp 0
17:30:03.035448 WS_LUKA.48796 > WS_LUKICH.1017: udp 0
17:30:03.035653 WS_LUKA.48796 > WS_LUKICH.1415: udp 0
17:30:03.035815 WS_LUKA.48796 > WS_LUKICH.963: udp 0
17:30:03.036006 WS_LUKA.48796 > WS_LUKICH.11: udp 0
17:30:03.036160 WS_LUKA.48796 > WS_LUKICH.345: udp 0

Представленные данные три фрагмента журнала TCPdump очень интересны, так как номера сканируемых портов увеличиваются не на единицу, как это обычно происходит, а совершенно случайным образом. Более того, чтобы усложнить обнаружение такого сканирования, номера сканируемых портов не только увеличиваются, но и уменьшаются. Дополнительный механизм скрытия факта сканирования от средств сетевой защиты — повторное обращение к некоторым портам (в нашем примере во втором фрагменте это номера 427 и 447).

Классические варианты сканирования легко обнаруживаются межсетевым экраном:

"421316" "29Dec2000" " 9:32:16" "daemon" "localhost" "alert" 
   "accept" "" "x.x.x.x" "x.x.x.x" "ip" "" "" "" "" "" "" "" "" "" 
   "" "" "MAD" " additionals: attack=blocked_connection_port_scanning"
"422255" "29Dec2000" " 9:33:59" "daemon" "localhost" "alert" 
   "accept" "" "x.x.x.x" "x.x.x.x" "ip" "" "" "" "" "" "" "" "" "" 
   "" "" "MAD" " additionals: attack=blocked_connection_port_scanning"
"427220" "29Dec2000" " 9:43:26" "daemon" "localhost" "alert" 
   "accept" "" "x.x.x.x" "x.x.x.x" "ip" "" "" "" "" "" "" "" "" "" 
   "" "" "MAD" " additionals: attack=blocked_connection_port_scanning"

Но помимо них существуют и другие способы сканирования, которые не обнаруживаются традиционными средствами сетевой безопасности. Это так называемое скрытое (stealth) сканирование, использующее особенности обработки сетевых пакетов, не соответствующих стандартам TCP/IP. Таких вариантов сканирования может быть несколько: например FIN-сканирование, Xmas-сканирование или Null-сканирование.

18:18:03.436878 WS_LUKA.57239 > WS_LUKICH.9535: F 0:0(0) win 3072
18:18:03.437131 WS_LUKA.57239 > WS_LUKICH.1482: F 0:0(0) win 3072
18:18:03.437335 WS_LUKA.57239 > WS_LUKICH.617: F 0:0(0) win 3072
18:18:03.437501 WS_LUKA.57239 > WS_LUKICH.148: F 0:0(0) win 3072
18:18:03.437709 WS_LUKA.57239 > WS_LUKICH.638: F 0:0(0) win 3072
18:18:03.437872 WS_LUKA.57239 > WS_LUKICH.1467: F 0:0(0) win 3072
18:18:03.438089 WS_LUKA.57239 > WS_LUKICH.1475: F 0:0(0) win 3072
18:18:03.438286 WS_LUKA.57239 > WS_LUKICH.852: F 0:0(0) win 3072
18:18:03.438446 WS_LUKA.57239 > WS_LUKICH.653: F 0:0(0) win 3072
18:18:03.442145 WS_LUKA.57239 > WS_LUKICH.672: F 0:0(0) win 3072

18:18:28.038171 WS_LUKA.57407 > WS_LUKICH.1031: FP 0:0(0) 
	win 3072 urg 0
18:18:28.038378 WS_LUKA.57407 > WS_LUKICH.1112: FP 0:0(0) 
	win 3072 urg 0
18:18:28.038643 WS_LUKA.57407 > WS_LUKICH.2048: FP 0:0(0) 
	win 3072 urg 0
18:18:28.038846 WS_LUKA.57407 > WS_LUKICH.6666: FP 0:0(0) 
	win 3072 urg 0
18:18:28.039015 WS_LUKA.57407 > WS_LUKICH.906: FP 0:0(0) 
	win 3072 urg 0
18:18:28.039180 WS_LUKA.57407 > WS_LUKICH.135: FP 0:0(0) 
	win 3072 urg 0
18:18:28.039369 WS_LUKA.57407 > WS_LUKICH.1003: FP 0:0(0) 
	win 3072 urg 0
18:18:28.039575 WS_LUKA.57407 > WS_LUKICH.3141: FP 0:0(0) 
	win 3072 urg 0
18:18:28.039739 WS_LUKA.57407 > WS_LUKICH.1448: FP 0:0(0) 
	win 3072 urg 0

18:20:04.466572 WS_LUKA.53497 > WS_LUKICH.2766: . win 1024
18:20:04.466776 WS_LUKA.53497 > WS_LUKICH.534: . win 1024
18:20:04.466995 WS_LUKA.53497 > WS_LUKICH.206: . win 1024
18:20:04.467164 WS_LUKA.53497 > WS_LUKICH.119: . win 1024
18:20:04.467372 WS_LUKA.53497 > WS_LUKICH.636: . win 1024
18:20:04.467575 WS_LUKA.53497 > WS_LUKICH.313: . win 1024
18:20:04.467836 WS_LUKA.53497 > WS_LUKICH.372: . win 1024
18:20:04.468040 WS_LUKA.53497 > WS_LUKICH.378: . win 1024
18:20:04.468204 WS_LUKA.53497 > WS_LUKICH.532: . win 1024

Последний вариант более наглядно можно продемонстрировать на примере журнала регистрации системы обнаружения Snort (http://www.snort.org).

[**] NULL Scan [**]
05/28-21:09:23.686988 194.159.251.190:27025 -> 192.168.1.1:1186 
   TCP TTL:44 TOS:0x0 ID:64660 DF ******** Seq: 0xE4714 
   Ack: 0xFFFFFFFF Win: 0x0

Последний вариант более наглядно можно продемонстрировать на примере журнала регистрации системы обнаружения Snort (http://www.snort.org).

[**] NULL Scan [**]
05/28-21:09:23.686988 194.159.251.190:27025 -> 192.168.1.1:1186 
   TCP TTL:44 TOS:0x0 ID:64660 DF ******** Seq: 0xE4714 
   Ack: 0xFFFFFFFF Win: 0x0

Для сравнения приведем уже продемонстрированный вариант FIN-сканирования.

[**] SCAN-FIN [**]
02/02-04:49:15.135173 0:D0:58:4A:46:D0 -> 0:10:5A:6C:9A:55 
   type:0x800 len:0x104 195.11.50.204:2931 -> my-squid:53 
   TCP TTL:39 TOS:0x0 ID:2037 *F**** Seq: 0x32563E 
   Ack: 0x362C0000 Win: 0x0

Необходимо отметить, что средства сетевой защиты должны обращать внимание на
любые пакеты, не соответствующие стандартам RFC, например неописанные или запрещенные
комбинации флагов. Именно данный принцип заложен в механизм скрытого сканирования,
поскольку зачастую сетевые средства анализируют только "правильные" с точки
зрения RFC пакеты, не замечая весь остальной трафик. Например, в RFC 793 описано,
как должны реагировать различные системы на нормальные TCP-пакеты. Но… в этом
документе (и в других) не описано, как система должна реагировать на неправильные
TCP-пакеты; в результате различные устройства и ОС по-разному реагируют на пакеты
с запрещенными комбинациями TCP-флагов. В TCP-пакете могут встретиться шесть
флагов: SYN, ACK, FIN, RST, PSH, URG. К запрещенным комбинациям относятся следующие.

• SYN + FIN — это два взаимоисключающих флага (первый устанавливает соединение,
  а второй завершает его), поэтому они не могут встречаться вместе. Такую комбинацию
  очень часто используют различные сканеры, например уже упоминавшийся Nmap.
  Еще год назад многие защитные системы не могли обнаружить такого рода сканирование.
  Сейчас ситуация изменилась к лучшему, многие системы отслеживают эти комбинации
  флагов. Но добавление еще одного флага к данной комбинации (например, SYN
  + FIN + PSH, SYN + FIN + RST, SYN + FIN + RST + PSH) опять приводит к тому,
  что некоторые средства сетевой безопасности не обнаруживают такие несанкционированные
  попытки. Аналитики называют эти комбинации "шаблоном рождественской елки"
  ("Christmas Tree Pattern").

  "Шаблон рождественской елки" (фрагмент журнала Snort)

  01/23-01:15:22.237103 195.11.212.180:30975 -> 192.0.97.80:49708 TCP TTL:49 TOS:0x0 ID:12207 DF SFRPAU21 Seq: 0x78FFC22C Ack: 0x78FFC22C Win: 0xC22C TCP Options => Opt 120 (40): C22C 78FF C22C 78FF C22C 78FF 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 78 FF C2 2C 78 FF x..,x.

• TCP-пакеты никогда не должны содержать только один флаг FIN. Обычно один
  установленный флаг FIN говорит о FIN-сканировании;
• TCP-пакеты должны иметь хотя бы один флаг, но не FIN и не SYN (если это
  не первый пакет в соединении);
• если в TCP-пакете не установлен флаг ACK и этот пакет — не первый при установлении
  соединения (three-way handshake), то такой пакет однозначно ненормален, поскольку
  в любом TCP-пакете должен присутствовать флаг ACK;
• помимо указанных комбинаций, подозрительными считаются RST+FIN, SYN+RST.
  

  Подозрительные комбинации флагов в заголовке TCP-пакета (фрагмент журнала TCPdump)

  13:45:28.194556 172.20.20.1.5800 > 192.168.1.2.5800: SFP 6172717:6174189(1472) ack 2436270 win 15360 (DF)

Еще одна интересная возможность сканера Nmap, которой часто пользуются квалифицированные злоумышленники при сканировании, — возможность фальсификации адресов источника (режим Decoy), когда вместо реальных IP-адресов источника проставляются другие IP-адреса. Тем самым перед администратором системы обнаружения атак ставится непростая задача: обнаружить среди множества зафиксированных в журналах регистрации IP-адресов только один реальный, с которого действительно проводилось сканирование.

06:43:55 10.2.2.2.57536 > WS_LUKICH.328: S 1496167267:1496167267(0)
06:43:55 10.3.3.3.57536 > WS_LUKICH.328: S 1496167267:1496167267(0)
06:43:55 WS_LUKA.57536 > WS_LUKICH.328: S 1496167267:1496167267(0)
06:43:55 10.4.4.4.57536 > WS_LUKICH.328: S 1496167267:1496167267(0)
06:43:55 10.5.5.5.57536 > WS_LUKICH.328: S 1496167267:1496167267(0)
06:43:55 10.2.2.2.57536 > WS_LUKICH.994: S 1496167267:1496167267(0)
06:43:55 10.3.3.3.57536 > WS_LUKICH.994: S 1496167267:1496167267(0)
06:43:55 WS_LUKA.57536 > WS_LUKICH.994: S 1496167267:1496167267(0)
06:43:55 10.4.4.4.57536 > WS_LUKICH.994: S 1496167267:1496167267(0)
06:43:55 10.5.5.5.57536 > WS_LUKICH.994: S 1496167267:1496167267(0)
06:43:55 10.2.2.2.57536 > WS_LUKICH.280: S 1496167267:1496167267(0)
06:43:55 10.3.3.3.57536 > WS_LUKICH.280: S 1496167267:1496167267(0)
06:43:55 WS_LUKA.57536 > WS_LUKICH.280: S 1496167267:1496167267(0)
06:43:55 10.4.4.4.57536 > WS_LUKICH.280: S 1496167267:1496167267(0)
06:43:55 10.5.5.5.57536 > WS_LUKICH.280: S 1496167267:1496167267(0)

Идентификация ОС

Знание типа ОС позволяет еще больше сузить число потенциальных атак, которые можно реализовать против избранной жертвы. Основной механизм удаленного определения ОС (OS detection) — анализ реализаций TCP/IP-стека. В каждой ОС по-своему реализован стек протоколов TCP/IP, что позволяет при помощи специальных запросов и ответов на них определить, какая ОС установлена на узле.

Другой, менее эффективный и крайне ограниченный способ идентификации ОС — анализ сетевых сервисов, обнаруженных на предыдущем этапе. Например, открытый 139-й порт позволяет сделать вывод, что удаленный узел работает под управлением ОС семейства Windows. Для определения ОС можно использовать такие программы, как Nmap или Queso.

luka# queso -d 200.0.0.253
Starting luka.infosec.ru:6363 -> 200.0.0.253:80
IN #0 : 80->6363 S:1 A:+1 W:7C00 U:0 F: SYN ACK
IN #1 : 80->6364 S:0 A: 0 W:0000 U:0 F: RST
IN #3 : 80->6366 S:0 A: 0 W:0000 U:0 F: RST
IN #4 : 80->6367 S:1 A:+1 W:7C00 U:0 F: SYN FIN ACK
IN #6 : 80->6369 S:1 A:+1 W:7C00 U:0 F: SYN ACK XXX YYY
200.0.0.253:80 * Linux 1.3.xx, 2.0.0 to 2.0.34
luka# queso -d 200.0.0.200
Starting luka.infosec.ru:15690 -> 200.0.0.200:80
IN #0 : 80->15690 S:1 A:+1 W:2180 U:0 F: SYN ACK
IN #1 : 80->15691 S:0 A:+1 W:0000 U:0 F: RST
IN #2 : 80->15692 S:0 A:+1 W:0000 U:0 F: RST ACK
IN #3 : 80->15693 S:0 A:+1 W:0000 U:0 F: RST
IN #4 : 80->15694 S:1 A:+1 W:2180 U:0 F: SYN ACK
IN #5 : 80->15695 S:0 A:+0 W:0000 U:0 F: RST ACK
IN #6 : 80->15696 S:1 A:+1 W:2180 U:0 F: SYN ACK
200.0.0.200:80 * Windows 95/98/NT

После запуска QueSO определяет открытый порт на сканируемом узле.

02:35:10.10 WS_LUKA.29708 > WS_LUKICH.80: S 1173826820:1173826820(0)
02:35:10.10 WS_LUKICH.80 > WS_LUKA.29708: S 1108893357:1108893357(0) 
   ack 1173826821
02:35:10.11 WS_LUKA.29708 > WS_LUKICH.80: R 1173826821:1173826821(0)

Затем она посылает несколько пакетов, не соответствующих стандартам RFC, отклик на которые позволяет сделать вывод о том, какая ОС используется на узле.

02:35:10.11 WS_LUKA.29709 > WS_LUKICH.80: S 1173826820:1173826820(0) 
   ack 0
02:35:10.13 WS_LUKA.29710 > WS_LUKICH.80: F 1173826820:1173826820(0)
02:35:10.15 WS_LUKA.29711 > WS_LUKICH.80: F 1173826820:1173826820(0) 
   ack 0
02:35:10.17 WS_LUKA.29712 > WS_LUKICH.80: SF 1173826820:1173826820(0)
02:35:10.19 WS_LUKA.29713 > WS_LUKICH.80: P
02:35:10.21 WS_LUKA.29714 > WS_LUKICH.80: S 1173826820:1173826820(0)
	4500 0028 ee7b 0000 fc06 2f62 ab45 a42d
	ac15 a569 7412 0017 45f7 2d04 0000 0000
	50c2 1234 14d8 0000 0000 0000 0000

В посылаемых пакетах могут быть использованы следующие комбинации флагов:

• SYN+ACK с ACK, установленным в ноль;
• только FIN;
• FIN+ACK с ACK, установленным в ноль;
• SYN+FIN;
• только PUSH;
• SYN+XXX+YYY, где XXX и YYY — зарезервированные флаги в TCP-заголовке (два
  старших бита в 13-м байте заголовка TCP-пакета).

Сканер Nmap использует сходную технику для определения типа ОС, но в посылаемых пакетах используются несколько иные комбинации флагов:

• только SYN;
• никаких флагов;
• SYN+FIN+URGENT+PUSH;
• только ACK;
• только SYN (посылается на закрытый порт);
• только ACK (посылается на закрытый порт);
• FIN+URGENT+PUSH (посылается на закрытый порт).

Кроме того, для удаленной идентификации ОС сканер Nmap может использовать UDP-пакеты и опции TCP-пакета (TCP options).

И в заключение заметим следующее. Знание методов и механизмов, используемых злоумышленниками для реализации различных атак, не только поможет в реальной жизни обнаруживать несанкционированные действия, не приобретая дорогостоящих средств защиты, но и понять принципы, заложенные в широко известные системы сетевой безопасности, такие как RealSecure Network Sensor или Check Point Firewall-1.