Для реализации понадобится уверенные знания работы TCP/IP и желание понять. В результате мы получим возможность сканировать удаленную машину на открытые порты от чужого адреса по следующией схеме (картинка из мануала по nmap):
Теоретическое введение
Как можно увидеть на википедии, каждому отправляемому IP пакету назначается его номер (правда фрагментированные пакеты имеют один номер), хранимый в специальном 16ти битном поле. При переполнении поля счет начинается с нуля. Сделав 2 замера номеров сетевого пакета можно судить о сетевой активности наблюдаемого компьютера.
Установка TCP соединения происходит по схеме «тройного рукопожатия». Клиент посылает серверу пакет с установленным флагом SYN, сигнализирующим предложение создать соединение. В случае, если серверу удается создать socket для соединения, то он ответит клиенту пакетом с встречным предложением SYN и запросом на подтверждение ACK (где в свою очередь клиент подтверждает свое желание о создании TCP соединения пакетом с флагом ACK). В случае, если сервер отказывает в соединении, он отсылает клиенту отказ в виде пакета с флагом RST, на что свою очередь клиент грустно отмалчивается. Базируясь на этом различии мы и построим сканирование открытых портов от чужого имени.
Практика
Как заметил уважаемый vanaf, метод будет работать если сканируемый и сканирующий хосты находятся в одной подсети или если в разных то сканирующий и подставной хосты должны находятся в одной подсети.
Для реализации мы будем использовать один из основных инструментов специалиста по компьютерной безопасности hping3. В схеме участвуют 3 машины, условно названные атакующей, целевой и подставной, от имени которой мы будем вести сканирование. В роли подставной машины необходимо выбрать такую, которая генерирует минимальное количество трафика (в идеале не генерирует вовсе). Для того, что бы узнать эту интимную подробность подставной машины, мы будем общаться с ней и наблюдать за изменением номеров пакетов. В идеале, номер пакета при каждой нашей коммуникацией с ней должен возрастать на единицу, что означает что за этот промежуток времени она не вела больше коммуникаций. Для этого запустим hping следующим образом:
root@Atom:~# hping3 -r 192.168.2.140
Ключ -r говорит hping3 показывать прирост номера пакета. Как видим, с каждой нашей коммуникацией он растет на 1, то есть свободен от лишнего общения. Поставим этот процесс на бесконечный «ping» для мониторинга изменения id пакета.
Далее, нам надо на целевую машину отправить предложение установить TCP соединение, причем предложение составленное специфическим образом: в поле источника пакета установим адрес подставной машины, на которую и будут идти ответы. Если указанный порт на целевой машине закрыт, то она пошлет подставной машине отказ (RST), что проигнорирует подставная машина. Если же порт открыт. то целевая машина пошлет встречное предложение установить соединение (SYN + ACK), на что подставная машина будет вынуждена ответить отказом, то есть пакетом с флагом (RST). Именно здесь мы обнаружим, что наша ранее отдыхающая машина кому-то что-то сказала именно в тот момент, когда мы отослали предложение на соединение от ее имени. Для избежания случайностей, эксперимент повторяется.
Послать запрос на соединение от чужого имени можно следующим образом:
root@Atom:~# hping3 -c 1 -S -a 192.168.2.140 192.168.2.1 -p 5222
--- 192.168.2.1 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
Где: -c 1 означает посылку только одного пакета;
-S установить флаг SYN
-a 192.168.2.140 в роли источника пакета установить адрес 192.168.2.140 (адрес подставной машины в нашем случае)
192.168.2.1 адрес целевой машины
-p 5222 целевой TCP порт
Ответа на пакет мы не получили потому что он ушел подставной машине вероятно вынуждать ее ответить отказом, что мы и обнаружим.
В случае, если порт открыт, мы увидим следующую картину:
len=46 ip=192.168.2.140 ttl=128 id=+1 sport=0 flags=RA seq=4 win=0 rtt=0.2 ms
len=46 ip=192.168.2.140 ttl=128 id=+1 sport=0 flags=RA seq=5 win=0 rtt=0.2 ms
len=46 ip=192.168.2.140 ttl=128 id=+2 sport=0 flags=RA seq=6 win=0 rtt=0.2 ms
len=46 ip=192.168.2.140 ttl=128 id=+1 sport=0 flags=RA seq=7 win=0 rtt=0.2 ms
len=46 ip=192.168.2.140 ttl=128 id=+1 sport=0 flags=RA seq=8 win=0 rtt=0.2 ms
Видите на 3й строке что подставная машина в тот самым момент успела пообщаться с кем-то еще? Скорее всего это отказ (RST) на предложение о взаимности (SYN + ACK), так подставная машина на самом деле не слала SYN. Для верности эксперимент повторяется.
Для удобства можно использовать ключи -i для задачи временного интервала и -p ++ увеличения порта на 1 с каждым пакетом.
Заключение
Этим же методом можно и забанить ничего не подозревающую подставную машину, если на целевой стоит система обнаружения вторжений.
Это лишь один из множества впечатляющих применений hping3. Им можно пинговать когда icmp запрещен (он посылает пакет по TCP по умолчанию на нулевой порт). Так же может использоваться для передачи файлов даже через строго настроенные фаерволлы (хоть через пинг), работать как traceroute не только на основе icmp, но и UDP и TCP, помогает определить удаленную ОС, может быть весьма специфичным трояном и многое многое другое. Очень рекомендую познакомится с ним поближе. У него хороший HOW-TO ;)
Если Вам понравилось, принимаю благодарности.
UPD:
Спасибо jcmvbkbc за информацию о том, что аналогичный трюк можно сделать при помощи nmap: nmap.org/book/idlescan.html
port scan
, скрытое сканирования
, hping
+75
138
Sicness 24,1
комментарии (35) отслеживать новые: в почте в трекере
+1
jcmvbkbc, 23 октября 2010 в 21:15 #
В теоретическом введении ошибка:
Как можно увидеть на википедии, каждому отправляемому TCP пакету назначается его номер, хранимый в специальном 32х битном поле. При переполнении поля счет начинается с нуля. Сделав 2 замера номеров TCP пакета можно судить о сетевой активности по протоколу TCP наблюдаемого компьютера.
если внимательно прочитать статью в википедии на которую дана ссылка, можно увидеть что в TCP заголовке два номера, один считает байты одной стороны, другой — второй стороны соединения.
Эти номера выбираются случайным образом при установлении соединения и имеют смысл только для этого соединения.
id на который ты смотришь, это 16-битный id из IP заголовка.
–1
Sicness, 23 октября 2010 в 21:17 #
↵
↑
Да, номера два, верно, подзабыл.
Но все же поле имеет смысл не только для этого соединения. Проверенно на практике.
0
jcmvbkbc, 23 октября 2010 в 21:30 #
↵
↑
Прочитай хотя бы внимательно пункт ru.wikipedia.org/wiki/Tcp#.D0.A3.D1.81.D1.82.D0.B0.D0.BD.D0.BE.D0.B2.D0.BA.D0.B0_.D1.81.D0.BE.D0.B5.D0.B4.D0.B8.D0.BD.D0.B5.D0.BD.D0.B8.D1.8F по своей ссылочке.
0
Sicness, 23 октября 2010 в 21:35 #
↵
↑
Ох… Этот метод работает, проверен мной, описан в книге Джонс К.Д., Шема М., Джонсон Б.С. «Инструментальные средства обеспечения безопасности» и описан в официальном мануале по hping3.
Если Вы не верите ничему из этого, попробуйте сами.
+1
jcmvbkbc, 23 октября 2010 в 21:44 #
↵
↑
Я не про метод, а про его интерпретацию. id — идентификационный номер IP-датаграммы, к SEQ/ACK из TCP не имеющий никакого отношения.
0
Sicness, 23 октября 2010 в 21:48 #
↵
↑
Да, действительно. Спасибо, сейчас поправлю.
+3
vanaf, 23 октября 2010 в 21:36 #
Интересно.
Но хочется отметить что оно будет работать если сканируемый и сканирующий хосты находятся в одной подсети или если в разных то сканирующий и подставной хосты должны находятся в одной подсети (в противном случае маршрутизатор скорее всего отвергнет пакет с адресом не соответствующим интерфейсу)
+2
amarao, 23 октября 2010 в 22:38 #
↵
↑
Почему отвергнет? Для этого требуется особая настройка маршрутизатора, которая вовсе не гарантирована. Другое дело, что ответ не придёт.
0
Evgeny_Shiryaev, 23 октября 2010 в 21:41 #
Анонимное сканирование портов говорите? А почему про nmap ни слова? В деле сканирования портов nmap — первый помощник.
0
Sicness, 23 октября 2010 в 21:45 #
↵
↑
Ну я же не обзор существующих методов сканирования пишу, а всего лишь частный случай :)
Тем более что я сомневаюсь что nmap способен на такой трюк (то есть через не контролируемого посредника). Я буду только рад, если Вы меня поправите.
+3
jcmvbkbc, 23 октября 2010 в 21:51 #
↵
↑
nmap с ключом -sI
-sI zombie host[:probeport] (idle scan).
This advanced scan method allows for a truly blind TCP port scan of the target (meaning no packets are sent to the
target from your real IP address). Instead, a unique side-channel attack exploits predictable IP fragmentation ID
sequence generation on the zombie host to glean information about the open ports on the target. IDS systems will
display the scan as coming from the zombie machine you specify (which must be up and meet certain criteria). This
fascinating scan type is too complex to fully describe in this reference guide, so I wrote and posted an informal
paper with full details at nmap.org/book/idlescan.html.
+2
Evgeny_Shiryaev, 23 октября 2010 в 21:54 #
↵
↑
Вы меня опередили :-)
Для тех, кто не хочет ходить по ссылке, приведу картинку:
0
Sicness, 23 октября 2010 в 22:02 #
↵
↑
Я позаимствую картинку в статью для наглядности…
0
Evgeny_Shiryaev, 23 октября 2010 в 21:53 #
↵
↑
nmap.org/book/idlescan.html
0
Calvrack, 24 октября 2010 в 11:58 #
↵
↑
habrahabr.ru/blogs/personal/40413/ на хабре было два года назад.
0
stas_agarkov, 24 октября 2010 в 15:51 #
↵
↑
но там не было пошагового выполнения с командами!
0
Sicness, 24 октября 2010 в 16:19 #
↵
↑
Там общая теория с ссылкой на мануал по nmap. Эта же статья про hping3 и когда я писал, я не знал что nmap так умеет. В предварительном поиске по хабру старая статья мне не попалась.
Да и это наверное не плохое дополнение.
0
lunatik42, 23 октября 2010 в 22:51 #
↵
↑
Наверно потому что nmap действует от лица машины, на которой он запущен.
+1
lunatik42, 23 октября 2010 в 22:52 #
↵
↑
Упс… не стоило отвечать через час после того, как открыл статью и не обновлял комментарии. Вопрос снят =)
–2
AstonMartin, 23 октября 2010 в 22:00 #
Не особо понятен смысл данного действия. В сканировании портов нет ничего опасного и поэтому незачем прятаться.
+2
Evgeny_Shiryaev, 23 октября 2010 в 22:31 #
↵
↑
Вы не совсем правы. Сканирование портов — это (как правило) первый шаг в атаке на сервер, поэтому грамотно настроенная IDS отследит скан, и предупредит админа. А с админами лучше не шутить ;-)
+1
AstonMartin, 23 октября 2010 в 22:36 #
↵
↑
Каждый публично доступный сервер в интернете каждый день сканируется десятки, сотни раз. Это боты ищут уязвимости. И никто на эти сканы не реагирует, только если это не сайт пентагона какого-нибудь.
–1
amarao, 23 октября 2010 в 22:41 #
↵
↑
Я одно время развлекался с автобаном любого IP, обратившегося на 21ый порт. Я точно знаю, что telnet'а у меня наружу нет, если кто-то постучался, значит что-то сканит.
Для злоумышленника с большой вероятностью это означает, что при линейном сканировании все порты будут закрыты (все используемые порты находятся выше), при рандомном сканировании хост просто перестанет отвечать через некоторое время.
+1
AstonMartin, 23 октября 2010 в 22:50 #
↵
↑
Одно дело развлекаться, а другое: стали бы вы внедрять эту схему на сервер хостинга с парой сотен клиентов?
Это я все к чему? К тому что нет никакого смысла скрывать работающие сервисы. Принцип «безопасность через неясность» не работает.
+4
amarao, 23 октября 2010 в 23:47 #
↵
↑
Именно там бы и стал, если бы руки дошли. В нормальной ситуации не должно быть обращения к посторонним портам, особенно если исключить невинные класса finger/whois. Если на хостинг кто-то стучится по 3389 порту (а там линух внутрях), то это явный злоумышленник, или направленный им клиент. Забанить на 5 минут — вполне разумное решение.
–1
AstonMartin, 24 октября 2010 в 09:47 #
↵
↑
Ну вот смотрите. Вы забанили злоумышленника на 5 минут. Он сразу это понимает и берет из пачки другой 3-х долларовый впс и начинает исследовать ваш хост дальше, уже более аккуратно. Плюс он сейчас знает, что админ параноик и надо действовать очень осторожно. Т.е. увеличения безопасности вашей системы не произошло.
Кроме того, IDS сами часто имеют серьезные уязвимости. Например, Snort Unified1 Output Remote Denial Of Service Vulnerability
Плюс я сам несколько раз сталкивался с ложными срабатываниями IDS когда банился «дружественный» хост и диагностировать эту плавающую причину пропадания коннекта весьма сложно.
+2
Sicness, 24 октября 2010 в 09:54 #
↵
↑
А что Вы предлагаете? Сэкономить злоумышленнику 3х долларовый впс? :)
Блокировка может защитить от некоторых автоматизированных систем и отгородится от лишнего траффика с ламерами.
0
amarao, 23 октября 2010 в 22:42 #
↵
↑
то есть, пардон, 23ий. Попутал.
0
lybin, 23 октября 2010 в 23:38 #
Спасибо, интересно!
0
moooV, 24 октября 2010 в 00:46 #
А почему злоумыщленник — принтер? о_0
+3
jcmvbkbc, 24 октября 2010 в 01:47 #
↵
↑
Не злоумышленник, а «зомби» — подставной хост. Потому что принтер, скорее всего, не будет ни с кем трепаться по IP в свободное время, а это — ключевой момент технологии.
0
mafet, 24 октября 2010 в 13:36 #
Да, интересный способ =)
0
mafet, 24 октября 2010 в 13:37 #
↵
↑
Правда относительно сложно нынче найти подставной хост с наличием инета (в пределах локалки, думаю это теперь мало кому интересно), такой, который не будет проявлять вообще никакой активности. Как показано на картинке — это может быть только какое-нибудь устройство типа принтера, свитча и тп.
0
Sicness, 24 октября 2010 в 16:22 #
↵
↑
Да не, в корпоративных и крупных сетях часто можно найти такие ПК.
0
stas_agarkov, 24 октября 2010 в 17:15 #
спасибо!
очень интересно, понятно написано
