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

· атрибутов TTL (Time-to-Live -- время жизни). Устанавливает ли операционная система значение TTL для исходящих пакетов?

· Windows Size (размер окна). Какой размер окна используется?

· DF (Don't Fragment -- бит фрагментации). Устанавливается ли операционной системой признак DF?

· TOS (Type-of-Service -- тип службы). Устанавливается ли операционной системой значение TOS. Если да, то какое?

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

Вот как работает описанный метод. Если с помощью утилиты telnet установить удаленное соединение между узлами 192 .168 .1.10 и 192 .168 .1.11 , то с использованием утилиты siphon можно определить тип удаленной операционной системы.

[shadow]# telnet 192.168.1.11

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

06/04-11:23:48.297976 192.168.1.11:23 -> 192.168.1.10:2295

TCP TTL:255 TOS:OxO 10:58934 DF

**S***A* Seq: OxD3B709A4 Ack: OxBE09B2B7 Win: 0x2798

TCP Options => NOP NOP TS: 9688775 9682347 NOP WS: 0 MSS: 1460

При этом видно, что упоминавшиеся выше атрибуты принимают следующие значения:

· TTL= 255

· Размер окна = 2798

· Бит DF = Yes A TOS = 0

Теперь обратимся к базе данных утилиты siphon -- файлу osprints.conf:

[shadow]f grep -i Solaris osprints.conf

# Window:TTL:DF:Operating System DF = 1 for ON, 0 for OFF.

2328:255:l:Solaris 2.6 - 2.7

2238:255:l:Solaris 2.6 - 2.7

2400:255:l:Solaris 2.6 - 2.7

2798:255:l:Solaris 2.6 - 2.7

FE88:255:l:Solaris 2.6 - 2.7

87CO:255:l:Solaris 2.6 - 2.7

FAFO:255:0:Solaris 2.6 - 2.7

FFFF:255:1:Solaris 2.6-2.7

Из приведенного фрагмента видно, что в четвертой записи содержатся те же значения, которые были получены с использованием утилиты snort. Таким образом, с помощью утилиты siphon можно точно определить исследуемую операционную систему.

[crush]# siphon -v -i xl0 -о fingerprint.out

Running on: 'crush' running FreeBSD 4.0-RELEASE on a(n) i386

Using Device: xlO

Host Port . TTL DF Operating System 192.168.1.11 23 255 ON Solaris 2.6 - 2.7

Итак, в качестве удаленной была определена система Solaris 2.6. И это .не вызвало особых проблем. Пассивное исследование стека взломщик может использовать для выбора потенциальных жертв. Для этого достаточно понаблюдать за соответствующим Web-узлом и проанализировать сетевой трафик либо воспользоваться утилитой siphon. Несмотря на то что описанный метод является достаточно эффективным, он все же имеет некоторые ограничения. Во-первых, в приложениях, генерирующих свои собственные пакеты (например, шпар), не применяются те же признаки, что и самой операционной системой. Поэтому полученные результаты могут оказаться неточными. Во-вторых, на удаленном узле можно без проблем изменить атрибуты соединения.

Solaris: ndd -set /dev/ip ip_def_ttl 'число'

Linux: echo 'число' > /proc/sys/net/ipv4/ip_default_ttl

NT:

HKEY_LOCAL_MACHINESystemCurrentControlSet

ServicesTcpipParameters

Активное исследование стека

Прежде чем перейти к рассмотрению возможностей утилит nmap и queso, необходимо вкратце пояснить, в чем же состоит суть исследования стека TCP/IP. Исследование стека (stack fingerprinting) -- это очень мощная технология, позволяющая быстро определить тип и версию операционной системы узла с высокой степенью вероятности.

Очевидно, что разные разработчики по-разному подходят к реализации стека TCP/IP. В частности, многие разработчики по-своему трактуют рекомендации документов RFC, что впоследствии проявляется в логике работы тех или иных сетевых служб. Таким образом, зная о существующих различиях и проверив реакцию служб изучаемой системы на различные ситуации, можно практически однозначно определить тип и версию соответствующей операционной системы. Для достижения максимальной достоверности при исследовании стека требуется по крайней мере один порт, находящийся в режиме ожидания запросов. С помощью утилиты nmap можно выдвинуть предположение об используемой операционной системе даже при отсутствии таких портов, однако степень его достоверности в этом случае будет невысокой. Полное описание процесса исследования стека можно найти в статье Федора (Fyodor), впервые публикованной в журнале Phrack Magazine.

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

· Передача пакетов FIN (FIN probe). Пакет FIN отсылается в открытый порт. Как уже упоминалось, согласно документу RFC 793 исследуемая система не должна отвечать на такое сообщение. Однако многие реализации стека (например, Windows NT) отвечают на них, отправляя пакет FIN/ACK.

· Попытка установки флагов (bogus flag probe). Отсылается пакет SYN с установленным флагом в заголовке TCP, значение которого не определено спецификацией протокола. Некоторые операционные системы, например Linux, в ответном пакете устанавливают этот же флаг.

· Изучение начальной последовательности (Initial Sequence Number (ISN) sampling). Основная задача этого теста -- попытаться определить характерные признаки начальной последовательности, генерируемой узлом при получении запроса на установку соединения, которые характерны для той или иной реализации TCP.

· Мониторинг бита фрагментации ("don't fragment bit" monitoring). Этот бит устанавливается некоторыми операционными системами для повышения производительности. Проверка данного бита может помочь в определении типа операционной системы, для которой характерно такое поведение.

· Исходный размер окна TCP (TCP initial window size). Для некоторых реализаций стека протоколов TCP/IP данный параметр уникален, что способствует точности определения типа операционной системы.

· Значение АСК (дек value). В различных реализациях стека IP по-разному задается значение поля АСК. В одних случаях возвращается полученный от вас номер последовательности, а в других -- значение номера последовательности, увеличенное на 1.

· Обработка сообщений об ошибках ICMP (ICMP error message quenching). Некоторые операционные системы следуют рекомендациям документа RFC 1812 (www. ietf.org/rfc/rfcl812.txt) и ограничивают скорость передачи сообщений об ошибках. Поэтому, отправляя UDP-пакеты на какой-либо порт (обычно с большим номером), вполне реально измерить количество сообщений об ошибках, поступившее за определенный период, и определить таким образом тип операционной системы.

· Измерение длины сообщений ICMP (ICMP message quoting). При возникновении ошибок ICMP разными операционными системами передаются сообщения различной длины. Проанализировав полученное сообщение, можно сделать некоторые предположения об исследуемой операционной системе.

· Проверка целостности ответных сообщений об ошибках ICMP (ICMP error message-echoing integrity). В некоторых реализациях стека используется изменение заголовка IP при возврате сообщений об ошибках ICMP. Проверив тип изменений, внесенных в заголовок, можно сделать некоторые предположения об операционной системе исследуемого узла.

· Тип службы (TOS -- type of service). Можно проверять поле TOS для сообщений "ICMP port unreachable" (порт недоступен). В большинстве реализаций это поле имеет значение 0, однако иногда используются и другие значения.

· Обработка фрагментации (fragmentation handling). Как отмечают Томас Пташек (Thomas Ptacek) и Тим Ньюсхам (Tim Newsham) в своей известной статье Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection (http://www. clark.net/~roesch/idspaper.html), различные стеки обрабатывают перекрывающиеся сообщения по-разному. При сборке фрагментированньк пакетов некоторые стеки записывают новые данные поверх старых и наоборот. Проверив, каким образом были собраны тестовые пакеты, можно сделать предположение об исследуемой операционной системе.

· Параметры TCP (TCP options). Параметры TCP определены в документе RFC 793 и недавно изданном RFC 1323 (www.ietf.org/rfc/rfcl323.txt). Нововведения, описанные в RFC 1323, нашли отражение только в самых последних реализациях стеков. Отправляя пакет с набором различных параметров, таких как по operation, maximum segment size, window scale factor, timestamp и так далее, можно сделать вывод о типе и версии операционной системы.

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

[tsunami] nmap -0192.168.1.10

Starting nmap V. 2.53 by fyodor@insecure.org

Interesting ports on shadow (192.168.1.10) :

Port State Protocol Service

7 open tcp echo

9 open tcp discard

13 open tcp daytime

19 open tcp chargen

21 open tcp ftp

22 open tcp ssh

23 open tcp telnet

25 open tcp smtp

37 open tcp time

111 open tcp sunrpc

512 open tcp exec

513 open tcp login

514 open tcp shell

2049 open tcp nfs

4045 open tcp lockd

TCP Sequence Prediction: Class=randorn positive increments

Difficulty=26590 (Worthy challenge)

Remote operating system guess: Solaris 2.5, 2.51

Как видно, при включении режима исследования стека утилиты nmap можно легко получить достаточно точное определение типа и версии операционной системы. Даже если на изучаемом узле не открыто ни одного порта, утилита nmap поможет сделать довольно точное предположение об используемой операционной системе.

[ tsunami]# nmap -p80 -0 10.10.10.10

Starting nmap V. 2.53 by fyodor@insecure.org

Warning: No ports found open on this machine,

OS detection will be

MUCH less reliable

No ports open for host (10.10.10.10)

Remote OS guesses: Linux 2.0.27 - 2.0.30, Linux 2.0.32-34,

Linux 2.0.35-36, Linux 2.1.24 PowerPC,

Linux 2.1.76, Linux 2.1.91 - 2.1.103, Linux 2.1.122 - 2.1.132; 2.2.0-prel - 2.2.2, Linux 2.2.0-pre6 - 2.2.2-ac5

Nmap run completed -- 1 IP

address (1 host up) scanned in 1 second

Как видно из приведенного листинга, утилита nmap даже без открытых портов, правильно определила операционную систему Linux.

Одной из примечательных особенностей утилиты nmap является то, что листинг сигнатур хранится в отдельном файле с именем nmap-os-fingerprints. При появлении каждой новой версии утилиты этот файл также обновляется, и на момент написания данной книги в нем содержались сотни сигнатур. Если вы хотите добавить новые сигнатуры и повысить таким образом эффективность утилиты nmap, обратитесь ПО адресу http://www.insecure.org:80/cgi-bin/nmap-submit.cgi.

Хотя на момент написания данной книги утилита nmap, по-видимому, позволяет наиболее точно выполнить исследование стека TCP/IP, она, тем не менее, является далеко не первой программой, в которой реализована соответствующая технология. До того как Федор встроил в утилиту nmap средства определения операционной системы, для этих же целей уже была создана утилита queso (http://www.apostols.org/projectz/). Необходимо отметить, что утилита queso не позволяет выполнять сканирование портов и может определять тип операционной системы только при наличии в исследуемой системе открытого порта (по умолчанию используется порт 80). Если порт 80 закрыт, необходимо задать другой открытый порт, как показано в следующем примере, в котором с помощью утилиты queso осуществляется попытка определить тип операционной системы через порт 25.

[tsunami] queso 10.10.10.20:25

10.10.10.20:25 * Windoze 95/98/NT

Контрмеры: защита от определения операционной системы

Обнаружение попыток определения операционной системы

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

Предупреждение попыток определения операционной системы

Хотелось бы посоветовать какое-нибудь средство, позволяющее противодействовать попыткам определения операционной системы, однако, к сожалению, вынуждены констатировать, что решить эту проблему весьма непросто. Конечно, можно изменить исходный код операционной системы (естественно, если он имеется в вашем распоряжении) или поменять ее параметры, влияющие на характеристики стека, однако такое вмешательство может значительно изменить функциональность ОС. Например, в системе FreeBSD 4.x имеется параметр ядра TCP_DROP_SYNFIN, который можно применить для игнорирования пакетов SYN+FIN, используемых утилитой nmap в целях исследования стека. Установка этого параметра поможет пресечь попытки определения типа операционной системы, однако в то же время нарушит поддержку RFC 1644 (TCP Extensions for Transactions).

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

Пассивное определение операционной системы

Из предыдущих разделов видно, насколько эффективными оказываются средства активного исследования стека, такие как утилиты nmap и queso. Важно не забывать о том, что рассмотренные выше приемы являются активными по своей природе. При этом для определения специфических особенностей сетевого стека и используемой операционной системы каждому узлу нужно передавать тестовые пакеты. Поскольку все активные методы предполагают передачу пакетов, идентификации операционной системы. Другими словами, активное исследование является далеко не самым скрытым методом, к которому может прибегнуть взломщик.

Типы сканирования

Прежде чем перейти к описанию конкретных средств, используемых для сканирования портов, необходимо уделить немного времени обзору методов сканирования, известных в настоящее время. Одним из пионеров реализации различных методов сканирования является ранее упоминавшийся Федор (Fyodor). Многочисленные приемы сканирования были реализованы им в утилите nmар. Многие из описанных в данной книге методов сканирования были предложены самим Федором.

TCP-сканирование подключением (TCP connect scan). При таком типе сканирования осуществляется попытка подключения по протоколу TCP к интересующему нас порту с прохождением полной процедуры согласования параметров (handshake), состоящей в обмене сообщениями SYN, SYN/ACK и АСК. Попытки такого сканирования очень легко выявляются. На рис. 1.3 показана диаграмма обмена сообщениями в процессе согласования параметров.

? TCP-сканирование с помощью сообщений SYN (TCP SYN scan). Этот метод называется также сканированием с незавершенным открытием сеанса (half-open scanning), так как при его использовании полное TCP-соединение не устанавливается. Вместо этого на исследуемый порт отправляется сообщение SYN. Если в ответ поступает сообщение SYN/ACK, это означает, что данный порт находится в состоянии LISTENING. Если же ответ приходит в виде сообщения RST/ACK, то, как правило, это говорит о том, что исследуемый порт отключен. Получив ответ, компьютер, выполняющий сканирование, отправляет исследуемому узлу сообщение RST/ACK, поэтому полное соединение не устанавливается. Этот метод обеспечивает более высокую скрытность по сравнению с полным подключением. Многие системы не регистрируют такие попытки, поэтому они довольно часто могут оставаться незамеченными.

Рис. 1.3. При установке TCP-соединения происходит обмен тремя сообщениями: (1) клиент отправляет серверу пакет SYN, (2) получает от сервера пакет SYN/ACK и (3) отправляет серверу пакет АСК

· TCP-сканирование с помощью сообщений FIN (TCP FIN scan). В этом случае исследуемой системе отправляется пакет FIN. Согласно документу RFC 793 (http://www.ieff.org/rfc/rfc0793.txt), в ответ узел должен отправить пакет RST для всех закрытых портов. Данный метод срабатывает только для стека протоколов TCP/IP, реализованного в системе UNIX.

· TCP-сканирование по методу "рождественской елки" (TCP Xmax Tree scan). При использовании данного метода на исследуемый порт отправляются пакеты FIN, URG и PUSH. Согласно документу RFC 793, исследуемый узел в ответ должен отправить сообщения RST для всех закрытых портов.

· TCP нуль-сканирование (TCP Null scan). Этот метод состоит в отправке пакетов с отключенными флагами. Согласно RFC 793, исследуемый узел должен ответить отправкой сообщения RST для всех закрытых портов.

· TCP-сканирование с помощью сообщений АСК (TCP ACK scan). Этот метод позволяет получить набор правил, используемых брандмауэром. Такое сканирование поможет определить, выполняет ли брандмауэр простую фильтрацию пакетов лишь определенных соединений (пакетов с установленным флагом АСК) или обеспечивает расширенную фильтрацию поступающих пакетов.

· TCP-сканирование размера окна (TCP Windows scan). Такой метод позволяет выявить открытые, а также фильтруемые/нефильтруемые порты некоторых систем (например, AIX и FreeBSD), в зависимости от полученного размера окна протокола TCP.

· TCP-сканирование портов RFC (TCP RFC scan). Этот метод применим только для систем UNIX и используется для выявления портов RFC (Remote Procedure Call -- удаленный вызов процедур), связанных с ними программ и их версий.

А UDP-сканирование (UDP scan). Данный метод заключается в отправке на исследуемый узел пакетов по протоколу UDP. Если в ответ поступает сообщение о том, что порт ICMP недоступен (ICMP port unreachabie), это означает, что соответствующий порт закрыт. С другой стороны, если такого сообщения нет, можно предположить, что данный порт открыт. В связи с тем, что протокол UDP не гарантирует доставки, точность данного метода очень сильно зависит от множества факторов, влияющих на использование системных и сетевых ресурсов. Кроме того, UDP-сканирование -- очень медленный процесс, что особенно сказывается при попытках сканирования устройств, в которых реализован мощный алгоритм фильтрации пакетов. Поэтому, планируя использовать UDP-сканирование, приготовьтесь к тому, что результаты могут оказаться ненадежными.

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

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

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

NetScanTools Pro 2000

Одним из наиболее универсальных средств исследования сетей, доступных в настоящее время, является пакет NetScanTools Pro 2000 (NSTP2K), содержащий самые разнообразные утилиты, объединенные общим интерфейсом. С использованием NSTP2K можно генерировать запросы DNS, включая nslookup, dig и axf r, запросы whois, осуществлять ping-прослушивание, сканировать таблицы имен NetBIOS, отслеживать сообщения SNMP и выполнять многие другие задачи. Более того, с использованием пакета NetScanTools Pro 2000 можно выполнять несколько задач одновременно. Например, можно выполнять сканирование портов одной сети и осуществлять ping-прослушивание другой сети (хотя мы не можем ручаться за правильность таких действий по отношению к большим сетям).

В состав пакета NetScanTools Pro 2000 включен также один из лучших сканеров портов Windows. Все необходимые параметры можно установить во вкладке Port Probe. К преимуществам утилиты сканирования NSTP2K. можно отнести возможность гибкого задания параметров исследуемых узлов и портов (и IP-адреса и список портов могут быть импортированы из текстовых файлов), возможность TCP- и UDP-сканирования (хотя соответствующие режимы нельзя установить отдельно для каждого порта), а также высокую скорость благодаря реализации многопоточности. К недостаткам утилиты сканирования пакета NSTP2K можно отнести некоторую громоздкость получаемых результатов, что затрудняет их анализ с помощью сценариев, и, кроме того, графический интерфейс делает невозможным применение этой утилиты в сценариях. Нам хотелось бы высказать следующее пожелание: было бы очень удобно, чтобы результаты, полученные с использованием одной утилиты пакета NSTP2K (скажем, NetScanner), можно было бы напрямую передавать другой утилите (например, Port Probe).

В общем, пакет NSTP2K (http://www.nwpsw.com) представляет собой профессионально разработанный программный продукт, который регулярно обновляется посредством сервисных пакетов, однако все же остается несколько дорогостоящим по сравнению с предоставляемыми им возможностями. Можно также познакомиться с менее робастной версией Netscan Tools (в настоящее время доступна версия 4), являющейся пробной 30-дневной версией пакета NSTP2K. Однако предоставляемые ею возможности не столь широки, как у пакета Pro 2000 (например, она не позволяет выполнять UDP-сканирование).

При использовании пакета NSTP2K не забудьте отключить сервер идентификации во вкладке IDENT Server, чтобы не запрещать прослушивание порта 113.

SuperScan

Утилита SuperScan, написанная Робином Кейром (Robin Keir) (http: //members. home.com/rkeir/software.html), является еще одной быстрой и гибкой утилитой TCP-сканирования портов и имеет гораздо более привлекательную стоимость -- она распространяется бесплатно! Как и пакет NSTP2K, утилита SuperScan позволяет гибко задавать перечень IP-адресов исследуемых узлов и сканируемых портов. Особенно удобно использовать режим Extract from file. Лучше всего особенности его применения описаны в справочной системе. Вот небольшой фрагмент из справочной системы утилиты SuperScan, из которого видно, что она позволяет сэкономить значительную часть времени.

"Режим [The "Extract from file" feature scans] позволяет просматривать содержимое любого текстового файла и извлекать из него корректные IP-адреса и имена узлов. При поиске корректных имен программой выполняются достаточно интеллектуальные действия. Однако перед обработкой файла из него нужно удалить потенциально неоднозначные фрагменты текста, воспользовавшись внешним текстовым редактором. На кнопках Browse и Extract можно щелкать столько раз, сколько различных файлов имеется в вашем распоряжении. При этом в список имен исследуемых узлов программой будут добавлены все новые имена. Все повторяющиеся элементы будут автоматически удалены. После нахождения всех имен узлов щелкните на кнопке Resolve, чтобы преобразовать их в числовые IP-адреса и выполнить подготовку к этапу сканирования портов." Эта утилита предоставляет также один из наиболее обширных списков портов, с которым нам когда-либо приходилось встречаться. (Авторам книги нравится список под названием henss.lst. Более того, в исходном англоязычном названии книги первые буквы составляют аббревиатуру HENSS&S, откуда можно заключить, что авторы -- просто фанаты этого списка.) Кроме того, порты можно выделить или отменить их выделение вручную. Не лишний раз повторить, что утилита SuperScan помимо всех перечисленных возможностей обладает также и высокой скоростью.

NTOScanner

Утилита NTOScanner компании NTObjectives, Inc. (http://www.ntobjectives.com) представляет собой быструю программу TCP-сканирования с графическим интерфейсом, которая при ручной установке соответствующего режима позволяет также собирать маркеры портов, находящихся в состоянии ожидания запросов. Однако эта утилита имеет некоторые неудобства при задании исследуемых узлов и портов, а также требует, чтобы перед сканированием сетей класса С к узлам было применено ping-прослушивание. Утилита NTOScanner чрезвычайно полезна для определения служб, запущенных на конкретном узле или в сети, достижимой с помощью ICMP-пакетов.

WinScan

Утилита WinScan компании Scan Mathias of Prosolve (http://www.prosolve.com) является свободно распространяемой программой TCP-сканирования портов, реализованной в двух версиях: с графическим интерфейсом (winscan.exe) и для использования в командной строке (scan.exe). Мы регулярно обращаемся к версии для командной строки в файлах сценариев, поскольку при сканировании сетей класса С она позволяет получить удобные для анализа результаты. При использовании утилит Win32 strings, tee и tr компании Mortice Kern Systems, Inc. (http://www.mks.com) следующая консольная команда NT будет выполнять сканирование сети для портов из диапазона 0-1023 и формировать результат в виде строк с полями, разделенными двоеточиями, в формате IP-адрес:имя_службы: порт/протокол (для облегчения восприятия строка была разделена на две части).

scan.exe -n 192.168.7.0 -s 0 -е 1023 -f|strings|findstr/с:"/top"|

tr \011\040 : | tr -s ::|tee -ia results.txt

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

192.168.22.5:nbsession:139/tcp

192.168.22.16:nbsession:139/tcp

192.168.22.32:nbsession:139/tcp

Большое спасибо Патрику Хейму (Patrick Heim) и Ясону Глассбергу (Jason Glassberg) за предоставление этой интересной команды.

ipEye

Не думаете ли вы, что для выполнения нетрадиционного сканирования потребуется система Linux и утилита nmap? He торопитесь с выводами, поскольку утилита ipEye Арни Видстрома (Arne Vidstrom)'(http: //ntsecurity.nu) позволяет выполнить сканирование требуемых портов, а также TCP-сканирование с помощью сообщений SYN, FIN и с использованием метода "рождественской елки", из командной строки Windows. На использование этой прекрасной утилиты накладывается лишь несколько ограничений. Они заключаются в том, что ее можно использовать только в среде Windows 2000 и одновременно сканировать один узел. Вот пример запуска утилиты ipEye для выполнения TCP-сканирования с помощью сообщений SYN порта с номером 20. При этом предпринята попытка избежать правил фильтрации, используемых маршрутизатором. Приведенный пример аналогичен запуску утилиты nmap с параметром -д (для краткости полученные результаты отредактированы).

С:\Toolbox>ipeye.exe

192.168.234.110 -syn -p 1 1023 -sp 20

ipEye 1.1 - (с) 2000, Arne Vidstrom (arne.vidstrom@ntsecurity.nu)

- http://ntsecurity.nu/toolbox/ipeye/

1-52 [closed or reject]

53 [open]

54-87 [closed or reject]

88 [open]

89-134 [closed or reject]

135 [open]

136-138 [closed or reject]

139 [open]

636 [open]

637-1023 [closed or reject]

1024-65535 [not scanned]

WUPS

Утилита Windows UDP Port Scanner (WUPS) разработана теми же авторами (http://ntsecurity.nu). Эта утилита представляет собой надежное, с графическим интерфейсом и относительно быстрое средство сканирования UDP-портов, несмотря на то, что позволяет одновременно сканировать заданную последовательность портов лишь одного узла. Как видно из рис. 2.6, утилита WUPS является надежным средством для быстрого UDP-сканирования каждого требуемого узла и, следовательно, значительно облегчает выполнение этой утомительной задачи.

Защита от сканирования портов

В табл. 1.4 приведен перечень различных популярных утилит сканирования, а также типы сканирования, которые эти утилиты позволяют выполнять.

Контрмеры: защита от сканирования портов

Выявление факта сканирования

Как правило, взломщики прибегают к сканированию TCP- и UDP-портов удаленного компьютера, чтобы установить, какие из них находятся в состоянии ожидания запросов. Поэтому выявить факт сканирования -- значит, установить, в каком месте и кем будет предпринята попытка взлома. Основные методы выявления факта сканирования состоят либо в использовании специальной программы, предназначенной для выявления вторжений на уровне сети (IDS), такой как NFR, либо в использовании механизма защиты на уровне отдельного узла.

Таблица 1.4. Популярные утилиты сканирования портов и их возможности

Утилита	Сканирование	Ресурс
UNIX	TCP	UDP	Скрытое
Strobe	X			ftp://f tp.FreeBSD.org/ pub/FreeBSD /ports/distfiles/strobe-1.06.tgz
Tcp_scan	X			http://wwdsilx. wwdsi.com/saint/
Udp_scan		X		http://wwdsilx. wwdsi.com/saint/
Nmap	X	X	X	http://www. inscure . org/nmap
Netcat	X	X		http://www.10pht.com/ users/10pht/nc110.tgz
Windows Netcat	X	X		http://www.10pht.com/users/ 10pht/ncllnt.zip
NetScanTools Pro 2000	X	X		http://www.nwpsw.com
SuperScan	X			http://members.home.com/ rkeir/software.html
NTOScanner	X			http://www.ntobjectives.com
WinScan	X			http://www.prosolve.com
IpEye	X			http://ntsecurity.nu
WUPS		X		http://ntsecurity.nu
Fscan	X	X		http://www.foundstone.com

Метод UDP-сканирования утилиты netcat не работает в операционной системе Windows NT, поэтому пользователям этой ОС не стоит доверять полученным результатам.

# Алгоритм выявления факта сканирования

# Автор - Стюарт Мак-Клар (Stuart McClure)

# Данный алгоритм выявляет неудачные попытки сканирования портов,

# которые приводят к генерации сообщений ACK/RST.

В процессе настройки

# можно поэкспериментировать со значениями

# maxcount и maxtime.

port_schema = library_schema:new( 1, ["time", "ip", "ip",

"int"],

scope() };

time = 0;

count = 0;

maxcount =2; t Максимально допустимое количество ACK/RST.

maxtime =5; tt Максимально допустимое время, в течение

# которого может достигаться значение maxcount.

source = 0; port = 0; target = 0;

filter portscan ip ( )

{

if (tcp.is)

(

# Проверка АСК, RST и источника поступления.

if ( byte(ip.blob, 13) == 20 )

# Установлены флаги АСК, RST

{

count = count + 1;

source = ip.dest;

target = ip.source;

port = tcp.sport;

time = system.time;

} } on tick = timeout

( sec: maxtime, repeat )

call checkout;

}

func checkout {

if (count >= maxcount) {

echo("Попытка сканирования порта,

Время: ", time, "\n); record system.time, source, target,

port to the_recorder_portscan; count = 0; }

else

count = 0;

}

the_recorder_portscan=recorder("

bin/histogram packages/sandbox/portscan.cfg",

"port_schema"

);

Для выявления попыток сканирования портов можно также воспользоваться утилитой snort (www.snort.org) (см. также http://spyjurenet.com/linuxrc.org/projects/ snort/). Как вы могли догадаться, эта утилита является одной из предпочитаемых нами программ IDS (заметим, что ее версии 1.x не позволяют обнаруживать фрагментацию пакетов). Вот пример листинга, содержащего данные о попытке сканирования портов.

[**] spp_portscan: PORTSCAN DETECTED from 192.168.1.10 [**]

05/22-18:48:53.681227

[**] spp_portscan: portscan status from 192.168.1.10: 4 connections

across 1 hosts: TCP(O), UDP(4) [**]

05/22-18:49:14.180505

[**] spp_portscan: End of portscan from 192.168.1.10 [**]

05/22-18:49:34.180236

Для платформы UNIX существует немало утилит, таких, например, как Утилита: scanlogd (http://www.openwall.com/scanlogd/) компании Solar Designer, которые выявляют и регистрируют попытки сканирования. Кроме того, утилиту Psionic PortSentry, созданную в рамках проекта Abacus (http://www.psionic.com/abacus), можно настроить не только на регистрацию, но и на принятие контрмер при выявлении факта активного сканирования. Один из способов борьбы с попытками сканирования портов заключается в автоматической установке для ядра правил фильтрации, когда к уже существующим добавляется новое правило, запрещающее доступ со стороны узла-нарушителя. Такое правило можно задать в конфигурационном файле утилиты PortSentry. При этом одно и то же правило может отличаться в различных системах. Для системы Linux 2.2.x, в которой имеется поддержка ядра брандмауэра, в файл portsentry.conf нужно добавить запись, аналогичную следующей.

# New ipchain support for Linux kernel version 2.102+

KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY -1"

Утилита PortSentry совместима с большинством версий UNIX, включая Solaris. Независимо от того, применяете ли вы какие-либо утилиты или нет, необходимо помнить, что массированные попытки сканирования портов, инициируемые каким-либо узлом или какой-нибудь сетью, могут означать, что кто-то изучает вашу сеть. Всегда обращайте самое пристальное внимание на такие действия, поскольку за ними может последовать полномасштабное вторжение. И наконец, не забывайте о том, что имеется возможность активного противостояния или блокирования попыток сканирования портов. Все эти вопросы рассматриваются в статье, опубликованной компанией Solar Designer (http://www. openwall.com/scanlogd/P53-13.gz). В этой статье содержатся дополнительные советы по разработке и использованию систем выявления попыток сканирования.

Большинство брандмауэров не только могут, но и должны настраиваться на режим обнаружения попыток сканирования. Однако одни брандмауэры справляются с этой задачей лучше, другие хуже. Например, некоторые брандмауэры умеют выявлять скрытое сканирование. Однако многие из них, поддерживая режим выявления SYN-сканирования, абсолютно игнорируют FiN-сканирование. Самой большой проблемой при выявлении факта сканирования является задача анализа огромных системных журналов, накапливаемых при ежедневной работе серверов сети. Для упрощения решения этой задачи можно воспользоваться утилитой Psionic Logcheck (http: //www.-psionic.com/abacus/logcheck/). Кроме того, мы рекомендуем настроить утилиты таким образом, чтобы они реагировали на обнаруженные попытки сканирования в реальном времени, отсылая сообщения по электронной почте. Везде, где это только возможно, устанавливайте пороговые значения для количества регистрируемых событий (threshold logging), чтобы взломщик не завалил ваш почтовый ящик грудой сообщений, в которых будет так же трудно найти информацию, как и в системных журналах. Кроме того, в этом случае может также возникнуть условие DoS. При использовании пороговых значений все предупреждения будут группироваться, а не обрабатываться по одному. Как минимум необходимо настроить систему безопасности на выдачу отчетов о самом факте выявленной попытки сканирования. Для брандмауэра Firewall-1 с этой целью можно использовать утилиту Ланца Спитцнера (Lance Spitzner) alert, sh (http://www. enteract.com/~lspitz/intrusion.html). Эта утилита будет выявлять и отслеживать попытки сканирования портов, работая под управлением Firewall-1 в качестве средства защиты, заданного пользователем.

Для платформы Windows NT также имеется несколько утилит, предназначенных для выявления попыток сканирования. Прежде всего, необходимо отметить такую утилиту, как Genius 2.0, разработанную компанией Independent Software (http://www. indiesoft.com) для платформ Windows 95/98 и Windows NT. Этот программный продукт предоставляет гораздо больше возможностей, чем простое средство обнаружения TCP-сканирования портов. Однако необходимо отметить, что даже с учетом этого, имеет смысл его использовать. Утилита Genius отслеживает многочисленные запросы к открытым портам и при обнаружении попыток сканирования отображает на экране предупреждающее диалоговое окно, в котором содержится IP-адрес взломщика и доменное имя его узла.

Утилита Genius позволяет выявлять как попытки обычного сканирования, т.е. с установлением TCP-соединения, так и SYN-сканирования.

Еще одним детектором сканирования для системы Windows, заслуживающем отдельного упоминания, является программа BlackICE компании Network ICE (http://www.-networkice.com). Данная программа представляет первое основанное на использовании агентов средство выявления вторжений, которое можно использовать как в Windows 9х, так и в NT. В момент написания данной книги этот программный продукт был коммерческим, хотя в ближайшем будущем компания обещает подготовить свободно распространяемую версию. И наконец, программа ZoneAlarm (http://www.zonelabs.com/zonealarm.htm) хорошо подходит для платформы Windows и может применяться в качестве средства IDS на уровне брандмауэра.

Предотвращение сканирования

Вряд ли можно помешать кому-либо предпринять попытку сканирования портов на вашем компьютере, однако вполне реально свести к минимуму связанный с этим риск. Для этого нужно заблокировать все службы, в работе которых нет необходимости. В среде UNIX данная задача решается с помощью добавления символов комментария в соответствующие строки файла /etc/inetd. corif, а также отключения автоматического запуска ненужных служб в сценарии начальной загрузки. В системе Windows NT также целесообразно отключить все ненужные службы. Однако сделать это сложнее, поскольку из-за сетевой архитектуры Windows NT по крайней мере Порт 139 должен работать постоянно. Тем не менее, остальные службы можно отключить, запустив аплет Services панели управления. Здесь же стоит упомянуть о том, что компанией Tiny Software (www.tinysoftware.com) распространяется модуль ядра, позволяющий выполнять фильтрацию входящих пакетов. С помощью этого модуля можно защитить большинство важных портов. Что же касается других операционных систем и устройств, то нам остается лишь посоветовать как можно внимательнее прочитать соответствующие справочные руководства. Постарайтесь найти в них информацию о том, какие порты вам действительно необходимы и как отключить остальные, чтобы свести риск к минимуму.

Активное определение операционной системы

Итак, мы убедились, что существует множество различных приемов и средств сканирования портов. Вспомните, что при сканировании портов преследуется две основные цели. Во-первых, нужно установить, какие TCP- и UDP-порты на исследуемом компьютере находятся в состоянии ожидания запросов. Во-вторых, необходимо определить тип операционной системы, используемой на удаленном узле. Информация об операционной системе понадобится на последующих этапах, при составлении схемы уязвимых участков. Об этом речь пойдет в последующих главах. Важно помнить, что при этом необходимо быть особенно точным и внимательным к мелочам. Именно поэтому очень важно абсолютно правильно установить тип удаленной операционной системы. При определении типа ОС очень полезной оказывается косвенная информация, получаемая, например с помощью сбора маркеров, о которых мы поговорим в главе 3. При этом будет собрана информация о таких службах, как FTP, telnet, SMTP, HTTP, POP и других. Сбор маркеров -- это один из самых простых методов определения типа операционной системы, а также версий работающих под ее управлением служб. Нетрудно догадаться, что существуют различные средства, призванные помочь в решении этой задачи. Среди доступных можно отметить две утилиты, позволяющие получить самые точные результаты, -- уже хорошо нам известная nmар и утилита queso. Точность результатов, выдаваемых обеими утилитами, объясняется, прежде всего, тем, что обе они предоставляют возможность исследования стека протоколов TCP/IP (stack fingerprinting).

Заключение

Целью данной курсовой работы было обзорной статьей о передаче информации в локальных сетях и методах её отслеживания (нахождения).

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

Список литературы

1. Мурлина В.А. Информатика и программирование. Методическое указание к курсовой работе по дисциплине «Информатика и программирование» для студентов всех форм обучения специальности 080801 - «прикладная информатика в экономике» факультета компьютерных технологий и автоматизированных систем.- Краснодар: издательство КубГТУ, 2004. - 49с.

2. С.В. Пеников «Локальные сети», издательство «АПВ», 2004 - 151 с.

3. Г.Т. Сизов «Системы и сети», издательство «Интер» 2005 - 204 с.

Страницы: 1, 2