исследование удаленных хостов с помощью hping
Целью этой статьи является обзор некоторых методов, которые могут быть эффективно использованы для исследования удаленных хостов. Кое-что на эту тему уже публиковалось в «Сетевых Решениях», однако, во-первых, это было давно, и, во-вторых, в тех публикациях упор делался на использование nmap и эвристические техники на основе изучения баннеров работающих сервисов.
Предполагается, что читатель понимает основные идеи host fingerprinting и знаком с принципами функционирования протоколов TCP/IP. Мы рассмотрим методы снятия отпечатков как сервисов, слушающих порт, так и операционных систем в различных защищенных МСЭ средах и попытаемся выяснить преимущества и недостатки различных способов. Знакомство с hping и nmap очень пригодится для понимания изложенного материала.
введение
Удаленное снятие отпечатков - это процесс идентификации операционной системы хоста и сетевых служб, прослушивающих определенные порты, по сети. Обычно это производится различными способами активного и пассивного сканирования, путем отправки некоторого количества пакетов и анализа ответов. Вообще, общедоступные утилиты, в том числе и nmap, довольно неплохо выполняют сканирование и определение версии удаленной ОС. Но в тех случаях, когда хост находится за межсетевым экраном, эти утилиты мало чем могут помочь, либо выдают неоднозначные или неверные результаты. Это особенно справедливо для машин, трафик которых серьезно фильтруется МСЭ и которым разрешено принимать и отправлять очень небольшое количество типов пакетов. В этих случаях нам нужно использовать другие методы для правильного определения состояния удаленной машины. Мы рассмотрим некоторые из них, включая RING- и ICMP-сканирование. В первом разделе рассматриваются различные методы сканирования портов, тогда как вторая часть пытается пролить свет на снятие отпечатка операционной системы.
сканирование портов
Начнем с основных методик сканирования портов, с использованием таких утилит, как nmap и hping. Вначале мы обсудим общеизвестное SYN- и SYNACK- сканирование и поведение различных хостов при приеме таких TCP-пакетов. Затем рассмотрим, как различаются результаты сканирования машин находящихся за МСЭ и тех, чей трафик не фильтруется. После этого мы обратим внимание на некоторые продвинутые техники, включая FIN-сканирование и UDP-сканирование хостов, находящихся за МСЭ.
hping
Hping описывается как утилита, которая может эффективно использоваться для сканирования, снятия отпечатков и тестирования межсетевых экранов. Среди большего количества возможностей утилиты присутствует возможность отправки произвольных пакетов различных протоколов и выполнение удаленного сканирования. Это очень удобно при изучении ответов хоста на различные произвольные пакеты.
nmap
Network Mapper (nmap) это известная утилита для исследования сетей, которую можно использовать для сканирования портов и определения удаленной ОС. Широкий функционал утилиты включает в себя пассивное и idle-сканирование, хотя возможность отправки произвольных пакетов отсутствует.
cканирование с установлением наполовину открытого соединения (SYN)
Идея сканирования с установлением наполовину открытого соединения (также известного как SYN-сканирование) очень проста. Отсылается SYN-пакет и ожидается ответ. Если в ответ получено SYN ACK, это означает, что удаленный порт открыт, в противном случае, если получен пакет с флагом RST, порт закрыт. Как вы пониматете, техника предполагает, что трехэтапное установление TCP-соединения не производится.
фильтрованные и закрытые порты
Однако межсетевой экран может просто заблокировать доступ к каким-то открытым портам. В этих случаях говорят, что порт фильтрован. При таком раскладе мы никогда не получим ответ на наш SYN-пакет. Также многие МСЭ блокируют RST-пакеты, являющиеся «ответом от закрытого порта». В таких ситуациях сложно понять, какие порты закрыты, а какие фильтрованы. Ниже приводятся результаты сканирования с помощью nmap хоста без МСЭ.
root@life# nmap –P0 –p 1,2,21,80 202.83.174.99
Interesting ports on (202.83.174.99):
PORT STATE SERVICE
1/tcp closed tcpmux
2/tcp closed compressnet
21/tcp open ftp
80/tcp open http
Nmap finished: 1 IP address (1 host up) scanned in 1.140 seconds
Как можно заметить, данный хост не похож на находящийся за МСЭ. Мы просканировали порты 1, 2, 21, 80, и установили, что порты 1 и 2 закрыты, а оставшиеся два открыты. Рассмотрим другой пример.
root@life# nmap –P0 –p 1,2,21,80 209.41.165.180
Interesting ports on (209.41.165.180):
PORT STATE SERVICE
1/tcp filtered tcpmux
2/tcp filtered compressnet
21/tcp open ftp
80/tcp open http
Nmap finished: 1 IP address (1 host up) scanned in 4.047 seconds
Вы можете заметить, что первые два порта (1, 2) теперь помечены как filtered. По этим данным вы не можете определить, закрыты или открыты порты 1 и 2. Единственная доступная информация - это то, что порт фильтрован. Однако, как мы знаем, все закрытые порты, если они не фильтрованы, при нормальных обстоятельствах должны отсылать RST-пакет. Попробуем с помощью hping послать несколько произвольных пакетов на часто используемые порты и посмотреть на результат.
root@life# hping -S -p 80 -c 2 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
len=44 ip=209.41.165.180 ttl=63 DF
id=62648 sport=80 flags=SA seq=0
win=65535 rtt=2359.0 ms
len=44 ip=209.41.165.180 ttl=63 DF
id=63296 sport=80 flags=SA seq=1
win=65535 rtt=1359.0 ms
--- 209.41.165.180 hping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 1359.0/1859.0/2359.0 ms
Я использовал команду hping -S -p 80 -c 2 209.41.165.180 для отправки двух пакетов с установленным SYN-флагом на 80 порт, в ответ на которые мы получили два пакета с флагом SA, означающим подтверждение нашей попытки создания соединения (SYN acknowledgement). DF указывает на то, что установлен бит «do not fragment». Теперь вернемся к нашей предыдущей проблеме и отправим два таких же пакета на порт 1.
root@life# hping -S -p 1 -c 2 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
--- 209.41.165.180 hping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
В данном случае мы не получили ответа, что подтверждает то, что порт фильтруется МСЭ и любые типы ответов этого порта блокируются. Теперь отправим тот же пакет еще на несколько других портов.
root@life# hping -S -p ++20 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
len=44 ip=209.41.165.180 ttl=108 DF
id=9352 sport=21 flags=SA seq=1
win=16616 rtt=1062.0 ms
len=40 ip=209.41.165.180 ttl=108
id=10442 sport=22 flags=RA seq=2
win=0 rtt=562.0 ms
len=40 ip=209.41.165.180 ttl=108
id=11643 sport=23 flags=RA seq=3
win=0 rtt=562.0 ms
len=44 ip=209.41.165.180 ttl=108 DF
id=13778 sport=25 flags=SA seq=5
win=16616 rtt=562.0 ms
len=40 ip=209.41.165.180 ttl=108
id=40085 sport=49 flags=RA seq=29
win=0 rtt=562.0 ms
len=40 ip=209.41.165.180 ttl=108
id=40941 sport=50 flags=RA seq=30
win=0 rtt=562.0 ms
Я попросил hping отослать по одному SYN-пакету на каждый порт, начиная с 20. Мы можем заметить, что некоторые ответные пакеты имеют флаг RA (Reset Acknowledged), что указывает на то, что эти порты закрыты, а не фильтрованы. Так как мы не получили ответов с портов 20, 24, 26-48, можно сделать вывод, что эти порты заблокированы межсетевым экраном. Таким образом, это может указывать на то, что данные порты также закрыты. МСЭ может быть настроен так, что все часто используемые порты не будут фильтроваться. Как мы видим, порт 443 (который используется для https и обычно открыт) отвечает RST-пакетом, что говорит нам о том, https-сервис не запущен и не блокируется.
root@life#hping -S -p 443 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
len=40 ip=209.41.165.180 ttl=108
id=40924 sport=443 flags=RA seq=0
win=0 rtt=238.0 ms
тестирование с помощью FIN-пакетов
Метод основан на том, что если закрытый порт получает пакет с установленным флагом FIN, при нормальных условиях он ответит RST-пакетом. Открытые порты не отвечают на FIN-пакеты. Это может пригодиться в тех случаях, когда SYN-пакеты блокируются межсетевым экраном. Однако это не применимо при сканировании Windows-компьютеров вследствие того, что они никогда не отвечают на FIN-пакеты. Давайте создадим два хоста в VMWare. На один из хостов установим Linux, а с другого будем отправлять FIN-пакеты. Начнем с того, что заблокируем весь нормальный SYN-трафик на Linux-хосте. Чтобы заблокировать все входящие пакеты с установленным флагом SYN, мы воспользуемся iptables.
iptables
Iptables – это основная утилита ОС Linux, используемая для фильтрации сетевых пакетов. Iptables организует правила файрволла в виде так называемых таблиц (есть 3 встроенные таблицы, но можно добавить и свои), каждая из которых содержит некоторые заранее определенные цепочки (chains). Таблица filter отвечает за фильтрацию (блокирование или разрешение) и содержит три встроенные цепочки, названные INPUT, OUTPUT и FORWARD.
Таким образом, для блокирования всех TCP-пакетов с установленным флагом SYN, нам всего лишь нужно добавить соответствующее правило в цепочку INPUT.
life1# iptables –A INPUT –p tcp –tcpflags SYN –j DROP
Теперь начнем тестирование и отправим несколько FIN-пакетов с Windows-машины (в данном случае я использовал версию hping для Windows, запущенную на Windows 2000). По умолчанию наш Linux-хост прослушивает порты 21, 22 и 80.
Ниже приведены результаты отправки SYN-пакетов на порт 80.
E:\hping>hping –S –p 80 –c 10 LIFE1
HPING LIFE1 (LAN eth1) Interface 192.168.10.2): S set, 40 headers + 0
data bytes
--- LIFE1 hping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Как мы видим, все 10 отправленных пакетов были потеряны. Если мы попробуем отправить SYN-пакеты на закрытый порт, получим тот же результат.
E:\hping>hping –S –p 50 –c 10 LIFE1
HPING LIFE1 (LAN eth1) Interface 192.168.10.2): S set, 40 headers + 0
data bytes
--- LIFE1 hping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Теперь попробуем отправить пакеты с флагом FIN.
E:\hping>hping –F –p 50 LIFE1
HPING LIFE1 (LAN eth1) Interface 192.168.10.2): F set, 40 headers + 0
data bytes
len=40 ip=202.83.174.99 ttl=56
id=30859 sport=50 flags=RA seq=0
win=0 rtt=24.0 ms
len=40 ip=202.83.174.99 ttl=56
id=30863 sport=50 flags=RA seq=1
win=0 rtt=14.0 ms
В результате отправки FIN-пакетов на закрытый порт, ранее не отвечавший, мы получили пакеты с флагом RA, что является индикатором того, что порт закрыт. Читатель может проверить, те же самые пакеты на порты 21, 22 и 80 не имеют ответов, что доказывает то, что они открыты, тогда как все другие порты отвечают RA.
UDP-порты
Сканирование UDP портов – непростое занятие из-за ненадежности получаемых результатов. Стандартный способ состоит в отправке пакетов на UDP- порты и идентификации открытых портов на основании того, что обычно от закрытых портов приходит ICMP-сообщение «Port Unreachable». Однако, не факт, что во всех случаях вы получите такой ответ.
Ниже показан результат сканирования UDP-портов с помощью nmap.
root@life#nmap -sU -p 21,53,80 yns1.yahoo.com
Interesting ports on 66.218.71.205:
PORT STATE SERVICE
21/udp open|filtered ftp
53/udp open|filtered domain
80/udp open|filtered http
Nmap finished: 1 IP address (1 host up) scanned in 3.141 seconds
Полученные результаты не кажутся интересными, так как nmap не смог определить, какие порты открыты, а какие фильтрованы или закрыты. По результатам сканирования все три порта или открыты или фильтрованы, что является неверной информацией.
Так как сканируемый хост – DNS-сервер, высока вероятность того, что его 53 UDP-порт открыт для DNS-запросов. Попробуем просканировать его с помощью hping. Применив стандартный метод UDP-сканирования, мы также не получили ответа.
root@life#hping -2 -p 50++ yns1.yahoo.com
HPING yns1.yahoo.com (WAN (PPP/SLIP) Interface 66.218.71.205): udp mode
set, 28 headers + 0 data bytes
6 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Изменим нашу стратегию. Для начала создадим простой текстовой файл произвольного содержания, размером примерно 120 байт, и снова просканируем хост, используя этот файл в качестве полезной нагрузки каждого пакета. Одновременно запустим tcpdump в promisc-режиме для просмотра всего сетевого трафика.
root@life/tmp#tcpdump
root@life#hping -2 -p ++50 -d 120 –E file.txt yns1.yahoo.com
HPING yns1.yahoo.com (WAN (PPP/SLIP) Interface 66.218.71.205): udp mode
set, 28 headers + 120 data bytes
len=46 ip=66.218.71.205 ttl=49
id=37187 seq=3 rtt=531.0 ms
Как легко догадаться, для дальнейшего анализа мы будем использовать вывод tcpdump.
root@life#tcpdump
tcpdump: listening on \Device\NPF_GenericDialupAdapter
00:42:50.484375 IP life.2950 >yns1.yahoo.com.50: UDP, length 120
00:42:51.484375 IP life.2951 >yns1.yahoo.com.51: UDP, length 120
00:42:52.484375 IP life.2952 >yns1.yahoo.com.52: UDP, length 120
00:42:53.484375 IP life.2953 >yns1.yahoo.com.53: 24930 updateM+
[b2&3=0x6364][24930a] [25958q] [25444n] [25958au][|domain]
00:42:53.953125 IP yns1.yahoo.com.53 >life.2953: 24930 updateM FormErr- [0q] 0 /0/0 (12)
00:42:53.953125 IP life >yns1.yahoo.com: ICMP life udp port 2953 unreachable, length 36
00:42:54.484375 IP life.2954 >yns1.yahoo.com.54: UDP, length 120
Обратите внимание на то, что, приняв наши данные, 53 UDP порт ответил сообщением об ошибке, что говорит нам о том, что этот порт открыт. Ответов на все остальные пакеты не было. Другой способ сканирования состоит в проверке ответных ICMP сообщений. Обычно, при отправке пакетов без полезной нагрузки на закрытый UDP-порт, система отвечает ICMP-сообщением Port Unreachable. Открытые порты на такие пакеты не отвечают. Это продемонстрировано в следующем примере.
root@life#hping -2 -p 11 –c 3 202.179.137.59
HPING 202.179.137.59 (WAN (PPP/SLIP) Interface 202.179.137.59): udp mode
set, 28 headers + 0 data bytes
ICMP Port Unreachable from ip=202.179.137.59
ICMP Port Unreachable from ip=202.179.137.59
ICMP Port Unreachable from ip=202.179.137.59
--- 202.179.137.59 hping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Как вы могли заметить, я отправил три пакета на 11 UDP-порт и получил три ICMP-сообщения Port Unreachable. Такие исходящие пакеты обычно блокируются межсетевым экраном, но в предыдущем примере мы показали способ обхода правил МСЭ.
снятие «отпечатка пальцев» ОС
Идентификация систем, находящихся за МСЭ, усложнено из-за того, что межсетевой экран может изменять TCP/IP-пакеты, вводя в заблуждения исследователя системы. Методы снятия отпечатков пальцев ОС (fingerprinting) подразделяются на пассивные и активные.
пассивное снятие отпечатков
В случае пассивного снятия отпечатков на целевой хост не отправляется никаких пакетов. Вместо этого используется некоторый промежуточный хост (компьютер-зомби) и делается попытки определить ОС целевого хоста, подсчитывая разницу между значениями IPID. Этот метод известен как idle scan. Также попытаться определить целевую ОС можно, получив доступ к входящему и исходящему трафику целевого хоста каким-либо другим способом. Не рассматривая эти способы, давайте сразу перейдем к активному методу.
активное снятие отпечатков
При активном снятии отпечатков на целевой хост отправляются произвольные пакеты и делается попытка определения ОС на основании таких значений полей заголовка ответных TCP/IP-пакетов, как временные характеристики или IPID, TOS, TCP ISN, флаг фрагментации и т. д. Другой старый метод определения удаленной ОС состоит в анализе значения TTL ICMP echo-пакета. Это простой способ, однако он не может выявить различия разных вариантов одной и той же ОС, например Windows 98, XP и 2000.
Обычно в каждой ОС установлено фиксированное, заранее определенное, значение TTL. В операционных системах Microsoft это значение по умолчанию равно 128, тогда как в Linux - 256. Ниже показан пример определения удаленной ОС по значению TTL ответного ICMP echo пакета. Я просто пингую целевую машину и проверяю значение TTL полученного в ответ пакета. В данном случае оно равно 113, что позволяет предположить, что удаленная ОС принадлежит к семейству Windows, так как стартовое значение TTL этих систем равно 128, а маршрут от моей машины до целевой составляет примерно 15 промежуточных хостов (113 + 15 = 128), что может быть проверено с помощью traceroute.
E:\>ping 209.41.165.180
Pinging 209.41.165.180 with 32 bytes of data:
Reply from 209.41.165.180: bytes=32 time 38ms TTL=113
Reply from 209.41.165.180: bytes=32 time 51ms TTL=113
Ping statistics for 209.41.165.180:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss), отдел адм практики 9 12
Approximate round trip times in milliseconds:
Minimum = 38ms, Maximum = 51ms, Average = 44ms
Нужно учитывать, что это не самый надежный метод. Если целевой хост является маршрутизатором или находится за NAT (Network Address Translation), описанный способ потерпит неудачу. Не вдаваясь в подробности известных методик снятия отпечатка удаленной ОС, используемых в утилитах типа nmap, я опишу способ, сложный в реализации, но дающий хорошие результаты по опознаванию удаленной ОС. Этот способ известен как RING scan и имеет программную реализацию. Суть методики в отправке произвольных SYN-пакетов на открытый порт и ожидании SYN ACK пакетов. После получения SYN ACK пакета, он молча блокируется, что заставляет удаленный хост заново переслать его по истечению таймаута. Вычисляя задержку между такими SYN ACK пакетами для различных хостов, вы можете собрать статистику задержек для различных операционных систем. Эти данные можно эффективно использовать для опознавания ОС, имеющих сходный тип TCP стека и находящихся за МСЭ, например FreeBSD и Windows 2000, в которых используется одинаковый тип TCP стека. Я привожу пример, в котором nmap не смог верно определить ОС на двух хостах, ошибочно приняв обе за FreeBSD по той причине, что один из хостов находился за межсетевым экраном.
Сканируем первый хост (202.83.174.99):
Interesting ports on ntc.net.pk (202.83.174.99):
(The 97 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
Device type: general purpose
Running: FreeBSD 4.X
OS details: FreeBSD 4.6.2-RELEASE - 4.8-RELEASE
Данные другого хоста (202.83.162.27):
Interesting ports on 202.83.162.27:
(The 99 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
80/tcp open http
Device type: general purpose
Running: FreeBSD 4.X|5.X
OS details: FreeBSD 4.3 - 4.4PRERELEASE, FreeBSD 4.9 - 5.1, FreeBSD 5.0-RELEASE,
Теперь попробуем применить описанную выше SYN ACK методику. Для начала мы должны настроить локальный МСЭ на тихое блокирование всех SYN ACK пакетов, приходящих с удаленного хоста.
life1# iptables –A INPUT –p tcp –j DROP –s 202.83.162.27
Теперь отправим SYN пакет на открытый 80 порт и начнем слежение за выводом tcpdump.
root@life# hping -S -p 80 -c 1 202.83.162.27
17:22:51.079596 202.134.134.230.1816 >202.83.162.27.http: S win 512
17:22:51.208938 202.83.162.27.http >202.134.134.230.1816: S ack win 5840
17:22:53.218939 202.83.162.27.http >202.134.134.230.1816: S ack win 5840
17:23:57.218939 202.83.162.27.http >202.134.134.230.1816: S ack win 5840
17:23:03.218939 202.83.162.27.http >202.134.134.230.1816: S ack win 5840
17:23:11.468939 202.83.162.27.http >202.134.134.230.1816: S ack win 5840
17:24:21.618938 202.83.162.27.http >202.134.134.230.1816: S ack win 5840
Разница во времени, между получением SYN ACK пакетов составляет примерно 2, 4, 5, 7 и 10 секунд.
Теперь проделаем те же действия над первым хостом, для которого достоверно известно, что на нем запущена ОС FreeBSD. Ниже приводится вывод tcpdump.
root@life# hping -S -p 80 -c 1 202.83.174.99
17:45:50.019746 202.134.134.230.2644 >202.83.174.99.http: S win 512
17:45:50.148940 202.83.174.99.http >202.134.134.230.2644: S ack win 5840
17:45:54.108939 202.83.174.99.http >202.134.134.230.2644: S ack win 5840
17:46:00.108939 202.83.174.99.http >202.134.134.230.2644: S ack win 5840
17:46:12.308939 202.83.174.99.http >202.134.134.230.2644: S ack win 5840
17:46:36.378938 202.83.174.99.http >202.134.134.230.2644: S ack win 5840
В данном случае разница во времени составляет примерно 4, 5, 12 и 24 секунды, причем после четвертого полученного SYN ACK пакета их отправка закончилась. Эксперименты с другими хостами показали, что задержки повторной передачи SYN ACK пакетов системы FreeBSD составляют примерно 3, 6, 12, 24 секунды, а Windows-хостов соответственно 2, 4, 6, 8, 10 секунд. Это информация может быть полезной для правильного опознавания операционной системы в тех случаях, когда другие методы терпят неудачу и дают неверные результаты. Обратите внимание на то, что представленные выше значения не очень точны и были получены в результате опытов с двумя хостами, на одном из которых установлена Windows 2000, а на другом FreeBSD 4.6. Исследовав несколько десятков хостов можно получить более точные данные. Описанная методика имеет несколько производных от нее, например, вместо проверки времени задержки ответных SYN ACK пакетов, можно продолжить стандартное трехфазовое TCP соединение, а затем закрыть его, отослав FIN пакет, но при этом не отправлять никаких подтверждений на ответные FIN ACK пакеты:
Host1 ->SYN ->Host 2
Host2 ->SYN ACK ->Host1
Host1 ->ACK ->Host2
Host1 ->FIN ->Host2
Host2 ->FIN ACK ->Host1
Host2 ->FIN ACK ->Host1
Host2 ->FIN ACK ->Host1
И так далее..
Первый хост (Host1) не отправляет ответов на FIN ACK пакеты второго хоста (Host2). Кроме этого, можно еще использовать RST-пакеты.
заключение
Автоматизированные способы снятия отпечатков удаленной системы могут давать неплохие результаты, однако в некоторых средах они не всегда эффективны. В этих случаях для получения наиболее точных результатов нужно комбинировать несколько различных методик. Приемы, описанные в этой статье, применяются “вручную” и могут использоваться для получения дополнительной информации об устройстве и функционировании сети. Приведенные подходы не единственные, например, из-за широты тематики не описывались методы пассивного снятия отпечатков.
Большинство межсетевых защит блокируют некоторые типы трафика и часто затрудняют идентификацию находящихся за ними систем. Однако тщательное изучение их поведения может помочь опознаванию закрытых, фильтрованных и открытых TCP- и UDP-портов, а также определению операционной системы удаленного хоста.
Naveed Afzal, National University Of Computer and Emerging Sciences, Lahore, Pakistan, перевод Владимира Куксенка.
Предполагается, что читатель понимает основные идеи host fingerprinting и знаком с принципами функционирования протоколов TCP/IP. Мы рассмотрим методы снятия отпечатков как сервисов, слушающих порт, так и операционных систем в различных защищенных МСЭ средах и попытаемся выяснить преимущества и недостатки различных способов. Знакомство с hping и nmap очень пригодится для понимания изложенного материала.
введение
Удаленное снятие отпечатков - это процесс идентификации операционной системы хоста и сетевых служб, прослушивающих определенные порты, по сети. Обычно это производится различными способами активного и пассивного сканирования, путем отправки некоторого количества пакетов и анализа ответов. Вообще, общедоступные утилиты, в том числе и nmap, довольно неплохо выполняют сканирование и определение версии удаленной ОС. Но в тех случаях, когда хост находится за межсетевым экраном, эти утилиты мало чем могут помочь, либо выдают неоднозначные или неверные результаты. Это особенно справедливо для машин, трафик которых серьезно фильтруется МСЭ и которым разрешено принимать и отправлять очень небольшое количество типов пакетов. В этих случаях нам нужно использовать другие методы для правильного определения состояния удаленной машины. Мы рассмотрим некоторые из них, включая RING- и ICMP-сканирование. В первом разделе рассматриваются различные методы сканирования портов, тогда как вторая часть пытается пролить свет на снятие отпечатка операционной системы.
сканирование портов
Начнем с основных методик сканирования портов, с использованием таких утилит, как nmap и hping. Вначале мы обсудим общеизвестное SYN- и SYNACK- сканирование и поведение различных хостов при приеме таких TCP-пакетов. Затем рассмотрим, как различаются результаты сканирования машин находящихся за МСЭ и тех, чей трафик не фильтруется. После этого мы обратим внимание на некоторые продвинутые техники, включая FIN-сканирование и UDP-сканирование хостов, находящихся за МСЭ.
hping
Hping описывается как утилита, которая может эффективно использоваться для сканирования, снятия отпечатков и тестирования межсетевых экранов. Среди большего количества возможностей утилиты присутствует возможность отправки произвольных пакетов различных протоколов и выполнение удаленного сканирования. Это очень удобно при изучении ответов хоста на различные произвольные пакеты.
nmap
Network Mapper (nmap) это известная утилита для исследования сетей, которую можно использовать для сканирования портов и определения удаленной ОС. Широкий функционал утилиты включает в себя пассивное и idle-сканирование, хотя возможность отправки произвольных пакетов отсутствует.
cканирование с установлением наполовину открытого соединения (SYN)
Идея сканирования с установлением наполовину открытого соединения (также известного как SYN-сканирование) очень проста. Отсылается SYN-пакет и ожидается ответ. Если в ответ получено SYN ACK, это означает, что удаленный порт открыт, в противном случае, если получен пакет с флагом RST, порт закрыт. Как вы пониматете, техника предполагает, что трехэтапное установление TCP-соединения не производится.
фильтрованные и закрытые порты
Однако межсетевой экран может просто заблокировать доступ к каким-то открытым портам. В этих случаях говорят, что порт фильтрован. При таком раскладе мы никогда не получим ответ на наш SYN-пакет. Также многие МСЭ блокируют RST-пакеты, являющиеся «ответом от закрытого порта». В таких ситуациях сложно понять, какие порты закрыты, а какие фильтрованы. Ниже приводятся результаты сканирования с помощью nmap хоста без МСЭ.
root@life# nmap –P0 –p 1,2,21,80 202.83.174.99
Interesting ports on (202.83.174.99):
PORT STATE SERVICE
1/tcp closed tcpmux
2/tcp closed compressnet
21/tcp open ftp
80/tcp open http
Nmap finished: 1 IP address (1 host up) scanned in 1.140 seconds
Как можно заметить, данный хост не похож на находящийся за МСЭ. Мы просканировали порты 1, 2, 21, 80, и установили, что порты 1 и 2 закрыты, а оставшиеся два открыты. Рассмотрим другой пример.
root@life# nmap –P0 –p 1,2,21,80 209.41.165.180
Interesting ports on (209.41.165.180):
PORT STATE SERVICE
1/tcp filtered tcpmux
2/tcp filtered compressnet
21/tcp open ftp
80/tcp open http
Nmap finished: 1 IP address (1 host up) scanned in 4.047 seconds
Вы можете заметить, что первые два порта (1, 2) теперь помечены как filtered. По этим данным вы не можете определить, закрыты или открыты порты 1 и 2. Единственная доступная информация - это то, что порт фильтрован. Однако, как мы знаем, все закрытые порты, если они не фильтрованы, при нормальных обстоятельствах должны отсылать RST-пакет. Попробуем с помощью hping послать несколько произвольных пакетов на часто используемые порты и посмотреть на результат.
root@life# hping -S -p 80 -c 2 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
len=44 ip=209.41.165.180 ttl=63 DF
id=62648 sport=80 flags=SA seq=0
win=65535 rtt=2359.0 ms
len=44 ip=209.41.165.180 ttl=63 DF
id=63296 sport=80 flags=SA seq=1
win=65535 rtt=1359.0 ms
--- 209.41.165.180 hping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 1359.0/1859.0/2359.0 ms
Я использовал команду hping -S -p 80 -c 2 209.41.165.180 для отправки двух пакетов с установленным SYN-флагом на 80 порт, в ответ на которые мы получили два пакета с флагом SA, означающим подтверждение нашей попытки создания соединения (SYN acknowledgement). DF указывает на то, что установлен бит «do not fragment». Теперь вернемся к нашей предыдущей проблеме и отправим два таких же пакета на порт 1.
root@life# hping -S -p 1 -c 2 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
--- 209.41.165.180 hping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
В данном случае мы не получили ответа, что подтверждает то, что порт фильтруется МСЭ и любые типы ответов этого порта блокируются. Теперь отправим тот же пакет еще на несколько других портов.
root@life# hping -S -p ++20 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
len=44 ip=209.41.165.180 ttl=108 DF
id=9352 sport=21 flags=SA seq=1
win=16616 rtt=1062.0 ms
len=40 ip=209.41.165.180 ttl=108
id=10442 sport=22 flags=RA seq=2
win=0 rtt=562.0 ms
len=40 ip=209.41.165.180 ttl=108
id=11643 sport=23 flags=RA seq=3
win=0 rtt=562.0 ms
len=44 ip=209.41.165.180 ttl=108 DF
id=13778 sport=25 flags=SA seq=5
win=16616 rtt=562.0 ms
len=40 ip=209.41.165.180 ttl=108
id=40085 sport=49 flags=RA seq=29
win=0 rtt=562.0 ms
len=40 ip=209.41.165.180 ttl=108
id=40941 sport=50 flags=RA seq=30
win=0 rtt=562.0 ms
Я попросил hping отослать по одному SYN-пакету на каждый порт, начиная с 20. Мы можем заметить, что некоторые ответные пакеты имеют флаг RA (Reset Acknowledged), что указывает на то, что эти порты закрыты, а не фильтрованы. Так как мы не получили ответов с портов 20, 24, 26-48, можно сделать вывод, что эти порты заблокированы межсетевым экраном. Таким образом, это может указывать на то, что данные порты также закрыты. МСЭ может быть настроен так, что все часто используемые порты не будут фильтроваться. Как мы видим, порт 443 (который используется для https и обычно открыт) отвечает RST-пакетом, что говорит нам о том, https-сервис не запущен и не блокируется.
root@life#hping -S -p 443 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
len=40 ip=209.41.165.180 ttl=108
id=40924 sport=443 flags=RA seq=0
win=0 rtt=238.0 ms
тестирование с помощью FIN-пакетов
Метод основан на том, что если закрытый порт получает пакет с установленным флагом FIN, при нормальных условиях он ответит RST-пакетом. Открытые порты не отвечают на FIN-пакеты. Это может пригодиться в тех случаях, когда SYN-пакеты блокируются межсетевым экраном. Однако это не применимо при сканировании Windows-компьютеров вследствие того, что они никогда не отвечают на FIN-пакеты. Давайте создадим два хоста в VMWare. На один из хостов установим Linux, а с другого будем отправлять FIN-пакеты. Начнем с того, что заблокируем весь нормальный SYN-трафик на Linux-хосте. Чтобы заблокировать все входящие пакеты с установленным флагом SYN, мы воспользуемся iptables.
iptables
Iptables – это основная утилита ОС Linux, используемая для фильтрации сетевых пакетов. Iptables организует правила файрволла в виде так называемых таблиц (есть 3 встроенные таблицы, но можно добавить и свои), каждая из которых содержит некоторые заранее определенные цепочки (chains). Таблица filter отвечает за фильтрацию (блокирование или разрешение) и содержит три встроенные цепочки, названные INPUT, OUTPUT и FORWARD.
Таким образом, для блокирования всех TCP-пакетов с установленным флагом SYN, нам всего лишь нужно добавить соответствующее правило в цепочку INPUT.
life1# iptables –A INPUT –p tcp –tcpflags SYN –j DROP
Теперь начнем тестирование и отправим несколько FIN-пакетов с Windows-машины (в данном случае я использовал версию hping для Windows, запущенную на Windows 2000). По умолчанию наш Linux-хост прослушивает порты 21, 22 и 80.
Ниже приведены результаты отправки SYN-пакетов на порт 80.
E:\hping>hping –S –p 80 –c 10 LIFE1
HPING LIFE1 (LAN eth1) Interface 192.168.10.2): S set, 40 headers + 0
data bytes
--- LIFE1 hping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Как мы видим, все 10 отправленных пакетов были потеряны. Если мы попробуем отправить SYN-пакеты на закрытый порт, получим тот же результат.
E:\hping>hping –S –p 50 –c 10 LIFE1
HPING LIFE1 (LAN eth1) Interface 192.168.10.2): S set, 40 headers + 0
data bytes
--- LIFE1 hping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Теперь попробуем отправить пакеты с флагом FIN.
E:\hping>hping –F –p 50 LIFE1
HPING LIFE1 (LAN eth1) Interface 192.168.10.2): F set, 40 headers + 0
data bytes
len=40 ip=202.83.174.99 ttl=56
id=30859 sport=50 flags=RA seq=0
win=0 rtt=24.0 ms
len=40 ip=202.83.174.99 ttl=56
id=30863 sport=50 flags=RA seq=1
win=0 rtt=14.0 ms
В результате отправки FIN-пакетов на закрытый порт, ранее не отвечавший, мы получили пакеты с флагом RA, что является индикатором того, что порт закрыт. Читатель может проверить, те же самые пакеты на порты 21, 22 и 80 не имеют ответов, что доказывает то, что они открыты, тогда как все другие порты отвечают RA.
UDP-порты
Сканирование UDP портов – непростое занятие из-за ненадежности получаемых результатов. Стандартный способ состоит в отправке пакетов на UDP- порты и идентификации открытых портов на основании того, что обычно от закрытых портов приходит ICMP-сообщение «Port Unreachable». Однако, не факт, что во всех случаях вы получите такой ответ.
Ниже показан результат сканирования UDP-портов с помощью nmap.
root@life#nmap -sU -p 21,53,80 yns1.yahoo.com
Interesting ports on 66.218.71.205:
PORT STATE SERVICE
21/udp open|filtered ftp
53/udp open|filtered domain
80/udp open|filtered http
Nmap finished: 1 IP address (1 host up) scanned in 3.141 seconds
Полученные результаты не кажутся интересными, так как nmap не смог определить, какие порты открыты, а какие фильтрованы или закрыты. По результатам сканирования все три порта или открыты или фильтрованы, что является неверной информацией.
Так как сканируемый хост – DNS-сервер, высока вероятность того, что его 53 UDP-порт открыт для DNS-запросов. Попробуем просканировать его с помощью hping. Применив стандартный метод UDP-сканирования, мы также не получили ответа.
root@life#hping -2 -p 50++ yns1.yahoo.com
HPING yns1.yahoo.com (WAN (PPP/SLIP) Interface 66.218.71.205): udp mode
set, 28 headers + 0 data bytes
6 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Изменим нашу стратегию. Для начала создадим простой текстовой файл произвольного содержания, размером примерно 120 байт, и снова просканируем хост, используя этот файл в качестве полезной нагрузки каждого пакета. Одновременно запустим tcpdump в promisc-режиме для просмотра всего сетевого трафика.
root@life/tmp#tcpdump
root@life#hping -2 -p ++50 -d 120 –E file.txt yns1.yahoo.com
HPING yns1.yahoo.com (WAN (PPP/SLIP) Interface 66.218.71.205): udp mode
set, 28 headers + 120 data bytes
len=46 ip=66.218.71.205 ttl=49
id=37187 seq=3 rtt=531.0 ms
Как легко догадаться, для дальнейшего анализа мы будем использовать вывод tcpdump.
root@life#tcpdump
tcpdump: listening on \Device\NPF_GenericDialupAdapter
00:42:50.484375 IP life.2950 >yns1.yahoo.com.50: UDP, length 120
00:42:51.484375 IP life.2951 >yns1.yahoo.com.51: UDP, length 120
00:42:52.484375 IP life.2952 >yns1.yahoo.com.52: UDP, length 120
00:42:53.484375 IP life.2953 >yns1.yahoo.com.53: 24930 updateM+
[b2&3=0x6364][24930a] [25958q] [25444n] [25958au][|domain]
00:42:53.953125 IP yns1.yahoo.com.53 >life.2953: 24930 updateM FormErr- [0q] 0 /0/0 (12)
00:42:53.953125 IP life >yns1.yahoo.com: ICMP life udp port 2953 unreachable, length 36
00:42:54.484375 IP life.2954 >yns1.yahoo.com.54: UDP, length 120
Обратите внимание на то, что, приняв наши данные, 53 UDP порт ответил сообщением об ошибке, что говорит нам о том, что этот порт открыт. Ответов на все остальные пакеты не было. Другой способ сканирования состоит в проверке ответных ICMP сообщений. Обычно, при отправке пакетов без полезной нагрузки на закрытый UDP-порт, система отвечает ICMP-сообщением Port Unreachable. Открытые порты на такие пакеты не отвечают. Это продемонстрировано в следующем примере.
root@life#hping -2 -p 11 –c 3 202.179.137.59
HPING 202.179.137.59 (WAN (PPP/SLIP) Interface 202.179.137.59): udp mode
set, 28 headers + 0 data bytes
ICMP Port Unreachable from ip=202.179.137.59
ICMP Port Unreachable from ip=202.179.137.59
ICMP Port Unreachable from ip=202.179.137.59
--- 202.179.137.59 hping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Как вы могли заметить, я отправил три пакета на 11 UDP-порт и получил три ICMP-сообщения Port Unreachable. Такие исходящие пакеты обычно блокируются межсетевым экраном, но в предыдущем примере мы показали способ обхода правил МСЭ.
снятие «отпечатка пальцев» ОС
Идентификация систем, находящихся за МСЭ, усложнено из-за того, что межсетевой экран может изменять TCP/IP-пакеты, вводя в заблуждения исследователя системы. Методы снятия отпечатков пальцев ОС (fingerprinting) подразделяются на пассивные и активные.
пассивное снятие отпечатков
В случае пассивного снятия отпечатков на целевой хост не отправляется никаких пакетов. Вместо этого используется некоторый промежуточный хост (компьютер-зомби) и делается попытки определить ОС целевого хоста, подсчитывая разницу между значениями IPID. Этот метод известен как idle scan. Также попытаться определить целевую ОС можно, получив доступ к входящему и исходящему трафику целевого хоста каким-либо другим способом. Не рассматривая эти способы, давайте сразу перейдем к активному методу.
активное снятие отпечатков
При активном снятии отпечатков на целевой хост отправляются произвольные пакеты и делается попытка определения ОС на основании таких значений полей заголовка ответных TCP/IP-пакетов, как временные характеристики или IPID, TOS, TCP ISN, флаг фрагментации и т. д. Другой старый метод определения удаленной ОС состоит в анализе значения TTL ICMP echo-пакета. Это простой способ, однако он не может выявить различия разных вариантов одной и той же ОС, например Windows 98, XP и 2000.
Обычно в каждой ОС установлено фиксированное, заранее определенное, значение TTL. В операционных системах Microsoft это значение по умолчанию равно 128, тогда как в Linux - 256. Ниже показан пример определения удаленной ОС по значению TTL ответного ICMP echo пакета. Я просто пингую целевую машину и проверяю значение TTL полученного в ответ пакета. В данном случае оно равно 113, что позволяет предположить, что удаленная ОС принадлежит к семейству Windows, так как стартовое значение TTL этих систем равно 128, а маршрут от моей машины до целевой составляет примерно 15 промежуточных хостов (113 + 15 = 128), что может быть проверено с помощью traceroute.
E:\>ping 209.41.165.180
Pinging 209.41.165.180 with 32 bytes of data:
Reply from 209.41.165.180: bytes=32 time 38ms TTL=113
Reply from 209.41.165.180: bytes=32 time 51ms TTL=113
Ping statistics for 209.41.165.180:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss), отдел адм практики 9 12
Approximate round trip times in milliseconds:
Minimum = 38ms, Maximum = 51ms, Average = 44ms
Нужно учитывать, что это не самый надежный метод. Если целевой хост является маршрутизатором или находится за NAT (Network Address Translation), описанный способ потерпит неудачу. Не вдаваясь в подробности известных методик снятия отпечатка удаленной ОС, используемых в утилитах типа nmap, я опишу способ, сложный в реализации, но дающий хорошие результаты по опознаванию удаленной ОС. Этот способ известен как RING scan и имеет программную реализацию. Суть методики в отправке произвольных SYN-пакетов на открытый порт и ожидании SYN ACK пакетов. После получения SYN ACK пакета, он молча блокируется, что заставляет удаленный хост заново переслать его по истечению таймаута. Вычисляя задержку между такими SYN ACK пакетами для различных хостов, вы можете собрать статистику задержек для различных операционных систем. Эти данные можно эффективно использовать для опознавания ОС, имеющих сходный тип TCP стека и находящихся за МСЭ, например FreeBSD и Windows 2000, в которых используется одинаковый тип TCP стека. Я привожу пример, в котором nmap не смог верно определить ОС на двух хостах, ошибочно приняв обе за FreeBSD по той причине, что один из хостов находился за межсетевым экраном.
Сканируем первый хост (202.83.174.99):
Interesting ports on ntc.net.pk (202.83.174.99):
(The 97 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
Device type: general purpose
Running: FreeBSD 4.X
OS details: FreeBSD 4.6.2-RELEASE - 4.8-RELEASE
Данные другого хоста (202.83.162.27):
Interesting ports on 202.83.162.27:
(The 99 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
80/tcp open http
Device type: general purpose
Running: FreeBSD 4.X|5.X
OS details: FreeBSD 4.3 - 4.4PRERELEASE, FreeBSD 4.9 - 5.1, FreeBSD 5.0-RELEASE,
Теперь попробуем применить описанную выше SYN ACK методику. Для начала мы должны настроить локальный МСЭ на тихое блокирование всех SYN ACK пакетов, приходящих с удаленного хоста.
life1# iptables –A INPUT –p tcp –j DROP –s 202.83.162.27
Теперь отправим SYN пакет на открытый 80 порт и начнем слежение за выводом tcpdump.
root@life# hping -S -p 80 -c 1 202.83.162.27
17:22:51.079596 202.134.134.230.1816 >202.83.162.27.http: S win 512
17:22:51.208938 202.83.162.27.http >202.134.134.230.1816: S ack win 5840
17:22:53.218939 202.83.162.27.http >202.134.134.230.1816: S ack win 5840
17:23:57.218939 202.83.162.27.http >202.134.134.230.1816: S ack win 5840
17:23:03.218939 202.83.162.27.http >202.134.134.230.1816: S ack win 5840
17:23:11.468939 202.83.162.27.http >202.134.134.230.1816: S ack win 5840
17:24:21.618938 202.83.162.27.http >202.134.134.230.1816: S ack win 5840
Разница во времени, между получением SYN ACK пакетов составляет примерно 2, 4, 5, 7 и 10 секунд.
Теперь проделаем те же действия над первым хостом, для которого достоверно известно, что на нем запущена ОС FreeBSD. Ниже приводится вывод tcpdump.
root@life# hping -S -p 80 -c 1 202.83.174.99
17:45:50.019746 202.134.134.230.2644 >202.83.174.99.http: S win 512
17:45:50.148940 202.83.174.99.http >202.134.134.230.2644: S ack win 5840
17:45:54.108939 202.83.174.99.http >202.134.134.230.2644: S ack win 5840
17:46:00.108939 202.83.174.99.http >202.134.134.230.2644: S ack win 5840
17:46:12.308939 202.83.174.99.http >202.134.134.230.2644: S ack win 5840
17:46:36.378938 202.83.174.99.http >202.134.134.230.2644: S ack win 5840
В данном случае разница во времени составляет примерно 4, 5, 12 и 24 секунды, причем после четвертого полученного SYN ACK пакета их отправка закончилась. Эксперименты с другими хостами показали, что задержки повторной передачи SYN ACK пакетов системы FreeBSD составляют примерно 3, 6, 12, 24 секунды, а Windows-хостов соответственно 2, 4, 6, 8, 10 секунд. Это информация может быть полезной для правильного опознавания операционной системы в тех случаях, когда другие методы терпят неудачу и дают неверные результаты. Обратите внимание на то, что представленные выше значения не очень точны и были получены в результате опытов с двумя хостами, на одном из которых установлена Windows 2000, а на другом FreeBSD 4.6. Исследовав несколько десятков хостов можно получить более точные данные. Описанная методика имеет несколько производных от нее, например, вместо проверки времени задержки ответных SYN ACK пакетов, можно продолжить стандартное трехфазовое TCP соединение, а затем закрыть его, отослав FIN пакет, но при этом не отправлять никаких подтверждений на ответные FIN ACK пакеты:
Host1 ->SYN ->Host 2
Host2 ->SYN ACK ->Host1
Host1 ->ACK ->Host2
Host1 ->FIN ->Host2
Host2 ->FIN ACK ->Host1
Host2 ->FIN ACK ->Host1
Host2 ->FIN ACK ->Host1
И так далее..
Первый хост (Host1) не отправляет ответов на FIN ACK пакеты второго хоста (Host2). Кроме этого, можно еще использовать RST-пакеты.
заключение
Автоматизированные способы снятия отпечатков удаленной системы могут давать неплохие результаты, однако в некоторых средах они не всегда эффективны. В этих случаях для получения наиболее точных результатов нужно комбинировать несколько различных методик. Приемы, описанные в этой статье, применяются “вручную” и могут использоваться для получения дополнительной информации об устройстве и функционировании сети. Приведенные подходы не единственные, например, из-за широты тематики не описывались методы пассивного снятия отпечатков.
Большинство межсетевых защит блокируют некоторые типы трафика и часто затрудняют идентификацию находящихся за ними систем. Однако тщательное изучение их поведения может помочь опознаванию закрытых, фильтрованных и открытых TCP- и UDP-портов, а также определению операционной системы удаленного хоста.
Naveed Afzal, National University Of Computer and Emerging Sciences, Lahore, Pakistan, перевод Владимира Куксенка.
Сетевые решения. Статья была опубликована в номере 01 за 2006 год в рубрике технологии
