форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Тематический каталог: Определение факта использования трансл..."

Сообщение от auto_topic (??) on 09-Дек-04, 23:51

Обсуждение статьи тематического каталога: Определение факта использования транслятора адресов (NAT) (nat freebsd) Ссылка на текст статьи: http://www.opennet.dev/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 (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 (??) 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 (??) on 13-Май-05, 01:12

Замечу ещё что можно, что для запрета входящих конектом модно просто резать всё что не established и related.

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

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