https://opennet.dev/openforum/vsluhforumID3/4759.html Обсуждение статьи тематического каталога: Определение факта использования транслятора адресов (NAT) (nat freebsd)<br><br>Ссылка на текст статьи: http://www.opennet.ru/base/net/nat_detect.txt.html<br> https://opennet.dev/openforum/vsluhforumID3/4759.html#12 Sun, 10 Feb 2008 06:33:37 GMT логи не имеют юридической силы<br> https://opennet.dev/openforum/vsluhforumID3/4759.html#11 Thu, 12 May 2005 21:12:40 GMT Замечу ещё что можно, что для запрета входящих конектом модно просто резать всё что не established и related. https://opennet.dev/openforum/vsluhforumID3/4759.html#10 Thu, 12 May 2005 18:14:33 GMT Хорошая статья. Но есть существенное дополнение, а именно дело было так. Прочитал -&gt; решил попробовать, так как на работе своя бука юзается именно через нат.<br>Тест был следующий<br>бука(172.31.5.51)-&gt;(NAT)рабочий комп(eth1:172.31.5.53, eth0:192.168.111.195)<br>Нетрудно видеть что 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 (ка https://opennet.dev/openforum/vsluhforumID3/4759.html#9 Mon, 28 Mar 2005 11:41:51 GMT но не имеет права разглашать и передавать третьим лицам увиденное<br>и если в договоре чётко прописан запрет на нат/прокси - результат анализа логов является поводом для подачи в суд за нарушение договора https://opennet.dev/openforum/vsluhforumID3/4759.html#8 Tue, 22 Mar 2005 12:14:54 GMT смотри секцию STATEFULL FIREWALL из man ipfw<br><br>всякие check-state + keep-state<br><br>по поводу опции natd -deny_incoming - можно перед <br>divert xxxx поставить например pass from any to me 22,25 и все будет работать<br><br><br><br>&gt;Избавиться от этой особенности NAT можно двумя способами: <br>&gt; 1 - вый настроить межсетевой экран с запретом <br>&gt;входящих соединений <br>&gt; 2 - рой внимательно почитать про функциональные возможности <br>&gt;демона natd. <br>&gt;<br>&gt;Честно говоря не понял первый пункт. Протокол TCP есть протокол с <br>&gt;подтверждением установки соединения(как Вы сами заметили). И если вы перекрываете входящий <br>&gt;трафик, то возникает глупый вопрос, а как вы получите ответ, например <br>&gt;от web-сервера из локальной сети? Ведь входящие перекрыты. Вы шлете данные. <br>&gt;Ответа нет. И вылетаете по таймауту. <br>&gt;Хотя статья достаточно интересна. Но я ожидал нечто более. Интересно было бы <br>&gt;с приведением жизненного примера. Точнее с практикой, как это делалось. <br>&gt;Например. Взялся Etheral, снялись пакеты, смотрим на параметр пакета https://opennet.dev/openforum/vsluhforumID3/4759.html#7 Mon, 21 Mar 2005 12:22:47 GMT касательно уровня приложений - провайдер не имеет права хоть как-то анализировать ваш трафик (содержимое пакетов), это все равно что прослушивать телефонные переговоры. Если вам предоставили подобные логи - берите их и идите в суд. Они могут знать что вы так делаете, но мараться не будут. Если только с санкции.. Или я неправ??? https://opennet.dev/openforum/vsluhforumID3/4759.html#6 Sat, 18 Dec 2004 15:04:30 GMT &gt;Честно говоря не понял первый пункт. Протокол TCP есть протокол с <br>&gt;подтверждением установки соединения(как Вы сами заметили). И если вы перекрываете входящий <br>&gt;трафик, то возникает глупый вопрос, а как вы получите ответ, например <br>&gt;от web-сервера из локальной сети? Ведь входящие перекрыты. Вы шлете данные. <br><br>Если я вас правильно понял то:<br><br>Дано: Локальная сеть&lt;---&gt;&#124; xl0&#124; G+NAT &#124;xl1&#124;&lt;------&gt;Интернет <br>Сеть А скрыта за NAT который установлен на шлюзе имеющем два интерфейса (xl0,xl1).<br>Задача: разрешить локальной сети А пользоваться всеми сервисами сети Интернет по протоколу TCP, но запретить обращение из сети Интернет к сервисам локальной сети по протоколу TCP. <br>Опишу только запрет.<br>Вспомним, как по протоколу TCP устанавливается соединение ( http://www.citforum.ru/nets/semenov/4/44/tcp_443.shtml ):<br><br>1)Comp0 --&gt; ---SYN ---&gt; Copm1<br>2)Comp0&lt;-- ACK,SYN &lt;-Comp1<br>3)Comp0&lt;--- ---ACK&lt;----Comp1<br>Если представить, что Comp0 есть локальная сеть (А) то для того чтоб запретить установлен https://opennet.dev/openforum/vsluhforumID3/4759.html#5 Fri, 17 Dec 2004 08:19:30 GMT Избавиться от этой особенности NAT можно двумя способами:<br> 1 - вый настроить межсетевой экран с запретом входящих соединений <br> 2 - рой внимательно почитать про функциональные возможности демона natd.<br><br>Честно говоря не понял первый пункт. Протокол TCP есть протокол с подтверждением установки соединения(как Вы сами заметили). И если вы перекрываете входящий трафик, то возникает глупый вопрос, а как вы получите ответ, например от web-сервера из локальной сети? Ведь входящие перекрыты. Вы шлете данные. Ответа нет. И вылетаете по таймауту.<br>Хотя статья достаточно интересна. Но я ожидал нечто более. Интересно было бы с приведением жизненного примера. Точнее с практикой, как это делалось.<br>Например. Взялся Etheral, снялись пакеты, смотрим на параметр пакета А и сравниваем с пакетом Б. Делаем выводы. Нет, я сам прекрасно это могу сделать, но статья, насколько я понял, ориентирована на начинающих и им бы не мешало показать на живом примере.<br>А касательно лога web-сервера - здесь вообще раздолье. Просто взят https://opennet.dev/openforum/vsluhforumID3/4759.html#4 Fri, 17 Dec 2004 05:30:45 GMT Статайка ничего, сам сталкивался с таким, но и это все будет бесполезно, если сдетать так как у меня.<br>И доступ в сетку некатит, и ftp/www/dns работает как надо.<br>В лине все описанные проблемы решаются всего в несколько строк:<br><br>iptables -t mangle -A POSTROUTING -p ALL -o ethX -j TTL 255<br>iptables -t nat -A POSTROUTING -p ALL -o ethX -j MASQUERADE<br>iptables -A INPUT -p ALL -i ethX -j ACCEPT -m state <br>--state ESTABLISHED,RELATED<br>iptables -A INPUT -p TCP -m multiport --dports 21,80,... -i ethX -j ACCEPT -m state <br>--state NEW,ESTABLISHED<br>iptables -A INPUT -p ICMP -i ethX -j ACCEPT -m state <br>--state NEW,ESTABLISHED --icmp-type echo-request<br>iptables -A INPUT -p ALL -i ethX -j DROP<br>iptables -A FORWARD -p ALL -i ethX -j ACCEPT -m state <br>--state ESTABLISHED,RELATED<br><br>Отличить можно будет только другими извратными методами типа ковыряния в слепках длины ICMP, и то не факт.<br>