dimon27254

Блокировка по белому списку уже отсекает огромное количество ботов и нежелательных подключений. А всех остальных отсекают остальные защиты. Поэтому ждать здесь каждую секунду увеличивающиеся значения точно не стоит. Стоит отметить, что если у вас что-то настроено неправильно (не тот интерфейс, не те порты), то никакая защита не будет работать.

Можно, например, воспользоваться WebCLI (Консоль RCI). Выполните команду show internet status В ответе найдите строку "interface". В ней в кавычках после двоеточия будет написано имя интерфейса, которое нужно себе записать. В моем примере это PPPoE0 (у вас может быть другим). Это еще не искомое имя. Теперь выполните команду: show interface ваше_имя system-name В результате найдите строку "system-name", и в кавычках после двоеточия окажется искомое имя интерфейса, которое нужно вписать в ascn.conf. У меня это будет: ISP_INTERFACES="ppp0" Для начала необходимо понять, на каких портах работает ваш сервер, какие порты открыты и как сервер подключен к роутеру. Также важно понять, на каких портах работает ваш роутер. Эта информация находится в разделе "Пользователи и доступ" веб-интерфейса роутера. Нужны номера портов HTTP, HTTPS и Telnet (если для него стоит галочка "разрешить доступ из интернета". Что вы подразумеваете под остальными? В HONEYPOT_PORTS вписываются порты, которыми не пользуются ваши клиенты. При подключении к этим портам пользователь сразу же блокируется.

Я бы не рекомендовал полностью заменять ваш конфиг другим. У вас могут быть другие интернет-подключения или перечень портов. Самое главное - иметь указанный каталог в IPSETS_DIRECTORY, установленную геоблокировку в режиме белого списка GEOBLOCK_MODE="whitelist" , а также страну Россия в списке стран: GEOBLOCK_COUNTRIES="RU"

В 5.2 Alpha 2 исправлено. Спасибо!

В 5.1.2 запросы на localhost:79 также начали возвращать 403.

В 5.2 Alpha 1 исправлено. Спасибо!

Подтверждаю исправление в 5.2 Alpha 1. Спасибо!

Подтверждаю исправление в 5.2 Alpha 1. Спасибо!

В 5.2 Alpha 1 реализовано в виде отдельного компонента Web Shell. Спасибо!

Hotfix 1.10.5 Исправлена ложная блокировка запуска с ошибкой "Токен доступа не найден. Задайте его и перезапустите Antiscan" в ПО 5.1 и ниже, проявляющаяся после перезапуска роутера при установленном Entware на внутреннюю память (сообщил @Dhampir113).

Спасибо за предоставленный лог! Проблема локализована. Скоро будет выпущена версия 1.10.5 с исправлением.

Пришлите, пожалуйста, мне в личные сообщения лог с вашего роутера. Чтобы в нем был и процесс запуска Кинетика, и попытки неудачного старта Антискана.

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

Новая версия 1.10.4. Новое: 1. Поддержка токенов доступа (для ПО версии 5.2 и выше). Спасибо @eralde. Токены доступа - новый и безопасный способ передачи запросов к системе, появившийся в ПО версии 5.2. Если вы перешли на 5.2, то рекомендуется создать и установить токен уже сейчас. В будущих версиях ПО токен может стать единственным способом получения данных от системы, и без него Antiscan не сможет работать. Работа с токенами приведена ниже. Информация может изменяться или дополняться. 2. Проверка наличия установленного компонента "Модули ядра подсистемы Netfilter". Теперь Antiscan перед запуском проверяет наличие указанного компонента. Если проверка завершится неудачно, запуск прерывается с выводом ошибки в консоль и лог. 3. Автозапуск Antiscan после завершения установки (предложил @MDP). 4. Автоматическая установка и настройка cron. Важная информация для пользователей с ПО версии 5.2: версии Antiscan 1.10.3 и ниже не совместимы с 5.2. Необходимо обновиться до актуальной версии.

@KoneTaH @admin @hlnw Если в роутере имеются object-group fqdn, то при выгрузке self-test для каждой группы в логе появляются ошибки вида: Xml::Document: system failed [0xcffd078c], invalid ELEMENT node name: "_NDM_OGDN_4@default/do-122843c3". Xml::Document: system failed [0xcffd078c], invalid ELEMENT node name: "_NDM_OGDN_6@default/do-c81e5440". Проверял на KN-1012 с 5.2 Alpha 1.

@KoneTaH @admin @hlnw Если обратиться к RCI с некорректным или уже удаленным токеном, то в логах появляются сообщения о попытках бана системой 127.0.0.1: Netfilter::Lockout::Manager: "Http": system failed [0xcffd037b], [H4] invalid address '127.0.0.1'. Проверял на KN-1012 с 5.2 Alpha 1.

@KoneTaH @admin @hlnw В 5.2 Alpha 1 модуль ядра xt_multiport.ko теперь не представлен в виде файла, из-за чего "ломаются" скрипты, явно проверяющие его наличие. Он теперь вкомпилирован в ядро, т.к. его можно использовать в iptables без предварительной подгрузки. Это какая-то ошибка, или же запланированное изменение? Проверял на KN-1012.

@eralde @Anna_ @Test Pilot Сейчас информация по созданному токену появляется только после закрытия окна создания. bandicam 2026-07-18 07-40-08-825.mp4 Было бы удобно, чтобы вся информация появлялась сразу же после генерации токена без ожидания закрытия окна. Так можно скопировать токен, оставить его на некоторое время показываться в окне еще для тестов, и в этот момент где-то проверить его корректность, увидев время последнего использования. Проверял на KN-1012 с 5.2 Alpha 1.

@KoneTaH @admin @hlnw В 5.2 Alpha 1 перестали приниматься запросы на localhost:79, для них всегда возвращается ошибка 403, даже с токеном. При этом, 127.0.0.1:79 работает: Проверял на KN-1012.

@eralde @Anna_ @Test Pilot В 5.2 потерялся отступ после группы селекторов: Для сравнения вариант из 5.1.1: Проверял на KN-1012 с 5.2 Alpha 1.

@KoneTaH @Infy @hlnw Имеется контроллер MWS KN-1012, на котором стоит 5.2 Alpha 1, и подключенный к нему ретранслятор NAP-650 с установленной 5.1.1. Время от времени в логах NAP-650 появляются "ack SB length (231) is invalid". 5.1.1 не понимает какие-то сообщения от контроллера на 5.2?

@KoneTaH @admin @hlnw В 5.2 появились токены доступа, которые, как я понимаю, в будущем станут одним единственным способом обращения к RCI из Entware. Хотелось бы понять: 1. Как долго еще останется неавторизованный доступ к RCI по 127.0.0.1:79? На данный момент запросы без токена еще принимаются, хоть система и отправляет в лог предупреждения. 2. Как для пользователя или скриптов в Entware будет выглядеть переход на токены доступа в 127.0.0.1:79? После очередного обновления RCI будет просто возвращать HTTP-код 401 вместо успешной обработки запроса, или же как-то иначе? 3. Хотелось бы увидеть все возможные примеры применения токенов. Судя по всему, они будут полезны не только при обращении к 127.0.0.1:79, но и в каких-то иных сценариях. 4. Всегда ли токен, генерируемый пользователем, будет содержать 56 символов, а также латинские буквы и/или цифры? 5. Возможно ли будет создавать токены с readonly-доступом к RCI? 6. Планируется ли "прикрывать" ndmc -c ? На данный момент там никаких ограничений нет, и система каких-либо предупреждений не возвращает.

Одной замены URL недостаточно, нужно еще править парсинг списков подсетей. Опишу правки для версии 1.10.3. В geo.sh: 1. Замените строку под номером 52 следующим содержимым: curl --connect-timeout 30 --retry 5 --retry-delay 10 --max-time 60 -fsS "https://www.iwik.org/ipcountry/${country}.cidr" -o "$curl_temp_file_path" 2>/tmp/ascn_curl1_error 2. Строку 83 замените на: grep -oE '[0-9]{1,3}(\.[0-9]{1,3}){3}(/[0-9]{1,2})?' "$curl_temp_file_path" 2>"/tmp/ascn_jq_error" >"$geo_subnets_file" У себя протестировал, списки успешно загружаются. Если загрузка завершится ошибкой по какой-то причине, Антискан, как и ранее, скачает с зеркала список RIPEstat. На будущее подумаю о возможности более гибкого указания URL для использования ваших собственных списков 🙂

На данный момент смена источника геоданных не предусмотрена. Могу вам предложить только вариант с правкой исходного кода Антискана.