Обсуждение статьи тематического каталога: Определение факта использования транслятора адресов (NAT) (nat freebsd)Ссылка на текст статьи: http://www.opennet.me/base/net/nat_detect.txt.html
Для Фри так же не плохо выставить "net.inet.ip.random_id: 1" незнаю точно как но по нему можно вычислить НАТ.
А так же FTP в активном режиме передаёт севреру команду PORT со своим реальным айпишником, если не включать поддержку Active FTP то по логам так же можно будет вычислить НАТ.
>Для Фри так же не плохо выставить "net.inet.ip.random_id: 1" незнаю точно как
>но по нему можно вычислить НАТ.
>А так же FTP в активном режиме передаёт севреру команду PORT со
>своим реальным айпишником, если не включать поддержку Active FTP то по
>логам так же можно будет вычислить НАТ.БОЛЬШОЕ СПАСИБО ЗА ДОПОЛНЕНИЕ!
Как появиться свободное время проверю/протестирую Ваши дополнения и перепешу статью с учетом ваших замечание.
Хм. А что же мешает поставить правила, запрещающие входящие соединения на fake-адреса на внешний интерфейс? Тогда все будет работать и невозможно будет проникнуть во внутреннюю сеть. Это верно для IPF.
Статайка ничего, сам сталкивался с таким, но и это все будет бесполезно, если сдетать так как у меня.
И доступ в сетку некатит, и 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, и то не факт.
Избавиться от этой особенности NAT можно двумя способами:
1 - вый настроить межсетевой экран с запретом входящих соединений
2 - рой внимательно почитать про функциональные возможности демона natd.Честно говоря не понял первый пункт. Протокол TCP есть протокол с подтверждением установки соединения(как Вы сами заметили). И если вы перекрываете входящий трафик, то возникает глупый вопрос, а как вы получите ответ, например от web-сервера из локальной сети? Ведь входящие перекрыты. Вы шлете данные. Ответа нет. И вылетаете по таймауту.
Хотя статья достаточно интересна. Но я ожидал нечто более. Интересно было бы с приведением жизненного примера. Точнее с практикой, как это делалось.
Например. Взялся Etheral, снялись пакеты, смотрим на параметр пакета А и сравниваем с пакетом Б. Делаем выводы. Нет, я сам прекрасно это могу сделать, но статья, насколько я понял, ориентирована на начинающих и им бы не мешало показать на живом примере.
А касательно лога web-сервера - здесь вообще раздолье. Просто взять пару строк и привести пример. Ведь не многие по началу даже знают не то что как выглядит лог-файл апача, но и где он находиться.
Впрочем это я уже зарвался. Ниче так статья. Но все же объясните про входящие соединения. Что-то я Вас не понял.
>Честно говоря не понял первый пункт. Протокол 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, но увы администраторы сети убиваю мою статью «запостиную» в студенческом форуме, аргументируя, что статья учит студентов плохому… (вот такая у нас свобода слова) :(
смотри секцию 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-сервера - здесь вообще раздолье. Просто взять пару строк
>и привести пример. Ведь не многие по началу даже знают не
>то что как выглядит лог-файл апача, но и где он находиться.
>
>Впрочем это я уже зарвался. Ниче так статья. Но все же объясните
>про входящие соединения. Что-то я Вас не понял.
касательно уровня приложений - провайдер не имеет права хоть как-то анализировать ваш трафик (содержимое пакетов), это все равно что прослушивать телефонные переговоры. Если вам предоставили подобные логи - берите их и идите в суд. Они могут знать что вы так делаете, но мараться не будут. Если только с санкции.. Или я неправ???
но не имеет права разглашать и передавать третьим лицам увиденное
и если в договоре чётко прописан запрет на нат/прокси - результат анализа логов является поводом для подачи в суд за нарушение договора
логи не имеют юридической силы
Хорошая статья. Но есть существенное дополнение, а именно дело было так. Прочитал -> решил попробовать, так как на работе своя бука юзается именно через нат.
Тест был следующий
бука(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. большое спасибо автору за статью, полезно было почитать
Замечу ещё что можно, что для запрета входящих конектом модно просто резать всё что не established и related.