[iptables] Что лучше deny-by-default или accept

Как тебе нравитца и проще так и делай

Обычно проще следовать принципу «все, что не разрешено, то запрещено», т.е. -P DROP для INPUT и FORWARD. Во всяком случае, если хост торчит задницей в недоверенной зоне.

Обычно структура этих цепочек такова:
-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Дальше идут всякие проверки на портсканы, некорректные пакеты, etc
-p tcp -m conntrack --ctstate NEW --tcp-flags ACK,SYN ACK,SYN -j REJECT --reject-with tcp-reset
# Потом разрешения для новых соединений
-p tcp --dport 80 -j ACCEPT
# В конце, опционально, логгирование
-m limit --limit-rate 3/min -j LOG --log-level DEBUG --log-prefix «Dropped: »
# Ну и после этого default drop

Конечно, я упрощаю, но общая идея примерно такая :)

а тебе есть что прикрывать? если нет то accept

мне логичней видится deny-by-default

Благодарю за совет. Мне собственно надо, чтобы только ssh торчал наружу и web-сервер на 20000 порту вот этого. Насчёт портскана, чем это чревато? В том смысле я ни от кого не скрываю какие сервисы у меня торчат наружу :)

есть. подефолту в itc всё торчит наружу :)

Ну, если полагаешь, что ты неуловимый Джо, то защита от портсканов и прочие IDS/IPS тебе действительно не нужны :)

Но ssh я бы на твоем месте все-таки защитил через knockd, особенно если оно на дефолтном порту. Ботнеты, они такие.

Спасибо. Ну auth.log пока ещё не такой раздутый :) Насчёт защиты пока ещё не определился ;)

Кстати, knockd классная вещь! Но в моём случае перебор :)

Кстати, ещё такой вопрос. Ведь по идее политика -A INPUT ACCEPT, в начале которой разрешающие правила, а в конце цепочки -A INPUT -j DROP ничем не отличается от -P INPUT DROP?

В принципе, разницы никакой, но -P INPUT ACCEPT -A INPUT -j DROP смотрится несколько по-индусски, имхо.

// Случаи извращенного хакинга с RETURN и -g вместо -j я не рассматриваю.

Согласен. Я просто анализировал правила на своём домашнем маршрутизаторе D-link 500t, там таким образом сделано -P INPUT ACCEPT, то есть дефолтно, потом разные разрешающие правила и в конце -A INPUT -j DROP

при -P INPUT ACCEPT и -A INPUT -j DROP в конце при iptables -F ssh коннект не отвалится

>при iptables -F ssh коннект не отвалится

Если вынуть вовремя, папой не станешь, да.
Однако современная цивилизация дает нам более удобные средства контрацепции.

Откройте для себя iptables-apply.

И чем же это более удобно? Еще один дополнительный скрипт, зачем к нему привыкать

Ешё небольшой вопросик :) Если у меня -P INPUT DROP и разрешено только ssh и state EST,REL, но на сервере у меня ещё крутятся www,smtp,bind,ftp, базы данных и т.д., то теоретически мой хост уязвим (remote) лишь для брута, openssh уязвимости и ядерной уязвимости (типа ping of death)?

ohshi~
пинг оф дед :D
DDOS-a сейчас стоит опасаться, остальное фигня
брут легко блочится через fail2ban, удаленные уязвимости в openssh? давно не слышал о таких

> пинг оф дед :D

да я утрировал канешно :) имелось ввиду ядерная уязвимость :)

удаленные уязвимости в openssh давно не слышал о таких

я тоже :)

брут легко блочится через fail2ban

да я пока не заморачиваюсь :)

itc:~# grep -i invalid /var/log/auth.log | wc -l

670

а как ддос распознать ^_^

>И чем же это более удобно?

Это удобно тем, что защищает от выстрела себе в пятку. // К.О.

Еще один дополнительный скрипт, зачем к нему привыкать

Кто не хочет учиться, идет работать в грузчики или во власть.
В сисадминство ему подаваться не след.

>Если у меня -P INPUT DROP и разрешено только ssh и state EST,REL, но на сервере у меня ещё крутятся www,smtp,bind,ftp, базы данных и т.д., то теоретически мой хост уязвим (remote) лишь для брута, openssh уязвимости и ядерной уязвимости (типа ping of death)?

В общем, да. Априорно предполагая, что никакой нечисти, устанавливающей бэкконнект, на твоем серваке нет.

Правда, не упомянута еще одна группа методов вскрытия ssh (кроме брутфорса и дыр в openssh) — то, что объединяется широким термином «социальная инженерия», начиная от кейлоггеров на твоей машине и заканчивая терморектальным криптоанализом. Не то, чтобы я уж очень это подчеркиваю, но забывать тоже не надо :)

Что касается DDoS'а, то тут он возможен в двух видах — на ssh-сервер (легко лечится кнокингом или fail2ban) и на забитие канала, т.е. пинги. Во втором случае сам ты сделать ничего не сможешь, придется обращаться к провайдеру.

Кнокинг и/или fail2ban рекомендую настроить уже сейчас, чтобы не париться потом.

Ну и, традиционно, обновляй софт почаще ;)

Спасибо большое за советы! Всё по полочкам разложено :)