Исследование политики фаервола, сканирование TCP-портов

Автор работы: Пользователь скрыл имя, 23 Августа 2013 в 17:11, реферат

Краткое описание

Рассмотрим подробнее процесс подключения к серверному приложению, ожидающему запросы на каком-либо TCP-порту. Данный процесс состоит из двух этапов. На первом этапе клиенту необходимо создать обычное TCP-соединение с указанным TCP-портом сервера. Для этого по схеме, описанной в разделе "Подмена одного из субъектов TCP-соединения в сети Internet", клиент передает на сервер TCP SYN-запрос на необходимый порт.

Содержание

1. ВСТУПЛЕНИЕ 9
2. ОТКРЫТЫЕ МЕТОДЫ СКАНИРОВАНИЯ 12
2.1. Сканирование TCP-портов методом reverse-ident 13
3. ПОЛУОТКРЫТЫЕ МЕТОДЫ СКАНИРОВАНИЯ 14
4. СКРЫТЫЕ (STEALTH) МЕТОДЫ СКАНИРОВАНИЯ 20
4.1. SYN|ACK scan 20
4.2. Fin scan 21
4.3. Ack scan 23
4.4. Null scan 24
4.5. Xmas Tree scan 25
4.6. TCP Fragmenting 26
5. ОСТАЛЬНЫЕ МЕТОДЫ СКАНИРОВАНИЯ 28
5.1. Сканирование UDP-портов проверкой ICMP-сообщения 28
5.2. Сканирование TCP-портов с использованием атаки 30
СПИСОК ЛИТЕРАТУРЫ 33

Вложенные файлы: 1 файл

referat 1.doc

— 227.50 Кб (Скачать файл)

Порт закрыт!

 

4. Скрытые (stealth) методы сканирования

 

Определение "stealth" сканирования изменилось с тех пор как Chris Klaus в своей статье "Stealth Scanning: Bypassing Firewalls/SATAN Detectors" впервые описал его. Изначально это определение использовалось для методов сканирования, которые позволяли обходить IDS и логирование, но сегодня они известны как полуоткрытые методы. В настоящее время stealth методы, которые:

  • Используют установку какого-то одного флага (ACK, FIN, RST, .. )
  • Используют сброс всех флагов (Null scan)
  • Используют установку всех флагов
  • Обходят фильтры пакетов, файерволы, маршрутизаторы
  • Неотличимы от обычного трафика
  • Используют различные способы разделения пакетов

 

Все описанные методы используют технологию «инвертированного сканирования»,т.е. подтверждение приходит для закрытых портов.

4.1 SYN|ACK scan (ТСР-сканирование пакетами с установленными флагами SYN и ACK)

 

Этот метод отсутствует в  большинстве сканеров портов. Тем  не менее, он более скрытен, чем обычный SYN метод.

 

В случае закрытого порта, ответ будет таким:

 

 

TCP реализован  так, что в ответ сервер не  пошлет SYN, а сразу же разорвет  соединение. То есть протокол  решит, что произошла ошибка  в соединении на этом порту,  когда получит SYN|ACK без предшествующего пакета SYN и в результате пошлет флаг сброса.

 

В случае открытого порта:

 

 

Как видно  сервер игнорирует пакет SYN|ACK, пришедший  на открытый порт. Понятно, что отсутствие ответа от сервера приводит к ложным срабатываниям. Так если мы пошлем SYN|ACK пакет и не получим ответа из-за фильтра пакетов, файервола или просто истечения времени жизни пакета, то сканер ошибочно решит, что порт открыт. Получается что этот метод менее надежный, чем TCP connect(). Методы, которым присущи такие ошибки, называются инвертированными ("inverse mapping").

 

Преимущества: быстрый, обходит простые IDS и файерволы, не устанавливает полного соединения

Недостатки: не очень надежный (возможно ложное определение закрытого порта как открытый)

 

4.2 Fin scan (ТСР-сканирование  пакетами с установленным флагом FIN)

 

FIN метод так же является инвертированным.  К сожалению, он основан ошибке  в сетевом коде BSD и не работает  для других ОС. В идеальном  случае закрытый порт пошлет RST, открытый не пошлет ничего.

 

 

Операционная система сервера  просто уничтожит пакет и ничего не передаст процессу, слушающему этот порт.

 

В случае закрытого порта:

 

 

Существует два способа проверки открытого порта, если от него не приходит ответ. Первый способ заключается в том, чтобы получить список портов, от которых пришли пакеты RST и сравнить его со списком портов, на которые были отосланы FIN пакеты. Например, отсылаем 3 пакета на порты 1, 2 и 3. Приходят ответы с RST от портов 1 и 3. Из этого можно сделать вывод, что порт 2 открыт.

 

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

 

Преимущества: обходит большинство IDS, не устанавливает полного соединения

Недостатки: не очень надежный (возможно ложное определение закрытого порта как открытый)

 

4.3 Ack scan (ТСР-сканирование  пакетами с установленным флагом ACK)

 

Впервые данный метод описал Уриэль Маймон (Uriel Maimon) в электронном журнале Phrack 49, article 15. Метод также основан на ошибке сетевого кода некоторых операционных систем.

 

Для проверки порта этим методом  нужно отослать ACK пакет на целевой хост. Ответные пакеты можно оценить по двум параметрам: по полю TTL (Time To Live - время жизни пакета) и по полю WINDOW. Оба этих поля должны содержать ответные пакеты с флагом RST.

 

Флаг RST будет потому, что сервер будет разрывать соединение. У некоторых ОС ответные пакеты с открытых портов будут иметь TTL меньше, чем пакеты с закрытых. Обычно на ACK пакет с любым TTL с открытого порта прейдет ответ, у которого TTL меньше или равно 64, а с соседних закрытых портов TTL будет больше.

 

 

Так выглядит реальный ответ хоста:

 

 packet 1: host XXX.XXX.XXX.XXX port 20: F:RST -> ttl: 70 win: 0 => closed

packet 2: host XXX.XXX.XXX.XXX port 21: F:RST -> ttl: 70 win: 0 => closed

packet 3: host XXX.XXX.XXX.XXX port 22: F:RST -> ttl: 40 win: 0 => open

packet 4: host XXX.XXX.XXX.XXX port 23: F:RST -> ttl: 70 win: 0 => closed

 

Здесь видно, что TTL у пакетов до и после третьего больше 64. TTL меньше 64 у третьего пакета говорит о том, что порт 22 открыт.

 

Оценка по полю WINDOW основывается на том, что для открытых портов значение этого поля не будет нулевым. Так происходит с ранними версиями BSD (FreeBSD,  OpenBSD) и UNIX (AIX,  DGUX), но в последующих версиях это было исправлено.

 

Так выглядит реальный ответ хоста:

 

 packet 6: host XXX.XXX.XXX.XXX port 20: F:RST -> ttl: 64 win: 0 => closed

packet 7: host XXX.XXX.XXX.XXX port 21: F:RST -> ttl: 64 win: 0 => closed

packet 8: host XXX.XXX.XXX.XXX port 22: F:RST -> ttl: 64 win: 512 => open

packet 9: host XXX.XXX.XXX.XXX port 23: F:RST -> ttl: 64 win: 0 => closed

 

У всех пакетов в этом примере TTL равно 64 это значит, что для данного хоста работает только WINDOW метод.

 

Преимущества: обходит IDS, сложно логируется

Недостатки: основан на ошибке в сетевом коде ОС BSD, подходит не для всех ОС

4.4 Null scan (ТСР-сканирование  нулевыми пакетами)

 

Как можно понять из названия метода, NULL сканирование производится пакетами, у которых все флаги сброшены. ACK, FIN, RST, SYN, URG, PSH не установлены. Зарезервированные  биты (RES1, RES2) не влияют на результаты сканирования, и установлены они или нет, не имеет никакого значения. Когда пакет приходит на сервер, сетевой код BSD игнорирует пакет, если порт открыт.

 

Если порт закрыт, отсылается RST пакет (еще один инвертированный метод).

 

Из-за того что в стандарте (RFC) не описывается как должен ответить хост при получении пакетов без флагов, различные операционные системы ведут себя по-разному.

 

Преимущества: обходит IDS, не устанавливает полного соединения

Недостатки: подходит только для всех ОС семейства UNIX, возможно ложное определение закрытого порта как открытый

4.5 Xmas Tree scan (TCP-сканирование  методом "рождественской елки")

 

Так называемое XMAS сканирование является противоположностью NULL методу. В TCP заголовке  отсылаемого пакета устанавливаются все флаги (ASK, FIN, RST,  SYN, URG, PSH). Метод XMAS или "рождественской елки" так называется из-за вида пакетов со всеми флагами. Зарезервированные биты никак не влияют на результат сканирования и их установка не имеет значения. Опять же метод основан на сетевом коде BSD и работает только на UNIX хостах.

 

XMAS сканирование устанавливает  все флаги и отправляет пакет  на удаленный хост. Если пакет  получает открытый порт, система  игнорирует пакет, если закрытый, возвращает RST. Метод является инвертированным и возможны ложные срабатывания.

 

Случай, если порт открыт или пакет  отфильтрован файерволом или маршрутизатором:

 

 

Случай закрытого порта:

 

 

Сервер отошлет RST, т.к. будет считать, что клиент пытается установить соединение с закрытым портом стандартным трехшаговым методом. И отошлет флаг сброса (RST) для немедленного прекращения передачи.

 

Преимущества: обходит IDS, не устанавливает полного соединения

Недостатки: подходит только для всех ОС семейства UNIX, возможно ложное определение закрытого порта как открытый

 

4.6 TCP Fragmenting (TCP-сканирование с использованием IP-фрагментации)

 

TCP фрагментация сама по себе не является методом сканирования, но позволяет скрыть применение других методов. Заключается она в том, что при отправке TCP пакет разбивается на несколько сегментов. На стороне сервера IP-фрагменты "собираются" в один TCP-пакет и производится его обработка. Иногда это может привести к не предсказуемым результатам, т.к. заголовок пакета может оказаться фрагментированным. Некоторые хосты не могут обрабатывать и собирать очень маленькие сегменты, и это может привести сбоям или даже перезагрузкам хостов.

 

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

 

Преимущества: обходит IDS, сложно логируется

Недостатки: возможны проблемы с получением пакетов на исследуемом хосте

 

 

 

 

 

 

 

 

 

 

 

 

5. Остальные методы сканирования

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

5.1 Сканирование UDP-портов проверкой ICMP-сообщения "Порт недоступен"

 

Этот метод также предназначен для определения состояния портов сервера. Основным отличием является использование протокола UDP вместо протокола TCP. Не смотря на то, что организация протокола UDP проще, чем TCP, сканировать UDP-порты гораздо труднее. Это связано прежде всего с концепцией протокола UDP как протокола с негарантированной доставкой данных. Поэтому UDP-порт не посылает подтверждение приема запроса на установление соединения, и нет никакой гарантии, что отправленные UDP-порту данные успешно дойдут до него.

 

К счастью, большинство серверов в  ответ на пакет, прибывший на закрытый UDP-порт, отправляют ICMP-сообщение "Порт недоступен" (Port Unreachable - PU). Таким образом, если в ответ на UDP-пакет пришло ICMP-сообщение PU, то сканируемый порт является закрытым, в противном случае (при отсутствии PU) порт открыт. Поскольку нет гарантии, что запросы от хоста дойдут до сервера, пользователь должен позаботиться о повторной передаче UDP-пакета, который, по всей видимости, оказался потерянным.

 

Этот метод работает очень медленно из-за использования на некоторых  машинах т.н. "компенсации" (RFC 1812 раздел 4.3.2.8), ограничивающей частоту генерирования ICMP-сообщений об ошибке. Например, ядро Linux ограничивает частоту генерирования ICMP-сообщения "адресат недостижим" (Destination Unreachable) до 80 сообщений за 4 секунды, с простоем 0,25 секунды, если это ограничение было превышено. Кроме того, для использования данного метода (а именно - для обнаружения ICMP-сообщений об ошибке) пользователь должен обладать статусом Root на хосте, с которого производится сканирование.

 

Может показаться, что сканирование UDP-портов не дает той полноты информации, какую можно получить при сканировании TCP-портов. Однако, принимая во внимание существующие (хотя и не многочисленные) "дыры" в службах, использующих протокол UDP (например, "дыру" в rpcbind-демоне ОС Solaris, который может находится на любом UDP-порту с номером выше 32770), сканирование UDP-портов кажется не таким уж бессмысленным.

 

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

 

Если пакет приходит на закрытый порт, отсылается ICMP-сообщение "Порт недоступен":

 

 

Преимущества: возможно сканирование не TCP портов, обходит IDS

Недостатки: необходимы права администратора (root), пакеты могут быть легко блокированы, метод легко обнаруживается

5.2 Сканирование TCP-портов с использованием атаки «Прорыв через FTP»

 

Первым методом анонимного сканирования является метод, получивший название FTP Bounce Attack (скрытая атака по FTP). Протокол FTP (RFC 959) имеет ряд, как нам кажется, чрезвычайно интересных и недостаточно описанных функций, одна из которых - возможность создания так называемых "proxy" ftp-соединений с FTP-сервера. Если программная реализация FTP-сервера поддерживает режим proxy, то любой пользователь (и анонимный в том числе) может, подключившись к серверу, создать процесс DTP-server (Data Transfer Process - процесс передачи данных) для передачи файла с этого FTP-сервера на любой другой сервер в Internet. Функциональность данной возможности протокола FTP вызывает некоторое сомнение, так как в обычной ситуации ftp-клиент, подключающийся к серверу, передает и получает файлы либо непосредственно от себя, либо для себя. Представить иной вариант действий, на наш взгляд, достаточно сложно, но, видимо, создатели протокола FTP для его "будущего" развития предусмотрели подобную возможность, которая теперь выглядит несколько архаичной и отнюдь не безопасной.

 

Эта особенность протокола FTP позволяет предложить метод TCP-сканирования с использованием proxy ftp-сервера, состоящий в следующем: ftp-серверу после подключения выдается команда PORT с параметрами IP-адреса и TCP-порта объекта сканирования. Далее следует выполнить команду LIST, по которой FTP-сервер попытается прочитать текущий каталог на объекте, посылая на указанный в команде PORT порт назначения TCP SYN-запрос. Если порт на объекте открыт, то на сервер приходит ответ TCP SYN АСК и FTP-клиент получает ответы "150" и "226", если же порт закрыт, то ответ будет таким:

 

425. Can't Build Data Connection: Connection Refused

(425. Невозможно установить соединение: в соединении отказано).

Информация о работе Исследование политики фаервола, сканирование TCP-портов