Не работают правила Firewall (первые! и выборочно)

[filichev]

В связи с атакой начал настраивать файрволл более тонко и столкнулся с тем, что несколько примитивных правил не работают.

#1 - не работает вообще. log/drop - не важно. Иногда в логах появляется запись, но никак не связанная с моими попытками достучаться до 8081 с другого канала. /с телефона/.

#12 и #13 - прекрасно работает для порта 8088 но абсолютно не работает (пускает) для 8086. Делал отдельное правило для 8086 - тоже самое.

Есть идеи?

входящих каналов два - оба в списке входящих интерфейсов WAN в правиле. Пробовал вообще по всем интерфейсам блокировать - не работают.

Ступор :(

[filichev]

В Raw все работает. Чудеса.

[vqd]

ну конкретно на крине первое правило явно просится в цепочку forward или этот адрес у вас на микротике висит?

[filichev]

Это микротиковский адрес одного из WAN

Было и на форвард и на инпут и без адреса. Не работает и все тут. Просто на скрине уже шаманство тоже заметно.

Но особенно впечатляют 12 и 13 - один порт откидывает, второй - пускает.

[vqd]

Тоесть у вас на данном микротике есть адрес 192.168.88.2 и открыт с этого адреса порт 8081 ?

[filichev]

Да. Микротик за провайдерским NAT, 192.168.88.0 внешняя сетка. Белый IP в мир там через пень/колоду.

[vqd]

Ну т.к. вы на вопрос не ответили то попробую включить телепата и скажу что верхнее правило у вас не будет работать ни на форварде ни на инпуте

[filichev]

Ну не буду испытывать ваши телепатические способности, скажу что я похоже понял причину - при настроенном dstnat (пробросе портов) попытка их закрыть фильтрами не отключая dstnat приводит к странному результату.

Вроде что-то работает, но не все.

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

[Vlad-2]

1) у микротика (у разработчиков) своё видение или своё решение и правила прохождения пакетов
2) когда делаем правила dst - закрывать такой порт как бы не резонно
3) с года два назад сделали табличку RAW, которая позволяет отлавливать те пакеты, которые явно не нужны,
но самое главное, позволяет не попадать этим пакетам в Connection tracker и тем самым не нагружать роутер
4) Также, согласно таблице прохождения пакетов в микротике, dst-nat раньше идёт, чем filter, отсюда следует
как раз то, что обычным правилом прохождения пакета по цепочке dst-nat не закрыть.

Как итог:
а) находим/смотрим наиболее частые сканирование и удары в порты, если порты нам не важны, защищаемся в RAW
б) делаем dst-nat, если можно, делаем его более точным, явным.
в) остальное (жизненное обыденное) режим уже в filter rules

Для коллег:
Писал обыденным языком, пытался просто описать сущность. Неточности есть, прошу не бить

Для всех: (картинка)

[filichev]

Да, спасибо - эту картинку я и нагуглил наконец, после чего пришло понимание.