Да, представь себе, я бы начал правила именно так. Разве что icmp бы уделил больше внимания, когда уже всё заработало.
Пойми, нет никакого смысла перегружать сервер бессмысленными проверками (по десять раз проверять, а не tcp ли это протокол?), или держать в памяти правила, до которых никогда не доходит очередь (все эти проверки невалидных флагов после -m state --state INVALID -j DROP просто никогда не будут выполнены).
Ещё раз, не надо изобретать велосипед. Я не считаю себя гуру, но тешу себя надеждой, что хорошо представляю себе работу нетфильтра.
Так вот, с моей колокольни, ваши правила сложно читать, ещё сложнее в них разобраться и тривиально допустить ошибку, которая будет стоить вам работы, если вы не врёте, что это будет связано с интернет банкингом.
Если писать совсем полностью, то правила были бы примерно такие:
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i <ext_IF> -p <proto> -m <proto> --dport <service_port> -m state --state NEW -j ACCEPT
-A INPUT -j LOG --log-prefix "IPTABLES-UNKNOWN "
COMMIT
Все пакеты, не попавшие в одно из предыдущих правил, будут валиться в лог. Предупреждаю, их там будет ДОХРЕНА, если только перед этой машиной не стоит другого шлюза, отсекающего лишний трафик. Пытаться блокировать этот интернет-шум принудительно - бессмысленно, он всё равно уже заблокирован правилом по умолчанию.
Но в академических целях, иногда полезно этот трафик проанализировать. Для анализа лучше всего настроить фильтрацию лога в отдельный файл по префиксу, чтобы не мусорить в syslog.