Проходим сквозь стены NAT-ов

[Danov]

Новый канал для работы троянцев?

[bondbig]

я не понял, в чём новизна? Посредник между двумя «заНАЧеными» хостами, классика. OpenVPN на tcp\443 гораздо более «проникающий», даже NAT не нужен, достаточно прокси с разрешенным методом CONNECT на порт 443 (почти всегда так и есть)

[bondbig]

хм, почитал доку. Работает на основе icmp time exeeded. Трудноприменимо. Зачастую трассировки запрещены через NAT-шлюз, но даже если разрешены, то приоритет у icmp самый низкий, тупить будет такой туннель нещадно.

[Dipp]

ICMP там только для открытия коннекта. Полезный трафик по UDP идёт.

[bondbig]

и вы наивно полагаете, что stateful firewall такое безобразие пропустит?

[intnzy]

я совершенно прогматически утверждаю, что куча «админов» про стейтфул — даже не слышала, да.

[bondbig]

покажите мне современный не-стейтфул файервол. Фильтр пакетов виндовый не в счет. )

[intnzy]

омг. вы читать умеете? где я сказал, что файер не стейтфул? я сказал, что куча одминов дальше allow all to all не идет.

[bondbig]

пожалуйста, ознакомьтесь для начала с понятием statful firewall.

[timoor]

Пардон, что влезаю… а зачем тогда вообще нужен файрвол, если его существование выражено только в allow all to all? Это уже не файрвол получается, а фигня какая-то…

[maxcom]

там же UDP, на нем нормального state как в tcp нет. То что делает statful firewall в случае UDP легко обманывается

[Roy]

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

[bondbig]

да, я в курсе. В случае с UDP файер на некоторое время запоминает две пары ip:port, обоих сторон, но только в случае инициирования со стороны LAN, со стороны WAN дропаются пакеты, не имеющие такого «виртуального state». Хитрость сабжа именно это и эксплуатирует, как я понял.

[Busla]

а там нет посредника
вкратце как это работает:
На первом этапе сервер за натом определяет публичный ip клиента, для этого сервер регулярно шлёт ICMP echo request на фиксированный ip 3.3.3.3 Клиент желающий подключиться щлёт на публичный ip сервера поддельный пакет ICMP Time Exceeded, NAT его пропускает, сервер узнаёт ip клиента.
Далее и клиент и сервер начинают слать друг дргугу на публичные ip udp пакеты — NAT их пропускает т.к. это соответствует традиционному сценарию работы с udp.

Никаких посредников в итоге не требуется. Правда при такой реализации за NAT может быть только один сервер, т.к. соединение инициируется по (не)ответу от магического ip 3.3.3.3

[mechmind]

Как udp проходит сквозь nat? В голову приходит только идея дописывать firewall'ом заголовки в пакет, которые сервер в обязательном порядке запишет в свой пакет и firewall сможет таким образом опознать ответный пакет и пропустить его внутрь сети. При таком подходе эти заголовки должны быть унифицированы.

[maxcom]

по идее антиспуфинг на клиентском МЭ должен помешать слать поддельный ICMP, ну или где-нибудь по пути его дропнут

[baxtep2]

я не понял, для соединения двух клиентов сидящих за NAT нужен сервер с открытым портом?

[baxtep2]

нашел описание примерно понял.

[tsippa]

вот еще en.wikipedia.org/wiki/Traversal_Using_Relay_NAT
собственно это все давно используется в скайпе

[antazy]

Думаю вы не дочитали.

UDP_hole_punching требует «public server with a well-known globally reachable IP address.»

Он предлагает без «человека по середине».

[klark]

Напомнило Hamachi

[gag_fenix]

Хамачи же использует центральный сервер посредник, не?

[Kastrulya]

да, но мне тоже он вспомнился. много чего помогает.

[lasc]

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

[isea]

Даже если внешние IP-адреса NAT-шлюзов будут определяться через ICMP, для работы UDP-тоннеля еще необходимо знать внешние адреса UDP-портов, которые NAT-шлюз открыл для данного трафика. Совсем необязательно эти номера будут совпадать с номерами внутренних портов клиента и сервера за NAT. Серверы STUN обычно для того и используются, чтобы кроме внешних IP-адресов также выявить и внешние UDP-порты. Из описания pwnat я не смог понять, как же там определяются внешние номера UDP-портов.

[sovnarkom]

Note: pwnat defaults source and destination
ports to 2222. Any unprivileged user can set UDP source and dest ports.

[0lympian]

Не знаю, как реализовано в конкретно этом проекте, но в принципе номер порта можно сообщить в ICMP-ответе ;)

[Roy]

Клиент его сам не знает.

[Roy]

frag! :)

[Chamie]

Клиент узнает порт, привязанный к серверу на NAT'е и сообщит его в ответе. А по ответу сервер узнает порт NAT'а клиента.

[Roy]

Как клиент узнает порт, привязанный к серверу на NAT'е?

[Chamie]

А порт, с которого пришёл пакет?
(или я что-то путаю?)

[Roy]

Чтобы он его получил сервер должен знать номер порта на NAT'е клиента — а он его тоже не знает.
Это замкнутый цикл и чтобы его преодолеть нужен хост-посредник.

[Chamie]

Загуглил… И правда, на уровне ICMP не существует понятия «порт», так что никак. Вы правы.

[AwesomeBanana]

Насколько мне известно, UDP hole punching реализован в uTP. Еще не приходилось видеть его в действии.

[Kastrulya]

хм. а если -P FORWARD DROP?

[Kastrulya]

у меня как раз политика в форварде — дропать. и уже руками открываю нужные порты

[Boiler]

Интересно. Как называется? Кто скульптор?

[0lympian]

Насколько я понимаю, в данной «технологии» за одним натом может быть только один сервер. Иначе оба будут слать одинаковые ICMP echo request на 3.3.3.3, и пакет пойдет на последний отправивший из них (хотя опять же, последнее от реализации ната зависит).

[0lympian]

Кстати, по этой же причине сервер очень уязвим man-in-the-middle атаке: пиратский хост за тем же натом может слать пакеты на 3.3.3.3 чаще и нат будет пересылать пакеты на него. Ну а далее уже все просто :)

[cblp]

Обманщик будет обманут!

[Roy]

Нет, в icmp для этого id есть.
Как по-вашему работают одновременно несколько пингов с разных клиентов из-за NAT? :)

[Roy]

Хотя вру. Клиент этого id знать не может, а значит он фиксированный.
Да — уязвимость.

[Roy]

Чтоб тот же CONNECT заблокировать нужен ssl-interception, мало того, что работающие решения денег стоят, так еще и практика довольно спорная…
С web-proxy все совсем сложно.
Так что про «хорошего админа» — это вам кажется.

[Roy]

443 из списка тоже исключим? ;)
А всякие OpenVPN да Skype по нему и ходят.

Про подумать головой это вы хорошо заметили.

[Roy]

Весь CONNECT не запретить — по нему https работает.
Если приложение гонит совсем не-SSL трафик то можно отсеять фильтром.
Если инкапсулирует свой трафик в SSL — то ой, только interception — подмена сертификата и прочие радости жизни.

А вот icmp-tunneling — это скучно и тривиально, и закрывается и отслеживается на раз. Когда-нибудь ваши админмы его заметят.

Значительно интересней dns-tunneling, закрыться от него можно, но настолько противно, что многие предпочитают не связываться :)

[Roy]

вы бредите(зачеркнуто) заблуждаетесь

[Roy]

Кстати а чего мы про OpenVPN — SSTP же есть еще с Vista.
Тот же SSL VPN и порт 443 по-дефолту :)

[Roy]

Учитывая, что сабж вообще не для обхода фильтров на выходе, а для организации сервера в случает, когда нет белого IP — от темы мы были далеко изначально :)

[Roy]

port 443
proto tcp

и причем здесь вообще GRE?

[timoor]

У хорошего админа icmp прикрыт. Не нужен он пользователям.
А при прикрытом icmp описаный выше софт теряет свою целесообразность.
Так что нарезка «левой резьбы» много времени и не займет =)

З.Ы.: А еще есть провайдеры, которые режут icmp пакеты. И куда с этим pwnat идти в таком случае? =)

[Roy]

От клиентов наружу? Совершенно корректно.

[Roy]

Клиентам все это не нужно.
Фрагментация — дело шлюза.
Port unreachable — его все равно уже мало кто шлет — защита от сканирования портов. Само отвалится по таймауту, ничего страшного.
TTL expired — зачем обычному пользователю traceroute?

[timoor]

Разговор изначально шел про локалки и NAT. Своего провайдера в привел в пример, у него действительно зарезан ICMP.

[Roy]

Тогда аргументируйте.
Требование безопасности — все правильно.

[Roy]

Режем по частоте: клиент пингует один хост — все ходит, начинает пинговать второй — отваливаются оба. :)
Режем по размеру: пытаем установить MTU на маршруте, увеличиваем размер пакета с выключенной фрагментацией — врубаемся в фильтр. :)
А безопасности мы при этих спецэффектах все равно не добьемся.

[Roy]

Мы же в этой ветке оффтопим — фильтрацию в корпоративных сетях обсуждаем? :) Обычный пользователь здесь — это сотрудник.

Про провайдера я уже ниже отписался — админ этого провайдера альтернативно одарен. Ладно бы он свою сеть трейсить запрещал, но интернет-то за что?

[timoor]

Это почему это некорректно? Зачем пользователю в моем офисе нужен ICMP? Вообще, для чего рядовому пользователю нужен ICMP? У меня провайдер считает, что всем его клиентам не нужен ICMP. И я бы не сказал, что при этом есть какие-то сбои в работе сети. Пинги проверить нельзя или трейсом пробить? Ничего страшного, я лично от этого не страдаю =)

[Roy]

А вот для провайдера это неправильно — не его дело, что клиенты шлют, он — труба.

[timoor]

Видимо считает что оберегается от ICMP-флуда… мало ли, мотивы мне неизвестны.

[Roy]

Чтобы тогда весь трафик не запретить? А вдруг там тоже флуд?! :)

[Q2W]

Там детская порнография!

[Roy]

Мы обсуждаем фильтрацию при выходе наружу — а не внутри сети.
И ничего, кстати, особенного не будет — DC вполне можно ставить в DMZ.
О какой версии Windows Server вы говорите?

[vladon]

есть некоторые софтины, в частности клиент-банк сбербанка рф, которые перед соединением пингуют сервер, а при отсутствии пинга отрубаются.

софтины незаменимы, а значит работать со сбербанком, например, будучи клиентом вашего провайдера, не получится.

у нас тоже так один провайдер (ТВТ) страдает фигнёй: icmp режет, 25-й порт режет, белые IP бесплатно не даёт и так далее. как факт, имеется отток клиентов от него к эр-телекому.

[timoor]

ipfw allow udp from 192.168.1.0/24 to 192.168.1.1 53
ipfw allow tcp from 192.168.1.0/24 to 192.168.1.1 53
ipfw deny udp from 192.168.1.0/24 to any 53
ipfw deny tcp from 192.168.1.0/24 to any 53

насколько мне память не изменяет — вот так вот

Вот вроде и накрылся весь днс-туннелинг медным тазиком.
Вы про это?

[timoor]

кажись методом, что описал я DNS-туннелинг не прикроешь… На досуге тоже покурю-подумаю =)

[Roy]

Как-то вам память изменяет, или это фильтр на бридже? Ну не суть.
192.168.1.1 — это ваш DNS. Клиентам разрешено обращаться к нему, а ему видимо разрешено обращаться к DNS'ам в интернете.
Если ваш DNS не только для того, чтобы внутренние зоны держать, он запросы умеет форвардить.
От клиента, в интернет. Профит. Осталось только где-то в интернете этот трафик терминировать.

[timoor]

Фильтр на бридже… Таки я думал, что оно напрямую клиента к внешнему днс пускает. Оказымайнд оно через мой днс-сервер и работает =)
Ничего, время будет — покурю на эту тему =)

[unxed]

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

В остальных же случаях все эти брокировки приносят больше вреда, чем пользы: во-первых, у людей появляется интерес их обойти, во-вторых, они чувствуют себя обиженными и их отношение к компании, в которой они работают, становится соответствующим.

[Stocker]

Бывает по — разному. У меня на работе реальный ай пи и линукс, но дороговориться с админами, чтобы хотя бы ssh открыли нереально. Потому что везде венда и вииирусы, а я с линем белая ворона и система на такие исключения не расчитана.
Жаль что udp у меня весь вообще закрыт в обе стороны, так что такую дырку не проковырять.

[unxed]

Типичный пример решения IT-задачи не-IT методами. Вы ещё про паяльник в жопу нарушителю забыли.

[Roy]

Инициализация сессии элегантная, очень понравилась.
А вот установка сессии наивна донельзя — работать она будет только с чистым NAT, без PAT (ибо требует, чтобы порт на клиенте совпадал с портом на NAT'е) — а где он такой еще вообще остался? Многие NAT'ы мало того, что не гарантируют такого совпадения, так еще и рандомизируют исходящие порты.
Плюс к этому, если упорно долбиться в закрытый порт, то нас еще и секьютири фильтр может заблокировать — совсем ничего не установим.

[AlexeyK]

Интересный топик, «революционный метод, блаблабла, интересное и неожиданное решение, дальше смотрите и ищите сами», вообще уже с катушек съехали :)

[Aux]

баян! Skype панчит так наты с первой версии.

[z123]

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

[Aux]

Я к тому, что это решение не ново и активно используется не первый год.

[unxed]

Это — не то же самое, что в скайпе. Скайп использует клиентов с белыми IP, чтобы соединить тех, кто за NAT. В лучшем случае, клиенты с белыми IP используются только для установки соединения, в худшем — через них ещё и трафик идёт.

А здесь речь о том, что не нужно никакого третьего узла с белым IP, всё и так будет работать (правда, не всегда).

[Aux]

Skype использует кучу штук сразу (:

[z123]

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

[Aux]

Просто это довольно узко-специализированная штука. А обычным людям уж если сильно припрёт, то хамачи более привычен (:

В любом случае я не против софтины как таковой, просто ажиотаж вокруг на хабре нездоровый. Такое впечатление, что люди вчера в интернет попали.

[Roy]

И раньше было и это ни разу не универсальное — глубоко не везде работать будет.

[unxed]

Собрал под винду в cygwin. Пробуйте:
40in.spb.ru/pwnat/pwnat-0.2-beta-cygwin.zip

[unxed]

Внутри локалхоста — работает, хоть и с сообщениями об ошибке.
Ща проверим на реальной паре NAT-NAT.

[unxed]

А вот на реальной паре NAT-NAT ничего не вышло.
Со стороны сервера — NAT провайдера Цифра (Спб), со стороны клиента — Kerio.
Teredo при этом на стороне сервера работает нормально.

Что-то я делаю не так… наверное :)

[unxed]

Есть мнение, что windows не очень-то любит подмену ip адреса отправителя пакета, а тут без этого не обходится. Но надо ещё пободаться :)

[unxed]

Вроде как, есть обход этого ограничения. Надо бы предложить автору идею.

[unxed]

Кто-нибудь, pls, проверьте на XP SP1 (на SP2+ — защита от ip spoofing), заработает или нет?

[mikes]

мы изобрели hamachi 2?

[unxed]

ЕМНИП, хамачи тоже использует третий сервер для установки соединений?

[Dialog]

+1, и работает через vpn

[HammeremmaH]

Тьфу. Я уже думал они Static NAT обманули. А тут такая лажа и не понимание механизмов работы различных (!) NATов.

[Dmitry_G]

Когда мне понадобилось подключиться к офисной машине из дома, я сделал ssh туннелирование. Дома у меня сервер на реальном ip, а в офисе NAT.

На машине за NAT(work) выполняем:
ssh -R 10022:localhost:22 serveruser@server

Ну, а когда Вы будете дома, выполните:
ssh workuser@localhost -p 10022

Понимаю, что может быть не в тему, но может, кому-то поможет.
Спасибо.

[TNK]

logmein aka hamachi?

[Rastler]

Я в свое время написал небольшую программку, эдакий proxy-туннелей на основе ICMP. В ICMP пакеты я упаковывал tcp-трафик. Что-то похожее на это www.cs.uit.no/~daniels/PingTunnel/. Правда скорость не большая, из-за отсутствия надежной доставки icmp-пакетов.

[Kopart]

У кого-нибудь это заработало?
Попробовал unix-NAT-NAT-unix — не хочет работать и главное никакого дебага не выводить про процесс(
Только Listening on TCP(/UDP) 192.168.1.2:8000

[Kopart]

Если был бы — то уже давно бы сделал.
А брать VDS только для это — не бюджетно ((
hamachi, remobo работают вот проверяю еще варианты для прямого тунеля.