Iptables

даже если я дропну пакеты в начале цепочки, как минимум в последний accept они попадут

не попадут, они же дропнутся.

Вероятно. Однако если добавить -s <IP> -j DROP и после него сразу следующим -s <IP> -j ACCEPT то трафик не заблокируется. То есть DROP только помечает пакет как отбрасываемый в будущем, но это не предотвращает его попадания в следующие по цепочке правила, где возможно он опять получит ACCEPT метку. А надо отбросить и выбросить его сразу. Потому как если он дойдет до следующих LOG, DROP, ACCEPT hashlimit правил, то система накроется от такого pps. Операция hashlimit слишком ресурсоемкая выходит, нельзя допустить чтобы туда попадали пакеты эти.

Однако если добавить -s <IP> -j DROP и после него сразу следующим -s <IP> -j ACCEPT то трафик не заблокируется.

Откуда ноги растут у этого утверждения? У меня все работает логично — если есть drop-правило выше accept-правил — пакеты отбрасываются, счетчик дропа растет, счетчик акцепта не изменяется.

Ясное дело что когда они Выше, то пакеты будут отброшены. Я же говорю о ситуации, когда drop правила ниже. Мне нужно чтобы в вышестоящий accept(drop) они не попадали совсем - сразу отбрасывались. Т.е. объясняю на пальцах - нижний drop очень простой и легкий для системы, верхний - очень тяжелый и сильно нагружает систему. При высоком pps она умирает. Надо сделать так, чтобы сразу после первого (нижнего) drop пакет отбрасывался тут же и безусловно, ни в какие иные цепочки DROP/LOG/ACCEPT не попадая.

В одном комменте у тебя DROP раньше ACCEPT, в другом уже наоборот. Ты уж разберись.
Далее:

первого (нижнего) drop

тут уже фундаментальная ошибка если речь идет о iptables -L или файле куда сохранен iptables-save и из которого идет восстановление в iptables-restore. Первое правило вносится под меньшим rule number и соответственно пакеты проходя по цепочке чекаются на соотвествие этим правилам (1 > 2 > 3 > N) и если в первом правиле у тебя есть DROP, под условия которого подпадает проходящий пакет он дропается сразу же и безусловно. DROP/LOG/ACCEPT — это таргеты, а не цепочки, по ним никакие пакеты не гуляют (но это уже придирки).

BOOBLIK, Стоп. Вернемся к элементарной базе.

ACCEPT udp  — 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ACCEPT all  — 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT icmp — 0.0.0.0/0 0.0.0.0/0 REJECT all  — 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Сначала запрещаем все, потом разрешаем ICMP, уже установленные соединения и наконец tcp трафик на порт 80. Пакеты проходят снизу вверх. Если бы было наоборот, то получалось бы, что сначала бы разрешили трафик на 80 порт, потом установленные соединения, потом icmp, а потом все это дружно запретили.

Еще раз правила, lorcode все размазал.

ACCEPT     tcp  —  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
ACCEPT     all  —  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     icmp —  0.0.0.0/0            0.0.0.0/0
REJECT     all  —  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

В твоем примере:
1) Применяем политику цепочки
2) Разрешаем tcp/80 с любого source ip
3) Разрешаем установленные и дочерние
4) Разрешаем весь icmp
5) Реджектим с отправкой icmp все, что не подпало под предыдущие условия

Почему тогда не срабатывает: Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 8 480 ACCEPT all  — * * <ip> 0.0.0.0/0 1 60 DROP all  — * * <ip> 0.0.0.0/0

Правило DROP сработало всего 1 раз, пока я еще не успел добавить ACCEPT. Оно идет по вашей логике после ACCEPT, соответственно должно отменить DROP'нуть пакеты, которые были пропущены выше.

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    8   480 ACCEPT     all  —  *      *       <ip>         0.0.0.0/0
    1    60 DROP       all  —  *      *       <ip>         0.0.0.0/0

Это не моя логика, это принципы работы пакетного фильтра в linux.

после ACCEPT, соответственно должно отменить DROP'нуть пакеты, которые были пропущены выше.

Тут у тебя еще одна фундаментальная ошибка. Как только пакет подпадает под условия одного из правил он уходит в назначенный таргет и более не обрабатывается фильтром (т.е. если он уже подпал под ACCEPT в первом правиле, то все иные правила данному пакету побоку, даже если следом будет -p all -j DROP).

Мне потребуется немного времени на осознание того, как предыдущие 5 лет администрирования linux-серверов я мог думать иначе.

Понимаю. Пробежался по созданным тобой топикам про всякие ha-кластеры и апачи и прочие жуткие штуки и немного удивился задаваемым в этом треде вопросам.

Как только пакет подпадает под условия одного из правил он уходит в назначенный таргет и более не обрабатывается фильтром

На всякий случай уточню для ТС, что таргеты бывают терминирующими (ACCEPT, DROP, REJECT) и не терминирующими (LOG, MARK). После вторых пакет продолжает идти по правилам цепочки.