Здравствуйте.

Задам необычный вопросец. Допустим к моему меридиану по PRI подключён клиентский Астерикс. Кто-то этот астерикс хакнул, получил над ним контроль и нагенерил много международки на платые инфоуслуги. Причём так хитро, что приходящее поле calling пустое при этом :eek:.
Вот моё начальство схватилось за волосы на попе и сказало, надо придумать что-то такое, что при превышении нагрузки её понижало.

Если скажем какая- там железяка дополнительная. Х.З. , есть мысли?

уменьшите кол-во каналов в потоке

Это идея! Надо будет один канал оставить :D

Транки в сторону астера как описаны? NCOSами не пробовали закрыть?

Транки в сторону астера как описаны? NCOSами не пробовали закрыть?

Вероятно не требуется прикрывать выход совсем, по этому предложение напрашивается само, поставить шлюз типа М200 или что то подобное, на котором отсекать звонки с пустым полем...

Правильный подход это конечно заставить * работать как следует.

Если нагрузка не велика можно мониторинг д канала включить и скриптом то же отекать звонки с пустым полем звонящего. Но это как локальная полицейская мера.

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

ЗЫ. Надо будет найти на avito_точка_ru M-200 , вчера там купил нормальный М3820 за 100 руб.

Здравствуйте.

Задам необычный вопросец. Допустим к моему меридиану по PRI подключён клиентский Астерикс. Кто-то этот астерикс хакнул, получил над ним контроль и нагенерил много международки на платые инфоуслуги. Причём так хитро, что приходящее поле calling пустое при этом :eek:.
Вот моё начальство схватилось за волосы на попе и сказало, надо придумать что-то такое, что при превышении нагрузки её понижало.

Если скажем какая- там железяка дополнительная. Х.З. , есть мысли?

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

Вообще на самом деле идея поставить M-200, очень даже хорошая и отсекать все звонки с неверным CallerID. Если звоночки пришли с * без номера, возможно на звездочки просто разрешены анонимные звонки вот и все.
По хорошему вам М-200, как вариант не пропускания не верных CallerID, вашему клиенту хорошие руки для настройки как самого Asterisk, так и системы защиты его от взломов.

Можно вопрос? Кто хакнул астерикс? Может проще разобраться на этом уровне, чем покупать М-200?

Можно вопрос? Кто хакнул астерикс? Может проще разобраться на этом уровне, чем покупать М-200?

Кто не ясно IP разные (наверно прокси), проблема на роутере где-то была много чего разрешено из вне было. Точно не знаю, только со слов админа. Просто таких клиентов с * может быть не один и не два и уровень админов на местах разный может быть.

Кто не ясно IP разные (наверно прокси), проблема на роутере где-то была много чего разрешено из вне было. Точно не знаю, только со слов админа. Просто таких клиентов с * может быть не один и не два и уровень админов на местах разный может быть.
* всяко нужно приводить к правильным уровням безопасности. Следовательно, для данного * клиента нужно найти правильную фирмяшку поддержки * на последующий период. Это уже вопрос не для публичного форума.

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

Очень часто * ставят от жадности, на предложение заплатить за поддержку представляю, какой будет ответ.
Жизнь их будет лечить рублем - сначала обязательно таких ребят с * хакнут, потом будет счет с кучей нулей от оператора, а потом они подумают о поддержке. Если такое случится, оператор по пути умоется кровавыми слезами, так что бороться превентивно все равно надо.

Вообще на самом деле идея поставить M-200, очень даже хорошая и отсекать все звонки с неверным CallerID. Если звоночки пришли с * без номера, возможно на звездочки просто разрешены анонимные звонки вот и все.
По хорошему вам М-200, как вариант не пропускания не верных CallerID, вашему клиенту хорошие руки для настройки как самого Asterisk, так и системы защиты его от взломов.

Чем она хорошая, объясните? Заплатит человек 100 т.р. за М200 и что?
Кто мешает злоумышленнику выплевывать звонки с совершенно правильным clid-ом, раз уж они похакали *? А сколько можно налить трафика на инмарсат или в Африку хотя бы за ночь по полному E1 можете сами прикинуть.

Имеется еще ретро-вариант: все идущие транзитом на МГ/МН вызовы от * переадресовывать на оператора (операторов) Меридиана с последующим опросом и установлением соединения уже от оператора.

Чем она хорошая, объясните? Заплатит человек 100 т.р. за М200 и что?
Кто мешает злоумышленнику выплевывать звонки с совершенно правильным clid-ом, раз уж они похакали *? А сколько можно налить трафика на инмарсат или в Африку хотя бы за ночь по полному E1 можете сами прикинуть.

Тут двоякий вопрос, изначально если Meridian выступает в роли провайдера они должны иметь возможность не пропускать звонки с не верным Clid чего как раз и не может Meridian, это им так же полезно будет в анализе биллинга потом.
Кто и как хакнул вы никогда не найдете, хотя конечно найти можно пройти цепочку анонимных прокси и все такое, ну очень уж это долго будет.
А еще я предложил вариант что * не хакнули а у нее просто разрешены анонимные звонки. В любом случае как бы то ни было, Asterisk нуждается в настройках.
Средство защиты на Meridian, возможно только на данном маршруте закрыть все направления которые не использует клиент с Asterisk (инфоуслуги, Африка да почти все куда не звонит клиент), конечно как защита это минимум но может съэкономить N-ое количество денег.

А так вообще если Asterisk не ваш MAX2, вам какая разница??? Клиент оплатит все куда звонили.

Тут двоякий вопрос, изначально если Meridian выступает в роли провайдера

Автомобиль не может выступать в роли водителя.

Здравствуйте.

Задам необычный вопросец. Допустим к моему меридиану по PRI подключён клиентский Астерикс. Кто-то этот астерикс хакнул, получил над ним контроль и нагенерил много международки на платые инфоуслуги. Причём так хитро, что приходящее поле calling пустое при этом :eek:.
Вот моё начальство схватилось за волосы на попе и сказало, надо придумать что-то такое, что при превышении нагрузки её понижало.

Если скажем какая- там железяка дополнительная. Х.З. , есть мысли?
Есть такая мысль! Можно написать скрипт (например, на php или vbs), который будет периодически, скажем раз в 10 минут, обрабатывать CDR-файл Меридиана и анализировать его по определённым признакам, а в случае обнаружения нарушения - отправлять администратору станции уведомление (по локальной сети или на эл. почту).

Признаки взлома могут быть разными: большая сумма продолжительности звонков с одного номера, большое количество звонков с одного номера, длительные звонки на МН направления, перевес МН/МГ трафика над местным и др.

Как говорится, +1

На астериске есть биллинг? Что мешает прикрутить к биллингу gsm-шлюз и отправлять сумму расходов по расписанию. Например отправляем утром, вечером и поздно вечером. Всегда под рукой баланс - его заметное изменение и гасим астериск до выяснений обстоятельств незапланированного повышения расходов (трафика).

Ну вот в общих чертах как то так.... на вскидку не углубляясь в суть вопроса, писал не я. Основной вывод, безопасность IP сети есть вопрос комплексного подхода.
_______________________



• Для выявления атак используйте систему обнаружения вторжений уровня хоста.

• С целью защиты IP-УАТС от атак из ЛВС и Интернет разверните МЭ (межестевой экран), оптимизированный для поддержки речевого трафика.

• Используйте коммутируемую ЛВС, что не только улучшит производительность VoIP-системы, но и затруднит получение злоумышленником доступа к ее компонентам.

• Используйте виртуальные ЛВС, чтобы изолировать телефонный трафик.

• Обеспечьте защиту всех сетевых компонентов, включая коммутаторы, маршрутизаторы и т. д.

• Для кампусной сети IP-телефонии МЭ и прочие системы Интернет-безопасности сконфигурируйте таким образом, чтобы предотвратить выход VoIP-трафика за пределы внутренней сети.

• Ограничьте число вызовов, попадающих через территориально распределенную сеть на медиашлюз или любой другой разделяемый ресурс, который может быть парализован DoS-атакой.

• Рассмотрите возможность установки дополнительных МЭ и средств безопасности с целью контроля сетевого трафика.

Специализированные МЭ

Развернуть на сети VoIP-оптимизированные МЭ и шлюзы безопасности на ключевых участках сети. К последним относятся участки между IP-УАТС и телефонами, периметры территориально распределенной сети и сети сервис-провайдера/Интернет-провайдера. VoIP-оптимизированный МЭ осуществляет следующие функции:

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

• Обеспечивает 99,999% работоспособного времени в сеансах передачи данных (media sessions) и отсутствие дополнительной задержки в них.

• В случае необходимости и по мере возможности обеспечивает интерфейс с другими имеющимися МЭ.

• Транслирует сетевые адреса с учетом протокола и управляет сеансом передачи данных.

• Поддерживает маркеры QoS.

• Поддерживает безопасность в гибридных сетях на период перехода к IP-телефонии.

И не забудьте о телефонах

Не менее важно защитить IP- и программные телефоны. Последние — это наиболее распространенный, а следовательно, наиболее уязвимый компонент VoIP-сети. Можно дать следующие рекомендации по защите телефонов:

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

• Применяйте усиленную парольную защиту.

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

• Запретите удаленный доступ, такой, как telnet.

• Применяйте строгую аутентификацию для любого Web-доступа к телефону.

• Запретите локальное администрирование телефона.

• Позаботьтесь о безопасности процесса обновления микропрограммного обеспечения (firmware) телефона.

• Обеспечьте регистрацию событий, если есть такая возможность.

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

Установите стандарты

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

Transport Layer Security (TLS). Обеспечивает шифрование “точка—точка” и аутентификацию сеанса TCP/IP, например при обмене данными между IP-УАТС и телефоном. Secure RTP (SRTP). Обеспечивает шифрование сеанса передачи данных. IP Security (IPsec). Предоставляет средства шифрования и аутентификации на третьем уровне OSI. S/MIME. Используется для шифрования и гарантирует целостность SIP-сообщений..