ferm не пробовал. Доверия к разного рода "автоматизировалкам" скриптов нет. -P OUTPUT DROP для сброса установленных подключений, это же очевидно. Говоря точнее, поумолчанию мы сбрасываем все пакеты по цепочками INPUT, OUTPUT и FORWARD. Или ты предпочитаешь, чтобы бот, который коим-то образом поселился на твоем роутере, продолжал спамить во вне? =)
Просто через ferm некоторые вещи написать гораздо быстрее. Но это дело вкуса.
-P OUTPUT DROP - устанавливает политику обработки трафика, не попавшего ни под одно правило.
Т.е. трактовать это надо так: Отбросить весь трафик, который явно не разрешен.
Т.е. мы получаем то, что сам маршрутизатор никуда ходить не может.
Хотя на мой взгляд при -P INPUT DROP запрещать еще и исходящий - это уже избыточно.
Соединения с состоянием ESTABLISHED рулит немного другая штука. Conntrack зовется.
P.S. У каждого свой уровень паранойи. :)
Т.е. мы получаем то, что сам маршрутизатор никуда ходить не может.
Да, именно этого мы и добиваемся. У нормально параноящего админа политика по умолчанию: запрещено все то, что явно не разрешено.
Даже если сбрасывать OUTPUT - избыточно, то я предпочитаю тезис "лучше перебдить, чем недобдить".
Про conntrack знаю, но у меня не было желания расписывать подробный мануал, иначе расписывать пришлось бы все ну ооочень подробно. Как я писал в самом стартмесседже - это всего лишь шпаргалка, а не учебник.
чем проще?
в чем бесчеловечность bash-скриптинга?
Как написал в комментариях к статье про файршор на швабре: "недостаток всех таких тулзов (включая shorewall) в том, что когда возникает необходимость добавить «нестандартное» правило, котрое слишком заковыристо для скрипта —
ВСЕ правила файрвола приходится переписывать вручную, с нуля."
Без понимания самой сути фильтрации пакетов все эти свистелки и пердлелки для иптабли - простая шелуха. Если на домашнем роутере на пару ноутбуков и телефон интернет раздавать - да, сгодится. А в ентерпрайзе всему этому не место.
А кто говорил о бесчеловечности шелла?
firehol уже готовый велосипед, впрочем как и толпа других. И у него есть возможность запуска с отредактированным конфигом с подтверждением. Тоесть вносим изменения в правил в его конфиг, рестартуем с параметром try - и потом после того как увидели строку приглашения - пишем в ней commit. Если не видим - значит что-то настроили не так - и сессия была сброшена - и через шелл на удаленном сервере работать нельзя. Правила через 30 сек (время наввод строки подтверждения, которой он не дождался) - фаервол перезапускается со СТАРЫМ конфигом. А мы смотрим где наш "ляп" был. При настройке на удаленных серверах бывает актуальным...
Впрочем чем юниксы и хороши - любую задачу можно тысячей способов сделать. Кому что нравится. Я просто поделися своей мыслю по этому поводу (на серверах принципиально никаких вэб-интерфейсов не держу, а многие "нативные" конфиги и синтаксис - ногу сломиш.)
Все на-любителя.
Кто-то моется мылом, а кто-то гель для душа предпочитает. И каждый прав :) Не прав тот - кто не моется вообще ;) впрочем тоже вопрос спорный
Для удаленных роутеров нужны прямые руки, а не велосипеды =)
В прочем, доводилось мне поднимать за 2000 километров роутеры по телефону, когда на том конце была какая-нибудь девочка, которая умела внимательно слушать, что ей говорят, и мастерски пользоваться клавиатурой =)
Прописываем путь до него в любой другой скрипт, выполняемый при запуске системы.
Обьясните нубу, а разве обязательно каждый раз при запуске системы выполнять эти правила? Разве нет места, куда можно прописать правила и они просто будут работать без всяких автозагрузок?
в любой операционной системе ничего просто так не запускается. Если что-то запустилось и работает, значит оно где-то для этого прописано. В данном случае эти правила прописываются в скрипте, который привязывается к какому-нибудь запускаемому при старте системы конфигу или скрипту.
Спасибо за статью, все по полочкам разложено. Если можно, два вопроса:
1. А как быть, если нужно пробросить порт в локалку? например, веб-сервер в локалке за роутером.
2. Если нужно обратиться к этому веб-серваку из локальной сети используя внешний IP ?
1) допустим, внешний IP у нас x.x.x.x, а внутренний, где веб-сервер - у.у.у.у, тогда проброс выглядит так: iptables -t nat -A PREROUTING -p TCP -d х.х.х.х --dport 80 -j DNAT --to-destination у.у.у.у:80
2) чтобы изнутри локалки обратиться к внутреннему веб-серверу, нужно обращаться на внешний IP-адрес, команда из п.1 перенаправит все внутрь.
Комментарии (16)
cкрипт бухгалтерский в клиент-банки не "взлетит"!)
ошибочка допущена. описочка, вернее;)
Хех, и не только в нем =) Что нашел - пофиксил.
А не пробовал ferm?
P.S. Не особо понятно для чего -P OUTPUT DROP ?
ferm не пробовал. Доверия к разного рода "автоматизировалкам" скриптов нет.
-P OUTPUT DROP для сброса установленных подключений, это же очевидно. Говоря точнее, поумолчанию мы сбрасываем все пакеты по цепочками INPUT, OUTPUT и FORWARD. Или ты предпочитаешь, чтобы бот, который коим-то образом поселился на твоем роутере, продолжал спамить во вне? =)
Просто через ferm некоторые вещи написать гораздо быстрее. Но это дело вкуса.
-P OUTPUT DROP - устанавливает политику обработки трафика, не попавшего ни под одно правило.
Т.е. трактовать это надо так: Отбросить весь трафик, который явно не разрешен.
Т.е. мы получаем то, что сам маршрутизатор никуда ходить не может.
Хотя на мой взгляд при -P INPUT DROP запрещать еще и исходящий - это уже избыточно.
Соединения с состоянием ESTABLISHED рулит немного другая штука. Conntrack зовется.
P.S. У каждого свой уровень паранойи. :)
Да, именно этого мы и добиваемся. У нормально параноящего админа политика по умолчанию: запрещено все то, что явно не разрешено.
Даже если сбрасывать OUTPUT - избыточно, то я предпочитаю тезис "лучше перебдить, чем недобдить".
Про conntrack знаю, но у меня не было желания расписывать подробный мануал, иначе расписывать пришлось бы все ну ооочень подробно. Как я писал в самом стартмесседже - это всего лишь шпаргалка, а не учебник.
shorewall ?
нужен ли в энтерпрайзе весь этот костыллинг и улучшайзинг? Лично мое мнение - как корове седло. Хотя, должно быть, кому-то нравится.
Не проще-ли какой-нить firehol пользовать для настройки правил?
Текстовый конфиг, человеческий синтаксис...
чем проще?
в чем бесчеловечность bash-скриптинга?
Как написал в комментариях к статье про файршор на швабре:
"недостаток всех таких тулзов (включая shorewall) в том, что когда возникает необходимость добавить «нестандартное» правило, котрое слишком заковыристо для скрипта —
ВСЕ правила файрвола приходится переписывать вручную, с нуля."
Без понимания самой сути фильтрации пакетов все эти свистелки и пердлелки для иптабли - простая шелуха. Если на домашнем роутере на пару ноутбуков и телефон интернет раздавать - да, сгодится. А в ентерпрайзе всему этому не место.
А кто говорил о бесчеловечности шелла?
firehol уже готовый велосипед, впрочем как и толпа других. И у него есть возможность запуска с отредактированным конфигом с подтверждением. Тоесть вносим изменения в правил в его конфиг, рестартуем с параметром try - и потом после того как увидели строку приглашения - пишем в ней commit. Если не видим - значит что-то настроили не так - и сессия была сброшена - и через шелл на удаленном сервере работать нельзя. Правила через 30 сек (время наввод строки подтверждения, которой он не дождался) - фаервол перезапускается со СТАРЫМ конфигом. А мы смотрим где наш "ляп" был. При настройке на удаленных серверах бывает актуальным...
Впрочем чем юниксы и хороши - любую задачу можно тысячей способов сделать. Кому что нравится. Я просто поделися своей мыслю по этому поводу (на серверах принципиально никаких вэб-интерфейсов не держу, а многие "нативные" конфиги и синтаксис - ногу сломиш.)
Все на-любителя.
Кто-то моется мылом, а кто-то гель для душа предпочитает. И каждый прав :) Не прав тот - кто не моется вообще ;) впрочем тоже вопрос спорный
Для удаленных роутеров нужны прямые руки, а не велосипеды =)
В прочем, доводилось мне поднимать за 2000 километров роутеры по телефону, когда на том конце была какая-нибудь девочка, которая умела внимательно слушать, что ей говорят, и мастерски пользоваться клавиатурой =)
Обьясните нубу, а разве обязательно каждый раз при запуске системы выполнять эти правила? Разве нет места, куда можно прописать правила и они просто будут работать без всяких автозагрузок?
в любой операционной системе ничего просто так не запускается. Если что-то запустилось и работает, значит оно где-то для этого прописано. В данном случае эти правила прописываются в скрипте, который привязывается к какому-нибудь запускаемому при старте системы конфигу или скрипту.
Спасибо за статью, все по полочкам разложено. Если можно, два вопроса:
1. А как быть, если нужно пробросить порт в локалку? например, веб-сервер в локалке за роутером.
2. Если нужно обратиться к этому веб-серваку из локальной сети используя внешний IP ?
1) допустим, внешний IP у нас x.x.x.x, а внутренний, где веб-сервер - у.у.у.у, тогда проброс выглядит так:
iptables -t nat -A PREROUTING -p TCP -d х.х.х.х --dport 80 -j DNAT --to-destination у.у.у.у:80
2) чтобы изнутри локалки обратиться к внутреннему веб-серверу, нужно обращаться на внешний IP-адрес, команда из п.1 перенаправит все внутрь.
Отправить комментарий