удалите, а затем переименуйте: те же самые имена файлов имеют различные расширения

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

Если ваш «CSF» — это Брандмауэр ConfigServer, , то он, скорее всего, уже разработан с использованием этого принципа.

Вы сказали, что ваши правила находятся в csfpost.sh, и все они кажутся командами iptables -A, поэтому они добавляют новые правила в конце цепочек правил, созданных CSF. Но если CSF хорошо -спроектирован, он помещает правило «отбрасывать все, что еще не было принято» в конце своих правил. Поскольку правила проверяются по порядку, ваш длинный список ручных правил может фактически вообще не иметь фактического эффекта, поскольку все они добавляются после последнего правила CSF.

Ваш скрипт также включает некоторые правила, которые могут быть действительно вредными, если они будут помещены в начало набора правил. Например:

iptables -A OUTPUT -p udp -j DROP
ip6tables -A OUTPUT -p udp -j DROP

Вы блокируете весь исходящий UDP-трафик. Многоадресная IP-рассылка может использовать только IGMP для управления и UDP для данных. Эти правила означают, что система вообще не может отправлять полезные многоадресные сообщения IPv4 или IPv6. Поскольку IPv6 по существу заменяет широковещательную рассылку многоадресной рассылкой, это фактически нанесет вред IPv6. На стороне IPv4 это заблокирует самые основные DNS-запросы, NTP и DHCP.

iptables -A INPUT -s 127.0.0.0/8 -j DROP

Поскольку это правило не ограничено внешними интерфейсами, оно будет действовать и для интерфейса обратной связи, и фактически отбросит весь трафик на нем. Блокировка петлевого интерфейса приведет к тому, что многие программы не будут работать или будут вести себя очень странно.

iptables -A INPUT -d 224.0.0.0/4 -j DROP
...
iptables -A INPUT -d 239.255.255.0/24 -j DROP

Это также приведет к прекращению всех многоадресных рассылок IPv4. Во втором правиле нет необходимости, так как первое его уже покрывает.

iptables -A INPUT -d 255.255.255.255 -j DROP

Если ваша система действует как DHCP-сервер, это нарушит эту функцию. (DHCP-клиент еще не знает свой IP-адрес при запуске, поэтому он может отправлять широковещательные сообщения только с исходным адресом 0.0.0.0 и целевым адресом 255.255.255.255. Если такие широковещательные сообщения передаются как -из одного сегмента сети в другой маршрутизатором, этот маршрутизатор неправильно настроен.)

iptables -A INPUT -p tcp -m state --state NEW -m limit --limit 2/second --limit-burst 2 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -j DROP

Только 2 новых входящих соединения TCP в секунду с буфером еще на 2 соединения? Один веб-браузер может легко насытить это.

iptables -A INPUT -p tcp --tcp-flags SYN,ECN,CWR -j DROP

ECN — это не один флаг, а метод, включающий несколько новых флагов TCP. Ядро Linux уже поддерживает ECN. Вероятно, он уже имеет встроенные -проверки работоспособности, которые являются более точными, чем то, что вы можете сделать с помощью простых правил iptables.

iptables -A INPUT -f -j DROP

Отбрасывание IP-фрагментов, вероятно, является устаревшим советом, :ядро ​​Linux может и будет автоматически повторно -ассемблировать и -проверять все фрагменты по мере необходимости. Это происходит до того, как пакеты будут обработаны отслеживанием соединения iptables, поэтому вполне вероятно, что это правило никогда не будет соответствовать чему-либо.

В целом, мне кажется, что вы либо собираете различные правила брандмауэра, не полностью понимая, что они означают, либо следуете устаревшим или неполным советам.

Чтобы разработать эффективные правила брандмауэра на уровне отдельных iptablesкоманд, вам действительно нужно знать все типы сетевого трафика, которые система должна принимать для выполнения своей работы, и иметь хотя бы базовое представление об используемых протоколах.. Если вы попытаетесь собрать правила для всех возможных плохих вещей, не понимая их отношения к «хорошим» типам трафика, вы всегда потерпите неудачу. Если вы пойдете по этому пути, вы научитесь этому на собственном горьком опыте -считайте себя предупрежденными.