Поднятие прокси на Lunix

[Rezor666]

Lunix -http://en.wikipedia.org/wiki/LUnix

[exo]

Rezor666, так не честно...

barasin, автор, исправьте заголовок темы.

[Rezor666]

exo, :tongue:
Буду ждать статью под LUnix а то может я и не прав :)

[exo]

Rezor666, не дождётесь. я умею признавать свои ошибки. Прошу меня извинить )

[Rezor666]

exo, да лан :) Зато Вон какую статью написал AMDBulldozer :)

[AMDBulldozer]

Приношу извинения, в тексте допущено несколько опечаток (быстро печатал и не вычитал перед отправкой - слишком уж он длинный и нудный получился).
Основная из них, в слове "MASQUERADE" (не в том, которое в начале текста, а в том, которое используется в качестве цели команды iptables) пропущена буква "E".

Примечание: Прописные буквы используются не для выделения текста. Это требование синтаксиса команды iptables.

[exo]

Да это полезно будет. Только это для Linux, вряд ли для Lunix подойдёт. ;)
Для начала, не будем указывать в сценарии ни явных имен программ, ни наименований интерфейсов.
Заменим их на переменные, которые установим в самом начале сценария:
IPTABLES=/sbin/iptables
IF_LAN=eth0
IF_INT=eth1 »
что за сценарий? это какой-то файл, куда надо это всё записать, или команды дать?

[AMDBulldozer]

что за сценарий? это какой-то файл, куда надо это всё записать, или команды дать? »

Сначала позволю себе отметить банальный факт (не для Вас, конечно, а для автора темы и других уважаемых участников форума не имеющих достаточного опыта работы в Linux): в этой операционной системе функции трансляции адресов и межсетевого экрана настраиваются одной и той же утилитой - iptables.
Естественно, фактически эти функции выполняются модулями ядра, которые неплохо было бы либо загрузить, либо встроить непосредственно в ядро. Поэтому может получиться так, что для исполнения указанных ранее команд понадобится одна или несколько команд "modprobe". Но это отдельный аспект вопроса и в данной теме я его не касаюсь.

Понятно, что для настройки межсетевого экрана должен быть создан достаточно сложный набор команд.
Который обеспечивал бы защиту от проникновения пакетов адресованных компьютерам локальной сети в сеть провайдера.
И наоборот, защиту от подмены адресов (spoofing) - экран не должен пропускать через внешний интерфейс пакеты с адресами локальной сети.
Должны быть закрыты для доступа извне все привилегированные порты и порты известные как используемые вредоносным ПО. Должен быть закрыт доступ наружу с тех же самых портов.
Блокирован входящий icmp echo request. Блокирован весь исходящий icmp трафик кроме icmp echo request.

$IPTABLES -A FORWARD -i $IF_INT -p icmp --icmp-type echo-request -j DROP
$IPTABLES -A FORWARD -o $IF_INT -p icmp ! --icmp-type echo-request -j DROP

(примечание - восклицательный знак в данном случае не нуждается в экранировании)

Ну и т.д. - запрещены широковещательные сообщения, блокирован диапазон ip из RFC 3927 (т.н. "locallink"), в явном виде запрещена попытка установления новых соединений извне и прочая, и прочая... ("и прочая" является устойчивым выражением, употребляемым вместо "и прочее")

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

К примеру, сначала мы пишем правило "пробрасывающее" входящие на определенные порты пакеты на внутренние серверы сети (с использованием цели -j DNAT), потом регистрируем и запрещаем все попытки установить новые соединения

$IPTABLES -A INPUT -i $IF_INT -m state --state NEW -j LOG
$IPTABLES -A INPUT -i $IF_INT -m state --state NEW -j DROP
$IPTABLES -A FORWARD -i $IF_INT -m state --state NEW -j DROP

а потом явно разрешаем входящие пакеты только относящиеся к уже установленным соединениям:

$IPTABLES -A FORWARD -i $IF_INT -o $IF_LAN -m state --state ESTABLISED,RELATED -j ACCEPT

Сразу видно, что в наборе правил есть явная избыточность. По крайней мере половина из них лишние. (запрет на установление новых соединений - это всего лишь иначе сформулированное разрешение на прохождение пакетов по уже установленным соединениям).
А некоторые содержат условия, которые вообще никогда не будут удовлетворены (если соединение новое, каким образом пакет попадет в цепочку FORWARD?).

Зачем нужны "лишние" команды?
Да по очень простой причине! Это не более, чем защита от дурака (ну, или от ошибок, если вам так больше нравится).
Когда вы пишете с нуля набор правил для межсетевого экрана, очень вероятно, что первым делом там понаделают кучу ошибок и сеть вообще не сможет нормально работать (забыли разрешить получать ответы с DNS-серверов? Какая досада... Придется пользователям ip вручную вбивать).
Вы заглядываете в /etc/services, находите там для сервиса "domain" порт 53 c протоколами tcp и udp и начинаете править свой сценарий, добавляя в него что-то вроде

$IPTABLES -A INPUT -p tcp --source-port 53 -j ACCEPT
$IPTABLES -A INPUT -p udp --source-port 53 -j ACCEPT

Естественно, вышеприведенные правила являются ошибочными!!! Ни в коем случае не записывайте их в таком виде.
Почему? Да потому, что любой злоумышленник, который использует порт 53 в качестве исходящего порта прошел бы через Вашу защиту и смог бы, к примеру, соединиться с запущенным на шлюзе HTTP-сервером.
Одна ошибка и в защите появляется дырка? К счастью, нет. Ведь Вы подстраховались, запретив новые соединения, тем самым "ненужным" правилом.
Злоумышленник не сможет воспользоваться Вашим любезным разрешением принимать все соединения исходящие с 53-го порта, потому что еще раньше Вы запретили вообще все новые соединения.

Рекомендация: для отбрасываемых исходящих пакетов мы используем цель REJECT, в то время как для входящих -j DROP.
Причина проста. Наши собственные пользователи должны иметь возможность сразу узнать, что сайты "одноклассники" и "в контакте" для них закрыты. А сетевой сканер злоумышленника пусть дожидается окончания таймаута.

[exo]

Зачем нужны "лишние" команды? »
значит это команды, а я думал их нужно в файл писать, например rc.local ну или свой firewall.local и помещать в /etc/init.d/...

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

[AMDBulldozer]

значит это команды, а я думал их нужно в файл писать »

Да, именно сохранять в файле.
Но ведь в rc.local Вы тоже сохраняете команды.
Правда в rc.local Вы сохраняете их с другой целью - чтобы они исполнялись каждый раз при запуске.
Исполнять файл с правилами межсетевого экрана (и NAT) каждый раз не требуется.
Рассматривайте этот файл как исходный текст программы (простите мне такую грубую аналогию). Их один раз "транслируют" и записывают командой iptables-save в файл, который будет считываться при каждом запуске системы.
А исходный файл с набором команд iptables Вам нужен для того, чтобы можно было его править, устраняя ошибки и добавляя новые правила по мере необходимости.
Поскольку это именно "исходный текст" он может иметь любое имя и храниться в любой директории. Всё равно операционной системой он никак не используется.

[exo]

Да, именно сохранять в файле. »
вот этого я от вас и добиваюсь - в какой файл? конкретные примеры? Этого у вас не указано.
Не все знаю, как делать автозагрузку в Linux.
А то получается как в анекдоте:
Лысый программист неделю сидит в ванной и перечитывает инструкцию к шампуню: на мокрые волосы нанесите шампунь.
iptables-save »
это конечно хорошо, но не все этим пользуются. и тем более знают как оно работает.

[AMDBulldozer]

вот этого я от вас и добиваюсь - в какой файл? конкретные примеры? Этого у вас не указано. »

Может быть Вы не обратили внимания, но я уже два раза отвечал на этот вопрос. Вы можете сохранить набор команд в файле с любым именем в любой директории.
Он, в любом случае, не будет использоваться операционной системой. Вы делаете его исполняемым (chmod a+x) и один раз запускаете.
После этого Вы сохраняете установленные Вами правила межсетевого экрана командой iptables-save. Эта команда выводит результат работы на stdout, поэтому для сохранения в файле его надо перенаправить.

Еще раз хочу повторить, что, к сожалению, в каждом дистрибутиве Linux способ загрузки полученного файла при старте системы отличается. Пример для Debian я дал.
В других дистрибутивах используются другие имена файлов и директории. К примеру, "iptables-save > /etc/sysconfig/iptables" (red hat/fedora/centos). В Mandriva может использоваться тот же каталог, но там настройка брандмауэра осуществляется утилитой shorewall. Проще всего сохранить усановленный набор правил в Mandriva командой service iptables save (для Debian та же самая команда будет выглядеть как "service iptables-persistent save").
Хуже всего, как обычно, обстоит дело в Ubuntu. Там пользователю предлагают пользоваться какой-то кривой надстройкой текстовой (ufw) или графической (gufw), которая доступна и в других дистрибутивах, хотя никому на фиг не нужна.
Сохраняйте свои правила командой "iptables-save > /etc/iptables.rules" (это официальное наименование файла из Ubuntu'вской документации), а потом запихивайте куда-нибудь, хоть в тот же rc.local, команду "iptables-restore < /etc/iptable.rules".
Какой-либо предустановленный сервис для восстановления настроек в Ubuntu либо отсутствует, либо я просто о нем не знаю.

P.S. Последний совет (с добавлением строки в rc.local) пригоден для абсолютно любого дистрибутива, если лень разбираться с его встроенным сервисом.

Автоматическая установка в 1 содержимого файла ip_forward при запуске системы может осуществляться правкой файла /etc/sysctl.conf, хотя команда echo в rc.local тоже нормальный вариант.

[exo]

Вы можете сохранить набор команд в файле с любым именем в любой директории. »
не, я так не играю. должна быть конкретика.
А любой файл в любом месте это как - нажмите Any key... сидишь и думаешь - где же Any Key ?!
Документация должна быть понятна всем, особенно новичкам.

[AMDBulldozer]

не, я так не играю. должна быть конкретика. »

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

[exo]

где его хранить »
разве в Linux нет рекомендаций где располагать конфигурационные файлы?

[AMDBulldozer]

разве в Linux нет рекомендаций где располагать конфигурационные файлы? »

В том-то и дело, что это не файл конфигурации. "Файл конфигурации" из него получится после сохранения командой iptables-save. Для сохраненного таким образом файла действительно существуют стандартные имена и директории.
К сожалению, они разные для разных дистрибутивов. Варианты я привел выше.
А файл сценария, с помощью которого создается файл с установками межсетевого экрана, как я уже неоднократно писал, не используется операционной системой.
Если у Вас есть аппаратный маршрутизатор, то большинство из них позволяет создать резервную копию его конфигурации.
Естественно, никаких рекомендаций о месте хранения резервной копии не существует.
То же самое касается и исходного файла с командами iptables. Он служит единственной цели - при необходимости создать заново файл, который будет загружать iptables-restore. В этом он ничем не отличается от архивной копии. Я его храню в директории /etc/iptables. Но это абсолютно произвольное место. Можно хранить в /usr/local/iptables, /usr/share/iptables, /usr/local/share/iptables и /root/porn/.
(исполнять его всё равно надо под root'ом).
Выбирайте любой каталог, который Вам нравится.

[exo]

Выбирайте любой каталог, который Вам нравится. »
/var/www/my_domain/ ok?

[zai]

Вот (http://forum.ubuntu.ru/index.php?topic=107492.0), неплохая инструкция

[exo]

iptables-save >/etc/iptables.conf
намного понятнее.

[El Scorpio]

В средних/мелких конторках никогда не ясно что понадобится завтра. Сегодня только NAT, а завтра уже прокси (фильтровать где лазить и что качать можно, а что - нет). В этом случае Linux гибче. »
Если нет серьёзных знаний по работе в консоли, можно использовать web-интерфейс.
Ставим Linux Debian, на него ставим Webmin (4 команды из консоли), а из него в графическом режиме ставим/настраиваем всё остальное.