Еще один метод сканирования объекта, при котором можно остаться анонимным, - сканирование с использованием промежуточного хоста (или цепочки хостов, что еще более надежно). В данном случае существует возможность действовать следующими двумя способами [22].
Первый способ состоит в использовании анонимных Free Telnet Account (свободный Telnet-доступ) которых в Internet довольно много. При помощи telnet можно, подключившись к данному хосту, от его имени вести сканирование любого хоста в Internet. Для этого пишется небольшой скрипт, который, последовательно изменяя порт назначения, будет выдавать следующую команду: telnet Scan_Host_Name Target_TCP_Port.
Если порт закрыт, telnet вернет сообщение Connection Refused (В соединении отказано) или не вернет ничего. Если же порт открыт, появится заставка соответствующей службы.
Второй способ заключается в использовании WinGate-серверов. WinGate - это обычная proxy-программа, позволяющая через сервер такого типа выходить в Internet, где можно найти немало WinGate-серверов, администраторы которых разрешают анонимное подключение к ним с любых IP-адресов. Это приводит к тому, что злоумышленник получает промежуточный хост, от имени (с IP-адреса) которого, используя различные прикладные службы (telnet, ftp и т. д.), он может вести работу с любыми объектами в Internet, сохраняя при этом полную анонимность.
IP ID (dumb host) сканирование - относительно новая и очень мощная технология, которая позволяет:
- провести максимально скрытное сканирование: На атакуемом хосте нет даже принципиальной возможности узнать адрес взломщика, а трафик злоумышленника может быть замаскирован под обычный трафик [50].
- сканировать системы, доступ к которым закрыт для атакующего брандмауэром.
- частично исследовать правила брандмауэра.
Для того, чтобы при передаче большого IP пакета между сетями с разными MTU его можно было фрагментировать, RFC 791 требует от хоста, отправляющего IP пакет, чтобы совокупность полей Identification (16 бит), Source address, Destination address и Protocol была уникальной в течении времени, пока пакет может быть 'живым' в сети. Так же допускается, что некоторые хосты могут просто использовать уникальные значения для ID поля каждого исходящего пакета вне зависимости от source/destination адресов.
В большинстве случаев разработчики операционных систем пошли по наиболее простому пути присваивая каждой последующей исходящей датаграмме значение поля ID на единицу больше чем в предыдущей.
TCP протокол (RFC 793) требует, чтобы хост отсылал RST пакет в случае, если он получил любой пакет кроме RST не относящийся к существующим соединениям.
Кроме того, процедура «трехстороннего рукопожатия», требует, чтобы по приходу пакета с установленным флагом SYN на открытый порт хост ответил ACK и SYN пакетами.
Сальвадор Сапфилиппо (Salvatore Sanfilippo) из Intesis Security Lab впервые заявил об этом методе 18 декабря 1998 года в конференции BUGTRAQ. Оригинальное название метода Dumb host scan переводится как "сканирование с использованием "немого" хоста" [23].
В оригинале атака позволяет просканировать TCP порты машины с использованием 'немой' (dumb) системы. В качестве ‘немой’ системы может выступать любая машина, которая бы увеличивала IP ID на единицу с каждым отосланным пакетом и не имела трафика во время сканирования, чтобы изменения IP ID контролировались только атакующим. Так же ‘немая’ система должна иметь возможность выполнить сканирование исследуемой машины.
Атакующий, зная адрес любой ‘немой’ системы, посылает SYN пакеты на сканируемые порты исследуемой машины заменяя в отправляемых пакетах свой адрес на адрес немого хоста. При этом он создает поток TCP пакетов на адрес немой машины для отслеживания изменения поля ID в приходящих к нему с 'немой' системы пакетах. При 'сетевом штиле' на dumb машине, каждый ответный пакет с него будет идти с полем ID на единицу большим, чем ранее.
Сканируемый хост в зависимости от того, открыт указанный в пакете порт назначения или нет, отвечает на адрес 'отправителя' либо RST пакетом (если порт открыт) либо SYN|ACK пакетом (если порт открыт).
Получив ответ от исследуемой машины, ‘немой’ хост либо игнорирует его (если это RST пакет), либо (если это SYN|ACK) отвечает сам RST пакетом, так как пришедший пакет не относится ни к одному из соединений. В первом случае, значение поля IP ID в исходящих с ‘немого’ хоста пакетах по прежнему монотонно увеличивается на 1 и атакующий, не обнаружив никакого изменения, делает вывод, что порт закрыт. Во втором случае, отправив RST пакет, ‘немой’ хост увеличил на единицу свой счетчик и атакующий, заметив это изменение, делает вывод, что порт открыт.
Отличительные особенности этого типа уязвимости заключаются в том, что сканируемый хост не знает, кто на самом деле атакующий. Даже полная запись всего трафика на исследуемой машине и последующий анализ не позволят найти злоумышленника. Администратор атакованной машины может по ошибке сделать вывод, что немой хост и есть атакующий.
Сканирование портов данным методом использует уязвимость не исследуемой системы, а третьей машины. Вне зависимости от того подвержена ли исследуемая машина этой уязвимости или нет, взломщик может все равно осуществить такую атаку.
Метод оказывает помощь в исследовании настроек брандмауэров. Фактически, проверка каждого порта на стороне уязвимой машины выглядит как попытка установления соединения от ‘немого’ хоста, и результаты сканирования отражают состояние портов исследуемой машины с точки зрения ‘немого’ хоста. Если ‘немой’ хост использует генерацию IP ID, есть возможность проверить, доступен ли какой-либо порт на исследуемой машине для ‘немой’ системы [20].
Для сканирования машин за брандмауэром требуется, чтобы у атакующего была возможность послать пакет на исследуемый хост с адреса ‘немого’ хоста. Если атакующий и ‘немой’ хост находятся на разных интерфейсах роутера/брандмауэра жертвы, то правильная настройка брандмауэра может быть серьезным препятствием для такого сканирования.
Elie Bursztein опубликовал рекомендацию, где указал на применимость этого сканирования для случая, когда ‘немой’ хост является шлюзом во внутреннюю сеть, а исследуемая система - машина, находящаяся во внутренней сети за ‘немым’ хостом.
Сканирование выполняется тем же путем. Возможно это только в случае, когда атакующий может послать ложный пакет на исследуемую машину. А это возможно только когда все маршрутизаторы на пути от атакующего до жертвы пропустят такой пакет, и будут направлять его в направлении, указанном атакующим. На практике это реализуется в случае, когда ‘немой’ хост не имеет простейшей защиты от спуфинга, а взломщик атакует с машины, непосредственно общающейся с машиной ‘немого’ хоста. Но в этом случае у атакующего есть и обычная возможность выполнить сканирование исследуемой системы, при котором нет необходимости в получении атакующим трафика с нее. Поскольку в качестве ‘немого’ хоста выступает машина из той же сети что и ‘жертва’, для расследования инцидента могут быть использованы журналы аудита, расположенные на ней, в которых будет присутствовать ip-адрес атакующего [36].
С некоторыми модификациями, IP ID сканирование можно проводить и для сканирования UDP портов.
'Обычное' UDP сканирование отличается от TCP тем, что нет схемы ‘рукопожатия’ на уровне протокола, и нет возможности послав один UDP пакет на какой либо порт, получить в ответ какое-либо стандартное подтверждение или опровержение мнения о наличии открытого порта от UDP протокола. Но ОС в случае обращения к несуществующему UDP порту посылают ICMP сообщение об этом. Для сканирования используется метод посылки UDP пакета на анализируемый порт, и ожидание ICMP сообщения с Type=3 (Destination Unreachable), Code=3 (Port Unreachable). Если сообщение не приходит, порт считается открытым, если приходит, порт считается закрытым.
Любой правильно сконфигурированный брандмауэр не пропустит такие сообщения, и для атакующего, использующего ICMP для определения статуса порта, нет возможности узнать, открыт порт или нет.
Также возможно использование IP ID для сканирования, только в качестве ‘немого’ хоста выступает сама исследуемая система. Атакующий следит за изменениями IP ID, при этом сканируя UDP порты. Как только на исследуемой машине приходит пакет с адресом закрытого UDP порта, она отсылает ICMP сообщение об этом, увеличивая тем самым счетчик IP ID. Ответ на следующий TCP пакет атакующего уже будет нести в себе информацию об этом.
Атакующий должен 'видеть' ответы на свои TCP запросы, чтобы отслеживать изменения IP ID, следовательно, метод не позволяет сохранить полную анонимность, но UDP пакеты могут идти с произвольного адреса, так что многие системы обнаружения вторжения могут зарегистрировать сканирование с подставного адреса [42].
Также возможно использовать слежение за IP ID для проведения анонимного UDP сканирования на известные сервисы. Технология заключается в том, чтобы спровоцировать исследуемую машину послать UDP сообщение, которое бы вызвало ответную датаграмму на ‘немой’ хост.
Метод позволяет анонимно определить некоторые сервисы на исследуемой машине, которые можно спровоцировать на исходящее UDP сообщение отправителю.
Для определения 'немых' сервисов типа syslog возможно использование косвенных признаков. Например, сервис syslog не посылает ответов на приходящие датаграммы, но преобразует ip адреса, с которых пришли эти сообщения. Если следить за IP ID на DNS сервере, который будет опрошен в результате преобразования ip адреса отправленной сервису syslog датаграммы, можно заметить изменения IP ID на нем, что будет свидетельством того, что порт открыт [15].
В качестве DNS сервера для такой атаки подойдет тот, который:
1) обладает уязвимой схемой генерации IP ID;
2) не имеет трафика в момент сканирования;
3) будет опрошен в момент получения датаграммы на открытый порт.
2.2.1.2.3.6 "2 в степени" (2^) сканирование и временные особенности сканирования
Используя классическое IP ID сканирование атакующий после отправления пакета на тестируемый порт жертвы ждет либо увеличение IP ID чтобы сделать вывод о том, что порт открыт, либо истечения достаточного времени (Max RTT) чтобы сделать вывод что ответа нет и порт закрыт. Для тестирования следующего порта, атакующий обязательно должен быть уверен, что нет трафика, оставшегося от предыдущего тестирования, так как это может исказить результат. Например, пакет от атакующего на открытый порт жертвы, либо SYN|ACK пакет с исследуемой машины задержались при передаче, и атакующий перешел к тестированию следующего порта (ошибочно посчитав этот тестируемый порт закрытым). Отослав пакет на следующий порт исследуемой машины, он видит увеличение IP ID на ‘немом’ хосте, вызванный задержавшимся пакетом от предыдущего тестирования и делает ошибочный вывод о том, что текущий тестируемый порт открыт. Кроме того, возможно имеется еще и SYN|ACK пакет от этого порта, который внесет свои помехи в тестировании следующего, и так далее.
Сеть может доставлять мегабайты в секунду, и иметь очень небольшую величину RTT, но если на ней встречаются достаточно большие задержки, это вынуждает использовать большие значения для MaxRTT. А поскольку при интенсивном тестировании проверяется много портов, из которых подавляющее большинство - закрыты, время сканирования может быть равно MaxRTT * количество портов. При таком достаточно длительном времени тестировании высока вероятность появления постороннего трафика, который может исказить полученные результаты.
Решением такой проблемы было бы одновременное сканирование нескольких портов. Но атакующий не знает ответные пакеты с каких портов вызвали приращение IP ID, но знает величину этого приращения. Если при одновременном сканировании нескольких портов на каждый отсылать разное количество пакетов (кратное степени 2), то по итоговому приращению IP ID можно легко представить, какие порты открыты [7].
Надежность метода: лишний или потерянный пакет вносит ошибку как при обычном сканировании, так и при "2 в степени" его модификации. Но в последнем случае ошибка несет больший дефект. Одновременно можно тестировать и больше портов, но следует учитывать, что одновременное тестирование 10 портов потребует послать 1023 пакета.
Этот метод также предназначен для определения состояния портов сервера. Основным отличием является использование протокола UDP вместо протокола TCP. Не смотря на то, что организация протокола UDP проще, чем TCP, сканировать UDP-порты гораздо труднее. Это связано, прежде всего, с концепцией протокола UDP как протокола с негарантированной доставкой данных. Поэтому UDP-порт не посылает подтверждение приема запроса на установление соединения, и нет никакой гарантии, что отправленные UDP-порту данные успешно дойдут до него.
Большинство серверов в ответ на пакет, прибывший на закрытый UDP-порт, отправляют ICMP-сообщение «Порт недоступен» (Port Unreachable - PU). Таким образом, если в ответ на UDP-пакет пришло ICMP-сообщение «PU», то сканируемый порт является закрытым, в противном случае (при отсутствии «PU») порт открыт. Поскольку нет гарантии, что запросы хоста дойдут до сервера, пользователь должен позаботиться о повторной передаче UDP-пакета, который, по всей видимости, оказался потерянным [24].
Этот метод работает очень медленно из-за использования на некоторых машинах т.н. «компенсации», ограничивающей частоту генерирования ICMP-сообщений об ошибке. Например, ядро Linux ограничивает частоту генерирования ICMP-сообщения «адресат недостижим» (Destination Unreachable) до 80 сообщений за 4 секунды, с простоем ¼ секунды, если это ограничение было превышено. Кроме того, для использования данного метода (а именно – для обнаружения ICMP-сообщений об ошибке) пользователь должен обладать статусом root на хосте, с которого производится сканирование.
Этот метод используется в случае, когда пользователь, проводящий сканирование, не обладает статусом root на хосте. Поскольку не-root пользователь не может «читать» ICMP-сообщение PU, в ОС, поддерживающих механизм сокетов (например в Linux), имеется возможность получения информации о состоянии UDP-порта косвенным способом. Так, например, попытка вызова функции write() на закрытый порт обычно приводит к возникновению ошибки.
Функция recvfrom() в этом плане более информативна. Вызов ее на неблокированный UDP-сокет сервера обычно возвращает ошибку EAGAIN (Try Again – «попытайтесь еще раз», код 13) в случае, когда ICMP-сообщение не было принято, и ECONREFUSED (Connection Refused – «соединение закрыто», код 111), если ICMP-сообщение было принято [50].
Может показаться, что сканирование UDP-портов не дает той полноты информации, какую можно получить при сканировании TCP-портов. Однако, принимая во внимание существующие уязвимости в службах, использующих протокол UDP (например, уязвимость в rpcbind-демоне ОС Solaris, который может находится на любом UDP-порту с номером выше 32770), сканирование UDP-портов может оказаться эффективным.
Таким образом, по всем вышеперечисленным признакам возможно определить состояние портов сканируемого сервера. Наибольшая эффективность достигается при использовании комплексного метода сканирования, предусматривающего выбор конкретного метода либо их совокупности в зависимости от конкретной ситуации. Как правило, для сканирования защищенных сетей необходимо использование целого ряда методов, тогда как для сканирования слабо защищенных хостов достаточно одного.