Pull to refresh

Comments 35

В теоретическом введении ошибка:
Как можно увидеть на википедии, каждому отправляемому TCP пакету назначается его номер, хранимый в специальном 32х битном поле. При переполнении поля счет начинается с нуля. Сделав 2 замера номеров TCP пакета можно судить о сетевой активности по протоколу TCP наблюдаемого компьютера.

если внимательно прочитать статью в википедии на которую дана ссылка, можно увидеть что в TCP заголовке два номера, один считает байты одной стороны, другой — второй стороны соединения.
Эти номера выбираются случайным образом при установлении соединения и имеют смысл только для этого соединения.

id на который ты смотришь, это 16-битный id из IP заголовка.
Да, номера два, верно, подзабыл.
Но все же поле имеет смысл не только для этого соединения. Проверенно на практике.
Ох… Этот метод работает, проверен мной, описан в книге Джонс К.Д., Шема М., Джонсон Б.С. «Инструментальные средства обеспечения безопасности» и описан в официальном мануале по hping3.
Если Вы не верите ничему из этого, попробуйте сами.
Я не про метод, а про его интерпретацию. id — идентификационный номер IP-датаграммы, к SEQ/ACK из TCP не имеющий никакого отношения.
Да, действительно. Спасибо, сейчас поправлю.
Интересно.
Но хочется отметить что оно будет работать если сканируемый и сканирующий хосты находятся в одной подсети или если в разных то сканирующий и подставной хосты должны находятся в одной подсети (в противном случае маршрутизатор скорее всего отвергнет пакет с адресом не соответствующим интерфейсу)
Почему отвергнет? Для этого требуется особая настройка маршрутизатора, которая вовсе не гарантирована. Другое дело, что ответ не придёт.
UFO just landed and posted this here
Ну я же не обзор существующих методов сканирования пишу, а всего лишь частный случай :)
Тем более что я сомневаюсь что nmap способен на такой трюк (то есть через не контролируемого посредника). Я буду только рад, если Вы меня поправите.
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.
UFO just landed and posted this here
Я позаимствую картинку в статью для наглядности…
UFO just landed and posted this here
но там не было пошагового выполнения с командами!
Там общая теория с ссылкой на мануал по nmap. Эта же статья про hping3 и когда я писал, я не знал что nmap так умеет. В предварительном поиске по хабру старая статья мне не попалась.
Да и это наверное не плохое дополнение.
Наверно потому что nmap действует от лица машины, на которой он запущен.
Упс… не стоило отвечать через час после того, как открыл статью и не обновлял комментарии. Вопрос снят =)
Не особо понятен смысл данного действия. В сканировании портов нет ничего опасного и поэтому незачем прятаться.
UFO just landed and posted this here
Каждый публично доступный сервер в интернете каждый день сканируется десятки, сотни раз. Это боты ищут уязвимости. И никто на эти сканы не реагирует, только если это не сайт пентагона какого-нибудь.
Я одно время развлекался с автобаном любого IP, обратившегося на 21ый порт. Я точно знаю, что telnet'а у меня наружу нет, если кто-то постучался, значит что-то сканит.

Для злоумышленника с большой вероятностью это означает, что при линейном сканировании все порты будут закрыты (все используемые порты находятся выше), при рандомном сканировании хост просто перестанет отвечать через некоторое время.
Одно дело развлекаться, а другое: стали бы вы внедрять эту схему на сервер хостинга с парой сотен клиентов?

Это я все к чему? К тому что нет никакого смысла скрывать работающие сервисы. Принцип «безопасность через неясность» не работает.
Именно там бы и стал, если бы руки дошли. В нормальной ситуации не должно быть обращения к посторонним портам, особенно если исключить невинные класса finger/whois. Если на хостинг кто-то стучится по 3389 порту (а там линух внутрях), то это явный злоумышленник, или направленный им клиент. Забанить на 5 минут — вполне разумное решение.
Ну вот смотрите. Вы забанили злоумышленника на 5 минут. Он сразу это понимает и берет из пачки другой 3-х долларовый впс и начинает исследовать ваш хост дальше, уже более аккуратно. Плюс он сейчас знает, что админ параноик и надо действовать очень осторожно. Т.е. увеличения безопасности вашей системы не произошло.

Кроме того, IDS сами часто имеют серьезные уязвимости. Например, Snort Unified1 Output Remote Denial Of Service Vulnerability

Плюс я сам несколько раз сталкивался с ложными срабатываниями IDS когда банился «дружественный» хост и диагностировать эту плавающую причину пропадания коннекта весьма сложно.
А что Вы предлагаете? Сэкономить злоумышленнику 3х долларовый впс? :)
Блокировка может защитить от некоторых автоматизированных систем и отгородится от лишнего траффика с ламерами.
то есть, пардон, 23ий. Попутал.
А почему злоумыщленник — принтер? о_0
Не злоумышленник, а «зомби» — подставной хост. Потому что принтер, скорее всего, не будет ни с кем трепаться по IP в свободное время, а это — ключевой момент технологии.
Правда относительно сложно нынче найти подставной хост с наличием инета (в пределах локалки, думаю это теперь мало кому интересно), такой, который не будет проявлять вообще никакой активности. Как показано на картинке — это может быть только какое-нибудь устройство типа принтера, свитча и тп.
Да не, в корпоративных и крупных сетях часто можно найти такие ПК.
Sign up to leave a comment.

Articles