asterisk.ru

Подключился к старой АТС версии 1.8
И периодически проскакивают подобные сообщения
[2021-12-17 16:45:59] NOTICE[9415]: chan_sip.c:22793 handle_request_invite: Sending fake auth rejection for device <sip:801@X.X.X.X>;tag=929606901
Где X.X.X.X Айпи АТС
Попытки подбора учёток с помощью пакетов регистрации банится fail2ban
Для исключения этого подбора Инвайтами, надо пачтить исходники АТС или переходить на версию выше, с этим понятно.
Не понятно другое, смысл этих действий злоумышленника, даже если уч данные будут угаданы, все равно выскочит аналогичная SIP/2.0 403 Forbidden (Bad auth), пока не будут оправлены валидные пакеты регистрации
При активных опциях
alwaysauthreject=yes
allowguest=no
Или я не прав ?

Хм сейчас с 8 американских айпи, притом везде From: <sip:10001@ (Предполагаю это зараженные вирусом пользовательские ПК Зомби, которые принадлежат одному взломщику)
Сыплют Инвайтами без пароля, натыкаясь на SIP/2.0 401 Unauthorized

Цифры в поле To: постоянно новые, но есть закономерность, после первых четырех цифр следует 46431313360

From: <sip:10001@
To: <sip:579246431313360@

From: <sip:10001@
To: <sip:915246431313360@

Что это за первые 4 цифры, полагаю 46431313360 это все же номер, мне интересно, а в самом модуле sip нет уязвимости, которое позволяет пересылать пакеты в обход диалплна и других модулей.

Префиксы подбирают чтобы прозвониться. Это сканеры.
Asterisk 1.8 имел уязвимость в chan_sip, и я бы Вам не советовал открывать порт 5060 для всего мира, даже с fail2ban - сканеры стали умными и атака может быть длительной - месяцами, чтобы в бан не попадать.

Да как то не похожи эти 4 цифры на префиксы, на 13 Астериске если убрать правило по инвайтам в файл2бан, аналогичный подбор (да и с ним постоянно, айпи меняются, притом владелец этих ботов один), как будто ID подбирают (ID чего ?), тут конечно надо исходники изучать.
Смысл подбирать префиксы, если не попасть в диалплан не пройдя регистрации, без этой процедуры ответ на инвайт даже с правильными учетными данными, будет стандартный SIP/2.0 403 Forbidden
Я чего боюсь, что взломают и найдут способ переправить сигнализацию внутри самого chan_sip, а я даже об этом не узнаю, так как в логах это не будет отражено.
А что за уязвимость была в 1.8 ?, и в какой ревизии она была устранена, ведь 1.8 развивалась очень долго

Да как то не похожи эти 4 цифры на префикс

Очень даже похоже на это, точнее - стандартно.
Думать не надо - закрывать нужно форточку, а то будет поздно когда на Сомали налетите.
В 1.8 так и не поправили CVE, поскольку EOL.

А если вас затруднит рассказать, как все таки происходит этот взлом, какие звезды должны сойтись чтоб это произошло, каким образом они попадают в диалплан если вообще в него попадают ?

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

Слишком прозаично, повторюсь при активных опциях
alwaysauthreject=yes
allowguest=no
Вообще не будет никакой разницы, есть реальный пир или нет, ответ будет един.
SIP/2.0 401 Unauthorized при отсутствии данных авторизации
SIP/2.0 403 Forbidden (Bad auth) с данными авторизация (притом даже если они валидные)

Как раз обычно пытаются подбирать с одного аккаунта (которого обычно в реальности нет), меняя номер в поле To:

С опциями которые вы указали астериск прекрасно сделает вызов по инвайту
достаточно в настройке пира "напортачить" и никакие опции не помогут

Если не затруднит, приведите пример корявого пира