Значения TTL в популярных ОС известны (http://www.binbert.com/blog/2009/12/default-time-to-live-ttl.../), например, в Linux 2.6.x и FreeBSD - 64, в Windows - 128.Если в сети имеется маршрутизатор на базе *nix или если есть возможность завернуть трафик на определенный хост, или настроен PBR на прозрачный прокси - на этой машине нужно выполнить:
# tcpdump -vv -n -i @interface@ 'ip[7:2] != 128 and ip[7:2] != 64'
Соответственно, если пакеты приходят с вашего маршрутизатора после PBR, значение TTL нужно уменьшить на 1.
Но эта информация неточная, так как TLL в ОС можно поменять.
Также полезным дополнением внутри этой команды будет 'src net @ваша внутренняя сеть@' и 'src net not @сеть, которую нужно исключить@'.
URL:
Обсуждается: http://www.opennet.ru/tips/info/2428.shtml
PBR ват ис дас?
Policy base routing, не?
http://en.wikipedia.org/wiki/Policy-based_routing , да.
http://www.acronymfinder.com/Information-Technology/PBR.html :)
я видел патчик на ядро linux, который прикручивает "плавающий" ttl.
iptables -t mangle -A POSTROUTING -o $EXT_IF -j TTL --ttl-set 64правда повлияет на traceroute.
а можно
iptables -t mangle -A POSTROUTING -o $EXT_IF -j TTL --ttl-inc 1 :)
На TTL далеко не уедешь. Вот чем пользуются православные пацаны: http://lcamtuf.coredump.cx/p0f.shtml
Детские проверки от младенцев. По последнему пункту - p0f и прочие нмапы блочится на раз,
профиль в соединения в linux/BSD то же меняется на раз, помнится у меня еше в 2007 опенок по данным нмапа был W2k0
> p0f и прочие нмапы блочится на разкак p0f может "блочится" если он ничего не посылает в сеть? ;)
Имелась ввиду подмена некоторых параметров стека tcpip, по которым можно определить операционную систему. Проблемка только в том, что придется это проделать со всеми машинами, расположенными за nat, заодно подправив и ttl. На практике это бывает проблематично, если только это не пара машин в квартире.
TTL поменять не есть вопрос. Scrub на интерфейсе устроить - и все. -1
Коллеги, какой вы интерфейс скрабить собираетесь? Речь шла, скорее всего, об устройствах типа домашних рутеров.
На домашних роутерах чаще всего линуксь с айпитаблесом. Поэтому сильно резвых детектеров можно айпитаблесом немного нагнуть чтобы не зарывались. Лучше всего для таких вещей подходит прошивка openwrt или dd-wrt. Пусть удетектируются.
И на многих домашних роутерах openwrt стоит?
>На домашних роутерах чаще всего линуксь с айпитаблесом. Поэтому сильно резвых детектеров
>можно айпитаблесом немного нагнуть чтобы не зарывались. Лучше всего для таких
>вещей подходит прошивка openwrt или dd-wrt. Пусть удетектируются.Особо резвых нагибаторов при малейшем подозрении шейпят. И хоть полгорода через себя пропускай ...
Не упоминая о том, что техника боянная - вопрос в её целесообразности. Как сказано выше - кому надо, детектеров передетектят, а домашний роутер, натящий домашний же десктоп и ноут детектить и смысла нет.
>Не упоминая о том, что техника боянная - вопрос в её целесообразности.
>Как сказано выше - кому надо, детектеров передетектят, а домашний роутер,
>натящий домашний же десктоп и ноут детектить и смысла нет.У вас ограниченные понятия о применениях SOHO рутеров.
Гораздо более надежной является техника, которая использует другие особенности стека, не TTL. Можно погуглить в сети файл fnat.pdf, в нём рассказано - правда, исходников детектора нет, увы.
я так и не понял смысла статьи, точней цели ее написания.автор может пояснит зачем (и кому) всё-таки надо "Выявлять NAT-устройства в сети" ??
я вижу лишь для провайдеров интерес да и то ооочень сомнительный особенно в 21 веке, в эпоху безлимита и оптики в квартиру. профиль потребления трафика даст больше инфы но и он далеко не 100% верен.
>я так и не понял смысла статьи, точней цели ее написания.
>
>автор может пояснит зачем (и кому) всё-таки надо "Выявлять NAT-устройства в сети"
>??
>
>я вижу лишь для провайдеров интерес да и то ооочень сомнительный особенно
>в 21 веке, в эпоху безлимита и оптики в квартиру. профиль
>потребления трафика даст больше инфы но и он далеко не 100%
>верен.Скажем, есть сеть предприятия, где выход в Интернет ограничен по политическим соображениям. Предприятие большое. Есть powerusers, которые покупают SOHO рутеры, для того, чтобы не оформлять документы для подключения.
и кому это там (где "выход в Интернет ограничен по политическим соображениям") интересно ? пользователям с SOHO или остальным пользователям копроративной сети?
бредятина. вы не ответили на вопрос.
тем паче что пляски с tcpdump предлагается делать на своем подконтрольном nix маршрутере, а вовсе не на SOHO коробочке.
походу речь всетаки о провайдере, только это не пишется напрямую (незнаю зачем это скрывать).
во-первых он по ttl может не увидеть толком ничего, например PF\srub это лечит, во вторых - провайдер лишится просто напросто клиента (не дадут работать через soho коробку - уйдут к йоте или жпрс)
>и кому это там (где "выход в Интернет ограничен по политическим соображениям")
>интересно ? пользователям с SOHO или остальным пользователям копроративной сети?
>бредятина. вы не ответили на вопрос.
>тем паче что пляски с tcpdump предлагается делать на своем подконтрольном nix
>маршрутере, а вовсе не на SOHO коробочке.
>походу речь всетаки о провайдере, только это не пишется напрямую (незнаю зачем
>это скрывать).
>во-первых он по ttl может не увидеть толком ничего, например PF\srub это
>лечит, во вторых - провайдер лишится просто напросто клиента (не дадут
>работать через soho коробку - уйдут к йоте или жпрс)Я не буду вступать в полемику, на тему "и кому это там интересно? бредятина.". На ваш вопрос
> автор может пояснит зачем (и кому) всё-таки надо "Выявлять NAT-устройства в сети" ??я ответил частично, а именно на часть вопроса "кому". Успокойтесь - я не провайдер.
Для чего вы начали искать причину? Мне кажется, это выходит за рамки этой ветки. Удачи.
вашу удачу оставьте себе как и спокойствие.
вы описывали сферу применения своего рецепта но сформулировали двусмысленно.
Кому, кому, это нужно кульхацкерам из районых сетей.
Для узнавания MAC адреса, по которому фильтруется,
например, удалённый доступ к девайсу, а там и пароль доступа,
и в итоге халявный доступ.Быстрее конечно перегрызть провод в подъезде, в 4 часа утра,
и впиндюрить туда кольцевой хаб на резисторах. http://www.colan.ru/img/artpics/2003/02/fbr2902.png
Речь идёт о следущей ситуации. Вот я сижу админ такой, у меня есть точка, за которой сразу-интернет. А к этой точке я разрешаю проходить всем клиентам, оплатившим. Так вот мне будет интересно проанализировать входящий трафик к этой точке с серой стороны (с локалки) на предмет того, а не сидят ли несколько человек через нат, эмулируя одно подключения к моей точке? Да, это детектится ЗНАЧИТЕЛЬНО проще. Это детектится по номерам исходящих портов с подозреваемого на nat-box компа. я даже такой скрипт на perl написал-ловит pcap пакеты (10 мегабит) и если с какой то машины исходящие порты идут не ровным приращением, а как бы из разных обособдленных областей-там точно нат.
Нат как правило пытается делать static ports, то есть пытается отдать пакет с того же порта что и его клиент. Если комп один - биение номера исходящего порта предсказуемо на определенном радиусе. Если это нат - то у него будет несколько (по числу клиентов) центров таких радиусов. Элементарно пишется анализатор.
