Antiscan - выявление и блокировка подозрительных IP

[odin2]

концепция фильтрации :
1) пропустить все УСТАНОВЛЕННЫЕ / ИЗВЕСТНЫЕ (из белого списка) соединения (99% трафика)

2) отфильтровать НОВЫЕ соединения (1% трафика)

2.1) аномальные (обнаружение сканирования ....) (0.9% трафика)

2.2) нормальные (желающие подключится к открытым портам) (0.1% трафика)
 

главное чтоб по выше стояло что часто срабатывает, а потом по мере уменьшения
чтоб было минимум холостых срабатываний

при малой нагрузке холостые срабатывания могут быть несущественны
но при больших могут стать заметными
но тут важнее ИЗВЕСТНЫЕ (из белого списка) чтоб "не выстрелить в ногу"
у вас есть белый список, все ли его заполняют ?
входят ли туда адреса от _NDM_ACL_IN_EXCEPTIONS ?

Изменено 15 часов назад пользователем odin2

[MDP]

по логике самым первым правилом должно быть

RELATED,ESTABLISHED

Далее уже наверное не так и важно в каком порядке.?

Только нюанс, что установленное соединение может поддерживаться продолжительное время. И запрещающие правила нижестоящие никак не отработают.

Короче я бы не трогал механизм, который сейчас есть.

Изменено 14 часов назад пользователем MDP

[odin2]

59 минут назад, MDP сказал:

по логике самым первым правилом должно быть

RELATED,ESTABLISHED

верно

59 минут назад, MDP сказал:

Далее уже наверное не так и важно в каком порядке.?

важно по прежнему
чтоб трафик обратной петли и локальной сети не фильтровать

 

59 минут назад, MDP сказал:

Только нюанс, что установленное соединение может поддерживаться продолжительное время. И запрещающие правила нижестоящие никак не отработают.

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

всё ради того чтоб не "выстрелить себе в ногу" - не блокировать отфильтрованные соединения

 

представьте ситуацию :
есть поликлиника (публичное заведение)

туда ходят как сотрудники по пропускам так и посетители (посторонние) без пропусков

человек с пропуском идёт по цепочке RELATED,ESTABLISHED

новые посетители без пропуска, первый раз - ANTISCAN

повторные посетители с талончиком на нужного врача идёт по цепочке RELATED,ESTABLISHED

Изменено 13 часов назад пользователем odin2

[MDP]

6 минут назад, odin2 сказал:

верно

важно по прежнему
чтоб трафик обратной петли и локальной сети не фильтровать

 

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

всё ради того чтоб не "выстрелить себе в ногу" - не блокировать отфильтрованные соединения

Принцип у антискана какой?  (я могу ошибаться, поправьте)

потенциальный гад ломится по 80 порту допустим...устанавливает соединение (не важно, что авторизации нету)...оно уже становится с флагом установленное.

 Как дальше то его отсекать? ...он так может долго ещё сессию держать и продолжать плодить новые сессии?

Изменено 13 часов назад пользователем MDP

[MDP]

9 минут назад, odin2 сказал:

важно по прежнему
чтоб трафик обратной петли и локальной сети не фильтровать

Разве это не относится к конкретному выбранному интерфейсу с направлением in  (ppp0 и т.п.)

Изменено 12 часов назад пользователем MDP

[odin2]

3 минуты назад, MDP сказал:

потенциальный гад ломится по 80 порту допустим...устанавливает соединение (не важно, что авторизации нету)...оно уже становится с флагом установленное.

 Как дальше то его отсекать? ...он так может долго ещё сессию держать и продолжать плодить новые сессии?

изучаем цепочки NDM , путь прохождения пакета до открытых портов 80 443 :

-A INPUT -j _NDM_INPUT

-A _NDM_INPUT -i eth3 -m set --match-set _NDM_I4AL_eth3 dst -m ndmslin --slin 3 (public) -j _NDM_IP_PUBLIC

-A _NDM_IP_PUBLIC -p tcp -m tcp --dport 80 -j ACCEPT
-A _NDM_IP_PUBLIC -p tcp -m tcp --dport 443 -j ACCEPT

итого
80й и 443 поты доступны для соединения ТОЛЬКО в цепочке _NDM_IP_PUBLIC, которая вызывается ПОСЛЕ _NDM_INPUT и INPUT
вот я и предлагаю перенести фильтрацию в _NDM_INPUT перед открытыми портами

[dimon27254]

2 часа назад, odin2 сказал:

концепция фильтрации :
1) пропустить все УСТАНОВЛЕННЫЕ / ИЗВЕСТНЫЕ (из белого списка) соединения (99% трафика)

2) отфильтровать НОВЫЕ соединения (1% трафика)

2.1) аномальные (обнаружение сканирования ....) (0.9% трафика)

2.2) нормальные (желающие подключится к открытым портам) (0.1% трафика)
 

главное чтоб по выше стояло что часто срабатывает, а потом по мере уменьшения
чтоб было минимум холостых срабатываний

при малой нагрузке холостые срабатывания могут быть несущественны
но при больших могут стать заметными
но тут важнее ИЗВЕСТНЫЕ (из белого списка) чтоб "не выстрелить в ногу"
у вас есть белый список, все ли его заполняют ?
входят ли туда адреса от _NDM_ACL_IN_EXCEPTIONS ?

Антискан никак не связан с логикой NDMS. Он работает полностью отдельно от всей системной фильтрации трафика. Поэтому и стоит в самом начале цепочек INPUT и FORWARD.

Цель Антискана - отсечь всё ещё до попадания в цепочки NDMS.

Я предлагаю вам привести конкретные сравнительные примеры в цифрах, на сколько отличается загрузка процессора в текущей и вашей реализации. Например, при условных 500, 1000, 5000, 10000, 20000 соединений.

Я тестирую Антискан на роутерах с ARM, и каких-либо затруднений в прохождении трафика или падении производительности не замечал при количестве соединений около 5000.

Изменено 12 часов назад пользователем dimon27254

[odin2]

1 час назад, dimon27254 сказал:

Антискан никак не связан с логикой NDMS. Он работает полностью отдельно от всей системной фильтрации трафика. Поэтому и стоит в самом начале цепочек INPUT и FORWARD.

Цель Антискана - отсечь всё ещё до попадания в цепочки NDMS.

ваши правила работают в среде NDM, так что связаны

1 час назад, dimon27254 сказал:

Я предлагаю вам привести конкретные сравнительные примеры в цифрах, на сколько отличается загрузка процессора в текущей и вашей реализации. Например, при условных 500, 1000, 5000, 10000, 20000 соединений.

Я тестирую Антискан на роутерах с ARM, и каких-либо затруднений в прохождении трафика или падении производительности не замечал при количестве соединений около 5000.

речь не столько в нагрузке сколько в "выстрелить себе в ногу"
чтоб не заблокировать случайно нужные адреса, того же самого netcraze ( _NDM_ACL_IN_EXCEPTIONS )

ARM не у всех, на руках больше mips mipsel

Изменено 11 часов назад пользователем odin2

[odin2]

настоятельно рекомендую, для новых мыслей, полистать https://manual.mikrotik.com/docs/firewall-and-quality-of-service/firewall/ 

микротик очень хорош для обучения

но для боевого применения довольно стрёмен, потому что если плохо понял тему то будет очень печально

кинетик хорош тем что за тебя реализовали все BEST PRACTIS главная задача всё это не поломать
ещё кинетик хорош тем что это 2 в одном :
человекопонятная вебморда и наличие подкапотья в виде opkg (entware) - просто чудо

простой пример :

как на локальном интерфейсе поднять второй и третий и ... ип адрес например на tp-lik d-link ?

а в кинетике можно

[dimon27254]

6 минут назад, odin2 сказал:

ваши правила работают в среде NDM, так что связаны

Правила идут по логическому порядку до всех цепочек _NDM. Допустим, в Антискане настроек белый список. Если я создам правило МСЭ в NDMS с блокировкой какого-то IP, то пакет до него не дойдет, так как будет отфильтрован Антисканом.

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

9 минут назад, odin2 сказал:

речь не столько в нагрузке сколько в "выстрелить себе в ногу"

Мы с вами начали обсуждение как раз с нагрузки на процессор:

В 12.10.2026 в 15:11, odin2 сказал:

если вы начнёте что-то активно прогонять через роутер, даже внутри роутера на lo, то ваш проц напряжётся проверяя КАЖДЫЙ , КАРЛ, пакет ВСЕХ соединений.

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

12 минут назад, odin2 сказал:

сколько в "выстрелить себе в ногу"
чтоб не заблокировать случайно нужные адреса, того же самого netcraze 

Приведите реальные рабочие примеры, как это можно сделать в Антискане, особенно с сервисами Кинетика/Неткрейза.

[odin2]

17 минут назад, dimon27254 сказал:

Правила идут по логическому порядку до всех цепочек _NDM. Допустим, в Антискане настроек белый список. Если я создам правило МСЭ в NDMS с блокировкой какого-то IP, то пакет до него не дойдет, так как будет отфильтрован Антисканом.

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

если бы это был микротик, где все правила делаете ТОЛЬКО ВЫ то я с вами абсолютно согласен

но вы пришли в "чужой монастырь" и вводите свои правила на считаясь с "местными"

17 минут назад, dimon27254 сказал:

Мы с вами начали обсуждение как раз с нагрузки на процессор:

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

Приведите реальные рабочие примеры, как это можно сделать в Антискане, особенно с сервисами Кинетика/Неткрейза.

пример по нагрузке :
откройте SMB шару и заливайте туда, смотрите нагрузку проца

согласен, я начал тему с этого но потом расширил и это важнее чем нагрузка

пример :
атака специализированная на кинетики где обратным адресом стоят сервера Кинетика/Неткрейза и не только (ZeroTier ... )

Изменено 12 часов назад пользователем odin2

[dimon27254]

5 минут назад, odin2 сказал:

если бы это был микротик, где все правила делаете ТОЛЬКО ВЫ то я с вами абсолютно согласен

но вы пришли в "чужой монастырь" и вводите свои правила на считаясь с "местными"

С таким подходом, пожалуй, нужно закрыть все проекты, связанные с маршрутизацией трафика, так как они тоже не "считаются с местными", вставляя свои правила там, где считают нужными сами.

3 минуты назад, odin2 сказал:

пример :
атака специализированная на кинетики где обратным адресом стоят сервера Кинетика/Неткрейза и не только (ZeroTier ... )

Жду пример реального рабочего приложения/скрипта, которое сделает всё, что вы описали.

 

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

 

[odin2]

41 минуту назад, dimon27254 сказал:

С таким подходом, пожалуй, нужно закрыть все проекты, связанные с маршрутизацией трафика, так как они тоже не "считаются с местными", вставляя свои правила там, где считают нужными сами.

абсолютно согласен, потому что мы все живём не в сферическом вакууме, надо читать инструкции и рекомендации а так же самому ориентироваться на новой местности, туда ходи, туда не ходи.

41 минуту назад, dimon27254 сказал:

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

воля Ваша, остальным рекомендую для понимания моей мотивации

1 час назад, odin2 сказал:

настоятельно рекомендую, для новых мыслей, полистать https://manual.mikrotik.com/docs/firewall-and-quality-of-service/firewall/ 

https://noc.org/learn/iptables-default-blocks
 

Разрешение установленных соединений

Прежде чем блокировать всё, необходимо разрешить существующим соединениям продолжать работу. Без этого правила установка политики DROP немедленно разорвёт все текущие соединения, включая вашу SSH-сессию:

# Allow established and related connections (INPUT)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow established and related connections (OUTPUT)
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

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

Рекомендации по оптимальному порядку ввода данных:

1. Loopback allow — Всегда первый, обрабатывает локальный трафик
2. Установленные/связанные соединения — эффективно обрабатывает существующие соединения.
3. Правила ограничения скорости — применяются до правил принятия для услуг с ограничением скорости.
4. Правила разрешения для конкретных служб — SSH, HTTP, HTTPS и т. д.
5. Правила ICMP — Пинг и другие типы ICMP
6. Правила ведения журнала — Записывать в журнал перед сбросом по умолчанию.
7. Политика по умолчанию (DROP) — отсеивает все остальное.

я у себя подправил ваши правила и сижу спокойно, чего и вам желаю !

Изменено 11 часов назад пользователем odin2

[FLK]

1 минуту назад, odin2 сказал:

я у себя подправил ваши правила и сижу спокойно чего и вам желаю !

Этой фразой можно было бы заменить весь этот разговор ни о чем)))

[MDP]

21 минуту назад, odin2 сказал:

я у себя подправил ваши правила и сижу спокойно, чего и вам желаю !

ну сравнительный тест нужен тогда)))

Напихайте адресов штук 10000 (наверное можно одинаковые даже адреса) в какой нибудь список.

Просто интересно же.

[odin2]

учите матчасть, ссылки выше

[dimon27254]

2 часа назад, dimon27254 сказал:

Приведите реальные рабочие примеры, как это можно сделать в Антискане, особенно с сервисами Кинетика/Неткрейза.

Вы не привели рабочего примера. Отредактировали свое собственное сообщение, где добавили название цепочки, которая вообще не имеет какого-либо отношения к Антискану:

2 часа назад, odin2 сказал:

чтоб не заблокировать случайно нужные адреса, того же самого netcraze ( _NDM_ACL_IN_EXCEPTIONS )

Рассмотрим данную цепочку на моем примере.

Да, она стоит после правил Антискана. Однако, ссылается на следующие две цепочки:

А эти две цепочки содержат правила для работы Keenetic/Netcraze Cloud (облачная платформа):

И здесь обнаруживается, что цепочки предназначены только для протокола UDP.

Если вы внимательно изучите матчасть Антискана, то увидите, что он не поддерживает работу с UDP. А значит, ни одна из блокировок или защит Антискана даже теоретически не способна как-либо сломать работу мобильного приложения.

Эксперимента ради, я установил на своем тестовом роутере геоблокировку по белому списку на страну США. У меня отвалился только прямой доступ через CrazeDNS, что является абсолютно ожидаемым поведением. Ни мобильное приложение, ни доступ к серверу обновлений, ни RMM не отвалились и продолжили штатно работать даже после перезапуска роутера.

Свои собственные правки в репозиторий вы не предложили.

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

Изменено 10 часов назад пользователем dimon27254