[zergty]

Приветствую всех!

При строительстве КСПД , сеть основной офис 400 человек , по туннелям gre, сейчас 2 офиса подключено , gre без шифрования. Еще по l2tp/ipsec ходят примерно 70-80 человек.

Еще снаружи временно по открытому порту sip (это временно) ходят еще 400 человек.

Внутри сети стоит Asterisk.

Та проблема что я сейчас опишу внутренних пользователей КСПД не касается, они ходят на Asterisk по его внутреннему "серому адресу" не пересекая nat так сказать.

Для того чтобы пустить пользователей снаружи сделан пор маппинг на основном маршрутизаторе cisco 3945, и включен на внешнем интерфейсе ip inspect FW in , в  ip inspect FW sip.

Как только эту команду включаешь во первых задержка увеличивается в канале в интернет, во вторых часть часть офисов работает в телефонии другая нет. Я вижу что rtp сессии открываются , но как будто не у всех и в каком то случайном порядке. Регистрация по порту 5060 который порт маппингом прописан проходит у всех без проблем.

Такое ощущение что у него производительности не хватает для именно inspect sip. Причем через этот insptect  всего то ну 400 пользователей пытаются работать. 

Остальные кто в КСПД (те кто через туннели и VPN щики, ну кто не через nat, у них все ок!)

Как только отключил inspect и тупо закинул 1000 пробросов udp портов для RTP. Человек по астериску поправил диапазон на эту тысячу сразу все взлетело.

 

Вроде бы у 3945 должно силенок хватать на такую нагрузку с inspect ?

Или я что то туплю, подскажите кто в курсе плс.

 

 

С уважением.

 

 

 

[jffulcrum]

Что show processes cpu sorted 5sec показывает?

[SUrov_IBM]

Zergty, здравствуйте.

 

В 24.12.2021 в 17:53, zergty сказал:

Вроде бы у 3945 должно силенок хватать на такую нагрузку с inspect ?

Возможно, предположу глупость, но мне кажется, что на порт сигнализации сыплются SIP INVITE от фрод скриптов. И при обработке через SIP inspection данных фрод INVITE, CISCO начинает "захлёбываться".

 

На практике, мою старуху CISCO 2851, при установленном voice ip address trusted list, фрод INVITE "заваливали" так, что по SSH было не попасть (возникали ошибки по памяти), канал был 25-30 Мб/Сек., она "захлёбывалась" отвечать sip forbidden. В моём случаи, было проще, я имел возможность ограничить voice доступ по ACL, с определённых IP адресов. По счётчикам ACL, видно, что опрос на VoIP порты происходит постоянно, но когда CISCO не отвечает на INVITE запрос, фрод скрипт быстро "отваливает" в сторону, если получил ответ forbidden, начинает переборку всевозможного набора цифр в INVITE, для попытки фрод "до посинения", с возрастанием запросов, пока CISCO не "захлебнётся".

 

"Звёздная АТС", со своим Fail2ban или что там у неё (я в ней не специалист), возможно намного проще переносит такие фрод INVITE, потому что работает на компьютерном CPU, в отличии от CISCO IOS.

[SUrov_IBM]

P.S. Для себя, я давно точно решил, что если CISCO (железный маршрутизатор, не ASA, за неё ничего не скажу) должна заниматься обработкой VoIP сигнализации, то обязательно должна быть ограничена взаимодействием только с доверенными (разрешёнными) по IP партнёрами. Разрешёнными, именно на уровне фильтрации IP по ACL, а не по собственному механизму проверки подлинности в сигнализации. Если нет возможности ограничить доступ по доверенным партнерам (вызов должен приходить из любой точки внешней сети), CISCO в таком случае не должна использоваться как коммутатор VoIP трафика, обрабатывающий сигнализацию (SIP, H.323 и прочие), иначе в лучшем случае ей "будет плохо" под воздействием фрод, в худшем, фрод  будет успешным, с последующим "проливанием" телефонного трафика на Сейшельские острова. ;)

 

Просто пример, количества отклонённых по ACL фрод запросов (счётчики matches), на популярных TCP/UDP портах сигнализации VoIP, за несколько дней, на маршрутизаторе CISCO имеющим несколько WAN IP адресов. Маршрутизатор не ответил на запросы, а показал состояние порта close. Если бы вступил в диалог, обрабатывая по voice ip address trusted list, боюсь что его стали бы терроризировать постоянно, а так не интересно в "молчанку играть" и ушли искать другую жертву.

Edited December 24, 2021 by SUrov_IBM

[zergty]

Приветствую всех!

 

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

Отключен МСЭ был в тестовых целях, при тестировании проекта строительства КСПД. Такие знания можно только на опыте получить. А я раньше с такой проблемой не сталкивался.

Для меня все стало понятно.

 

 

С уважением,

Юрий

[YuryD]

 Видимо надо помнить, что регистрация в сип и ртп в нем- немного разные протоколы, соотв фаер должен отсечь по acl все попытки регистрации не из белого списка, т.е. отсечь наглухо все пробы хакеров извне на регистрацию-попытки. Касаемо хитрости какеров, нас прорулили по какому-то багу в киске и h.323, назвонили на кубу из штатов. Дело было давно, отсудились по иным причинам.

 

 Ну и да, фильтровать по протоколу-порту, это задача процессора и стека, посему выше просто надо фильтровать по голому Ip, это дешевле для проца.

[zergty]

В 25.12.2021 в 17:53, YuryD сказал:

 Видимо надо помнить, что регистрация в сип и ртп в нем- немного разные протоколы, соотв фаер должен отсечь по acl все попытки регистрации не из белого списка, т.е. отсечь наглухо все пробы хакеров извне на регистрацию-попытки. Касаемо хитрости какеров, нас прорулили по какому-то багу в киске и h.323, назвонили на кубу из штатов. Дело было давно, отсудились по иным причинам.

 

 Ну и да, фильтровать по протоколу-порту, это задача процессора и стека, посему выше просто надо фильтровать по голому Ip, это дешевле для проца.

Спасибо, нет ненужно напоминать, я знаю как работает sip. Меж Сетевой Экран был отключен на время тестирования.

 

С уважением.

[dvb2000]

Чтоб ставить между Asterisk и интернетом что то вроде такого cisco 3945 нужно быть очень мужественным человеком. То что на Asterisk имеется fail2ban это не мешает загрузить канал и на 1G и даже более широкий запросами спамеров и скамеров приходящими с простор интернета. И чем дольше Asterisk будет светиться в интернет, тем больше таких запросов будет приходить, пока его база не развалится от переполнения логов от этих запросов, даже если они режутся в fail2ban после нескольких неудачных повторов.

Чтоб защитить SIP SoftSwitch от угроз приходящих с бескрайних простор интернета требуется несколько простых программных приспособлений. Все они могут быть бесплатными, например модулями на базе pfSense. Первое это обновляющиеся чёрные списки  файрволла. В pfSense это зовётся pfBlockerNG. Если поглядеть на статистику этого модуля сразу становится ясно для чего он нужен:

 

Запросы на порт SIP составляют 30% от всех проб ломать чего либо.

 

Второе приспособление это модуль IPS/IDS именуемый SNORT, который в реальном времени мониторит весь трафик и режет вредные подключения. После того как всё настроено, в fail2ban пробираются максимум пару левых запросов за месяц, как можно видеть в следующем скрине:

 

 

[zergty]

Приветствую Вас.

 

Тут вопрос не в том, что маршрутизатор 3945 стоит между интернет и asterisk, тут был вопрос какую технологию использовать для проброса пакетов rtp внутрь.

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

 

 

С уважением.

[dvb2000]

Приветствую Вас.

 

Одно дело что маршрутизатор 3945 стоит между интернет и asterisk, и именно как маршрутизатор это одна нагрузка на 3945. Другое дело если этот 3945 ещё и держит NAT таблицу, это уже другая нагрузка на него, и совсем не дело требовать от 3945 анализировать SIP траффик приходящий со стороны интернета. И проблема тут скорее всего совершенно не с RTP, а именно с самим SIP и с пробами регистрации на  него всех тех ботов что сканируют все белые адреса. 

И именно по этому Cisco 3945 тут не приемлем, так как на наружном адресе (между интернетом и Asterisk) должны стоять те устройства которые я описал выше, или же подобные им, а не как не Cisco 3945.

 

[zergty]

В 26.12.2021 в 22:12, dvb2000 сказал:

Приветствую Вас.

 

Одно дело что маршрутизатор 3945 стоит между интернет и asterisk, и именно как маршрутизатор это одна нагрузка на 3945. Другое дело если этот 3945 ещё и держит NAT таблицу, это уже другая нагрузка на него, и совсем не дело требовать от 3945 анализировать SIP траффик приходящий со стороны интернета. И проблема тут скорее всего совершенно не с RTP, а именно с самим SIP и с пробами регистрации на  него всех тех ботов что сканируют все белые адреса. 

И именно по этому Cisco 3945 тут не приемлем, так как на наружном адресе (между интернетом и Asterisk) должны стоять те устройства которые я описал выше, или же подобные им, а не как не Cisco 3945.

 

Приветствую Вас!

Зачем с наружи нужно ставить что то другое если внутри  asterisk  справляется с теми задачами о которых Вы говорите ? Этот маршрутизатор работает в большой КСПД, а эта функция не большая часть КСПД. Еще раз Вам повторяю , проброс сделан прямой на asterisk  и как Вы сказали он решает необходимые задачи.

Я Вам напоминаю , был вопрос в выборе технологии на маршрутизаторе 3945, использовать ли  инспекцию трафика или нет ? Прочитайте в интернете что такое инспекция трафика у Cisco и Вы поймете о чем я говорю.

 

С уважением. 

PS.  Прочитайте первое сообщение мое, по регистрации не одного вопроса не было , она всегда работала у всех.

 

 

Edited December 26, 2021 by zergty

[ShyLion]

ZBFW пробовали?

Конфиг чтоли покажите, а то может там в другом проблема.

[zergty]

Приветствую Вас!

Да вопрос давно закрыт! Люди которые разбираться в теме , первые 3 ответа мне помогли. 

Все тема закрыта.

 

 

Привет всем, 

С уважением