The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Тематический каталог: Определение факта использования трансл..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [ Отслеживать ]

"Тематический каталог: Определение факта использования трансл..."  
Сообщение от auto_topic (??) on 09-Дек-04, 23:51 
Обсуждение статьи тематического каталога: Определение факта использования транслятора адресов (NAT) (nat freebsd)

Ссылка на текст статьи: http://www.opennet.ru/base/net/nat_detect.txt.html

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Определение факта использования транслятора адресов (NAT) (n..."  
Сообщение от a55 (??) on 09-Дек-04, 23:51 
Для Фри так же не плохо выставить "net.inet.ip.random_id: 1" незнаю точно как но по нему можно вычислить НАТ.
А так же FTP в активном режиме передаёт севреру команду PORT со своим реальным айпишником, если не включать поддержку Active FTP то по логам так же можно будет вычислить НАТ.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Определение факта использования транслятора адресов (NAT) (n..."  
Сообщение от Stas_Dragon (??) on 15-Дек-04, 16:29 
>Для Фри так же не плохо выставить "net.inet.ip.random_id: 1" незнаю точно как
>но по нему можно вычислить НАТ.
>А так же FTP в активном режиме передаёт севреру команду PORT со
>своим реальным айпишником, если не включать поддержку Active FTP то по
>логам так же можно будет вычислить НАТ.

БОЛЬШОЕ СПАСИБО ЗА ДОПОЛНЕНИЕ!
Как появиться свободное время проверю/протестирую Ваши дополнения и перепешу статью с учетом ваших замечание.


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Определение факта использования транслятора адресов (NAT) (n..."  
Сообщение от RAM on 16-Дек-04, 12:11 
Хм. А что же мешает поставить правила, запрещающие входящие соединения на fake-адреса на внешний интерфейс? Тогда все будет работать и невозможно будет проникнуть во внутреннюю сеть. Это верно для IPF.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Определение факта использования транслятора адресов (NAT) (n..."  
Сообщение от Игорь (??) on 17-Дек-04, 08:30 
Статайка ничего, сам сталкивался с таким, но и это все будет бесполезно, если сдетать так как у меня.
И доступ в сетку некатит, и ftp/www/dns работает как надо.
В лине все описанные проблемы решаются всего в несколько строк:

iptables -t mangle -A POSTROUTING -p ALL -o ethX -j TTL 255
iptables -t nat -A POSTROUTING -p ALL -o ethX -j MASQUERADE
iptables -A INPUT -p ALL -i ethX -j ACCEPT -m state
--state ESTABLISHED,RELATED
iptables -A INPUT -p TCP -m multiport --dports 21,80,... -i ethX -j ACCEPT -m state
--state NEW,ESTABLISHED
iptables -A INPUT -p ICMP -i ethX -j ACCEPT -m state
--state NEW,ESTABLISHED --icmp-type echo-request
iptables -A INPUT -p ALL -i ethX -j DROP
iptables -A FORWARD -p ALL -i ethX -j ACCEPT -m state
--state ESTABLISHED,RELATED

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Определение факта использования транслятора адресов (NAT) (n..."  
Сообщение от Skif email(ok) on 17-Дек-04, 11:19 
Избавиться от этой особенности NAT можно двумя способами:
    1 - вый настроить межсетевой экран с запретом входящих соединений
    2 - рой внимательно почитать про функциональные возможности демона natd.

Честно говоря не понял первый пункт. Протокол TCP есть протокол  с подтверждением установки соединения(как Вы сами заметили). И если вы перекрываете входящий трафик, то возникает глупый вопрос, а как вы получите ответ, например от web-сервера из локальной сети? Ведь входящие перекрыты. Вы шлете данные. Ответа нет. И вылетаете по таймауту.
Хотя статья достаточно интересна. Но я ожидал нечто более. Интересно было бы с приведением жизненного примера. Точнее с практикой, как это делалось.
Например. Взялся Etheral, снялись пакеты, смотрим на параметр пакета А и сравниваем с пакетом Б. Делаем выводы. Нет, я сам прекрасно это могу сделать, но статья, насколько я понял, ориентирована на начинающих и им бы не мешало показать на живом примере.
А касательно лога web-сервера - здесь вообще раздолье. Просто взять пару строк и привести пример. Ведь не многие по началу даже знают не то что как выглядит лог-файл апача, но и где он находиться.
Впрочем это я уже зарвался. Ниче так статья. Но все же объясните про входящие соединения. Что-то я Вас не понял.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Определение факта использования транслятора адресов (NAT) (n..."  
Сообщение от Stas_Dragon (??) on 18-Дек-04, 18:04 
>Честно говоря не понял первый пункт. Протокол TCP есть протокол  с
>подтверждением установки соединения(как Вы сами заметили). И если вы перекрываете входящий
>трафик, то возникает глупый вопрос, а как вы получите ответ, например
>от web-сервера из локальной сети? Ведь входящие перекрыты. Вы шлете данные.

Если я вас правильно понял то:

Дано: Локальная сеть<--->| xl0| G+NAT |xl1|<------>Интернет
Сеть А скрыта за NAT который установлен на шлюзе имеющем два интерфейса (xl0,xl1).
Задача: разрешить локальной сети А пользоваться всеми сервисами сети Интернет по протоколу TCP, но запретить обращение из сети Интернет к сервисам локальной сети по протоколу TCP.
Опишу только запрет.
Вспомним, как по протоколу TCP устанавливается соединение ( http://www.citforum.ru/nets/semenov/4/44/tcp_443.shtml ):

1)    Comp0 --> ---SYN ---> Copm1
2)    Comp0<-- ACK,SYN <-Comp1
3)    Comp0<--- ---ACK<----Comp1
Если представить, что Comp0 есть локальная сеть (А) то для того чтоб запретить установление соединения по протоколу TCP с Comp0 нужно брандмауэром запретить все пакеты исходящие с xl0 с установленным флагом SYN идущие из сети Интернет.
Как выглядит это в действительности, выше «запостил» Игорь. Прошу обратить внимание на слова --state NEW,ESTABLISHED в конфиге Игоря.

P.S Большое спасибо за отзывы, и замечания.

P.S Еще раз подчеркну, что  написанная мной статья прежде всего есть кусочек теории/мыслей, которые могут помочь найти/спрятать NAT. Просто в той локальной, студенческой сети в которой я жил, несколько студентов (администраторов) запретили использование NAT. Вот я и описал для студентов общие принципы нахождения/прятанья NAT, но увы администраторы сети убиваю мою статью «запостиную» в студенческом форуме, аргументируя, что статья учит студентов плохому… (вот такая у нас свобода слова) :(


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Определение факта использования транслятора адресов (NAT) (n..."  
Сообщение от evgen (??) on 22-Мрт-05, 15:14 
смотри секцию STATEFULL FIREWALL из man ipfw

всякие check-state + keep-state

по поводу опции natd -deny_incoming - можно перед
divert xxxx поставить например pass from any to me 22,25 и все будет работать

>Избавиться от этой особенности NAT можно двумя способами:
>    1 - вый настроить межсетевой экран с запретом
>входящих соединений
>    2 - рой внимательно почитать про функциональные возможности
>демона natd.
>
>Честно говоря не понял первый пункт. Протокол TCP есть протокол  с
>подтверждением установки соединения(как Вы сами заметили). И если вы перекрываете входящий
>трафик, то возникает глупый вопрос, а как вы получите ответ, например
>от web-сервера из локальной сети? Ведь входящие перекрыты. Вы шлете данные.
>Ответа нет. И вылетаете по таймауту.
>Хотя статья достаточно интересна. Но я ожидал нечто более. Интересно было бы
>с приведением жизненного примера. Точнее с практикой, как это делалось.
>Например. Взялся Etheral, снялись пакеты, смотрим на параметр пакета А и сравниваем
>с пакетом Б. Делаем выводы. Нет, я сам прекрасно это могу
>сделать, но статья, насколько я понял, ориентирована на начинающих и им
>бы не мешало показать на живом примере.
>А касательно лога web-сервера - здесь вообще раздолье. Просто взять пару строк
>и привести пример. Ведь не многие по началу даже знают не
>то что как выглядит лог-файл апача, но и где он находиться.
>
>Впрочем это я уже зарвался. Ниче так статья. Но все же объясните
>про входящие соединения. Что-то я Вас не понял.


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Определение факта использования транслятора адресов (NAT) (n..."  
Сообщение от Hawk (??) on 21-Мрт-05, 15:22 
касательно уровня приложений - провайдер не имеет права хоть как-то анализировать ваш трафик (содержимое пакетов), это все равно что прослушивать телефонные переговоры. Если вам предоставили подобные логи - берите их и идите в суд. Они могут знать что вы так делаете, но мараться не будут. Если только с санкции.. Или я неправ???
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "если в договоре написано - имеет"  
Сообщение от Mik (??) on 28-Мрт-05, 15:41 
но не имеет права разглашать и передавать третьим лицам увиденное
и если в договоре чётко прописан запрет на нат/прокси - результат анализа логов является поводом для подачи в суд за нарушение договора
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "если в договоре написано - имеет"  
Сообщение от Alexander (??) on 10-Фев-08, 09:33 
логи не имеют юридической силы
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Определение факта использования транслятора адресов (NAT) (n..."  
Сообщение от Chaos email(??) on 12-Май-05, 22:14 
Хорошая статья. Но есть существенное дополнение, а именно дело было так. Прочитал -> решил попробовать, так как на работе своя бука юзается именно через нат.
Тест был следующий
бука(172.31.5.51)->(NAT)рабочий комп(eth1:172.31.5.53, eth0:192.168.111.195)
Нетрудно видеть что eth0 внешняя сеть, а eth1 внутренняя якобы, бука за натом. Дальше к томуже свичу что и eth0 подключён комп (192.168.111.189) Понятно что в обычных условиях пинг на буку не пойдёт. Прописываем роутинг на 192.168.111.189, указав мой eth0 на рабочей машине как шлюх и воля. пинг идёт. Однако тут и одно но. Вроде бы всё как по статье да только не совсем. А именно. Что-то меня заставило усомнится в том что всё именно так как описано. Запустив банальный iptraf я посмотрел от куда приходят icmp, и что же я вижу? они приходят с 192.168.111.189. Если бы такой расклад был благодаря NAT тоесть если бы это была его фишка то icmp преобровывался и приходил от eth0 моего рабочего компа. Это при том что icmp на 192.168.111.189 приходит именно от eth0 (как и должно быть) а не от буки. Всё это наталкивает на вывод о том что фишка эта не в нате а в шлюзе. Весь сказ. И нат тут не причём получается. Поправте если я ошибся.
P.S. большое спасибо автору за статью, полезно было почитать
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Определение факта использования транслятора адресов (NAT) (n..."  
Сообщение от Chaos email(??) on 13-Май-05, 01:12 
Замечу ещё что можно, что для запрета входящих конектом модно просто резать всё что не established и related.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру