I have read/write access to the entire system memory, and HV level access to the processor. In other words, I have hacked the PS3. The rest is just software. And reversing. I have a lot of reversing ahead of me, as I now have dumps of LV0 and LV1. I’ve also dumped the NAND without removing it or a modchip.

3 years, 2 months, 11 days…thats a pretty secure system

Возможность запуска Linux на PS3, позволила geohot-у запускать своё ПО для проверки разнообразных гипотез и, в конечном счёте, получить доступ к памяти гипервизора. В конце 2009 года, линейка приставок PS3 была обновлена, новая модель называется PS3 Slim. Гипервизор новой модели не позволяет запускать Linux, но, скорее всего, реализация доступа к памяти не изменилась.

Рассмотрим пример из жизни: у вас есть сеть IP телефонии принимающая звонки от АТС и отправляющая их по IP дальше.

Зачастую, для решения проблем, необходимо видеть ход установления/разрыва вызовов. Для мониторинга ISDN существует масса дорогих и не очень устройств, позволяющих «встать на поток» и просмотреть всю информацию, относящуюся к Q931. Кроме того, голосовые шлюзы Cisco предоставляют удобные встроенные средства для просмотра Q931 даже на загруженном оборудовании. Делается это так:

debug condition called 1234567
debug isdn q931
ter mon

Первая команда устанавливает фильтр, отображаться будут лишь те сообщения, которые относятся к вызову на указанный номер. Фильтр можно устанавливать как на набранный номер (Б номер) так и на отдаваемый АОН (А номер). Фильтров может быть несколько, тогда информация выводится на экран, если она удовлетворяет хотя бы одному фильтру. Вторая команда, включает отладку ISDN Q931. Третья команда включает отображение отладочной информации на текущем терминале. К сожалению таких удобных встроенных средств как debug condition для отладки IP телефонии – нет, приходится пользоваться внешними средствами – сетевым анализатором. Использовать сетевой анализатор можно на роутере. Но как быть, если это не PC роутер? т.е. на нём нет Linux/FreeBSD и привычного инструментария в виде tcpdump, wireshark и ngrep? или если это роутер провайдера и доступ к нему невозможен? Как без перерывов связи подключить к схеме, преведенной выше, сетевой анализатор? Очень просто: его следует подключать к свитчу.

По умолчанию, коммутаторы, как известно, посылают ethernet фреймы, только на тот порт, на котором находится MAC адрес получателя (если он известен). Серия коммутаторов Catalyst от Cisco поддерживают технологию Catalyst SPAN (Switched Port Analyzer), которая позволяет подключать сниффер к любому порту или набору портов коммутатора.

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

Как правило, коммутаторы поддерживают несколько сессий мониторинга (например, Catalyst 2960G, из примера выше, поддерживает 66 сессий). В одной сессии мониторинга может быть несколько портов источников. Источником может быть любой физический порт (e, fa, gi, te), объединение портов (EtherChanel) и т.д. Источником не может быть порт работающийй приёмником. Приёмником так же не могут быть EtherCahnnel. Настройка SPAN отличается в зависимости от модели коммутатора. Здесь я приведу настройку, для самых распространённых, на мой взгляд, моделей: 2950, 2960, 3550, 3560.

Для начала проверим список интерфейсов:

voip-cat-1#sh int descr
Interface                      Status         Protocol Description
Vl1                            up             up
Gi0/1                          up             up       voipgw
Gi0/2                          up             up       voipgw2
Gi0/3                          up             up       voipgw3 / conf
Gi0/4                          up             up       voipgw4
Gi0/5                          up             up       voipdb
Gi0/6                          up             up       SIP proxy
Gi0/7                          up             up       voipgw5
Gi0/8                          up             up       voiptest
Gi0/9                          up             up       voiptest
Gi0/10                         up             up       link to sw312
Gi0/11                         up             up       voipdb2
Gi0/12                         up             up       SIP proxy 2
Gi0/13                         up             up       storage
Gi0/14                         down           down
Gi0/15                         down           down
Gi0/16                         down           down
Gi0/17                         down           down
Gi0/18                         down           down
Gi0/19                         down           down
Gi0/20                         down           down
Gi0/21                         down           down
Gi0/22                         down           down
Gi0/23                         down           down
Gi0/24                         up             up       Optical uplink

Если коммутатор позволяет давать портам текстовые названия – не следует этим пренебрегать. Описывайте порты и тогда вы существенно облегчите жизнь себе и своим коллегам. Предположим, что мы хотим проанализировать трафик от устройства voipgw, которое находится на первом порту. Теперь выбираем порт для подключения сниффера. Следует выбрать любой нерабочий порт, например 19ый. Теперь, когда мы определились с портами, сконфигурируем сессию мониторинга:

voip-cat-1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
voip-cat-1(config)#monitor session 1 source interface gi0/1
voip-cat-1(config)#monitor session 1 destination interface gi0/19
voip-cat-1(config)#^Z

Посмотрим параметры сессмм:

voip-cat-1#sh monitor session 1
Session 1
---------
Type                   : Local Session
Source Ports           :
    Both               : Gi0/1
Destination Ports      : Gi0/19
    Encapsulation      : Native
          Ingress      : Disabled

Вот и всё! Теперь можно подключать ноутбук с любимым wireshark к 19 порту, и смотреть входящий и исходящий ethernet трафик от устройства voipgw. Кстати СОРМы подключаются точно так же. Если есть свободный ethernet порт на несильно загруженном сервере, то можно подключить этот порт к коммутатору, тогда всю процедуру анализа трафика можно будет осуществлять удалённо, перенастраивая сессию мониторинга на лету.

Пара слов о Wireshark

Wireshark имеет 2 набора фильтров. Первый называется просто и незатейливо – Filter. Строка для редактирования этого фильтра находится в основном окне сверху.

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

q931.called_party_number.digits == "74951234567"

Можно выбрать все пакеты содержащие h323 вызов (SETUP) на номер 74951234567, а с помощью такого:

q931.call_ref == 4f:f9

Все пакеты относящиеся к звонку с call reference равным 4f:f9 от начального SETUP до финального RELEASE COMPLETE. Гибкость фильтров отображения компенсируется их медлительностью. Не следует использовать эти фильтры на «живом захвате». Для уменьшения объёма анализируемого трафика существует другой набор фильтров – capture filter.

Capture filter настраивается в окне Wireshark: Capture Options. Фильтр захвата, не предоставляет той гибкости, которая есть у фильтров отображения, он предназначен для работы на «живом захвате» – для отбрасывания «неинтересного» трафика. Синтаксис capture filter идентичен синтаксису фильтров tcpdump. Например, вот такой фильтр:

host 10.1.1.1 or host 10.1.2.2

позволит захватить только тот трафик, который относится к указанным хостам. Использование capture filter крайне рекомендовано при анализе трафика с нагруженных систем. С помощью этих фильтров вы существенно снизите количество захваченных пакетов, а значит, ускорите работу фильтров отображения.

• Catalyst Switched Port Analyzer (SPAN) Configuration Example
• Wireshark Capture Filters

Ошибка кроется в обработке регистрации SIP аккаунтов. Существующие аккаунты и несуществующие обрабатываются по разному. Сделать это можно, с помощью специально составленного запроса REGISTER. Например, вот такого:

REGISTER SIP:192.168.0.22 SIP/2.0
From: 888888 <SIP:888888@192.168.0.1>;tag=123
To: 888888 <SIP:888888@192.168.0.1>
Call-ID: 321@192.168.0.22
CSeq: 111 REGISTER
Max-Forwards: 70
Contact: 888888 <SIP:888888@192.168.0.22:5060>;expires=60
Content-Length: 0
Allow: ACK, BYE
Supported: replaces

В данном запросе – 192.168.0.22 адрес компьютера, с которого производим проверку, 192.168.0.1 – адрес SIP сервера на котором проверяем наличие аккаунта, а 888888 – аккаунт, о наличие которого мы хотим знать. Теперь этот запрос можно записать в отдельный файл, например reg.txt и отправить с помощью замечательной утилиты sipsak:

sipsak -vv -f reg.txt -s SIP:999999@192.168.0.1

Здесь 192.168.0.1 – адрес сервера, куда будет отправлен наш запрос REGISTER, а 999999 – произвольное имя, которое будет использовано для авторизации. Главное что бы имя указанное в параметре к sipsak, не совпадало с именем указанным в теле запроса (999999 и 888888).

Из вывода sipsak, нас больше всего интересуют последние строчки:

** reply received 15.502 ms after first send
   and 2.089 ms after last send **
   SIP/2.0 403 Authentication user name does not match account name
   final received

Asterisk ответил ошибкой, пояснив, что имя пользователя не совпадает с именем, использованным для аутентификации. Это означает, что пользователь, указанный в теле запроса REGISTER (в нашем случае 888888) – существует на сервере.

В случае если искомый аккаунт отсутствует на сервере, ответ будет зависеть от опции

alwaysauthreject = yes

из файла SIP.conf. По умолчанию, сервер ответит с кодом 404:

** reply received after 3.053 ms **
   SIP/2.0 404 Not found
   final received

Если же опция включена, код ошибки заменится на 401.

На мой взгляд, ошибки подобного вида не представляют никакой опасности. Однако, если паранойя берёт верх вы можете смело обновиться до последних версий (1.2.35, 1.4.26.3). Обновлять ветку 1.6.0 до последней версии – я крайне не рекомендую. Дело в том, что текущий срез 1.6.0 абсолютно не пригоден для промышленного использования – сплошные дедлоки, сломанный T38 и т.п. Если у вас стабильный срез 1.6.0, то лучше наложить патч устраняющий проблему, избежав обновления среза.

• AST-2009-008
• AST-2009-008-1.6.0.diff

Лёгкость в установке и настройке Asterisk-a, привлекла большое количество низко квалифицированных IT-шников в сегмент IP-телефонии. Этим объясняются простые пароли для SIP логинов (или пароли, совпадающие с логином) и, соответственно, простота их подбора.

Наиболее заметными событиями в информационном поле стали: Публикация на сайте news.com.au о том, как маленькая Австралийская компания получила счёт на 120000$ после того как её корпоративную систему IP телефонии взломали и слили 11000 международных звонков за 46 часов и длиннющий тред в списке рассылки Asterisk-biz, начавшийся в начале февраля и закончившийся лишь к концу марта. Убыток во втором случае не столь впечатляющ, всего лишь 2000$. Однако последующее обсуждение имеет большую ценность.

Многие участники рассылки, используют программу fail2ban, которая умеет парсить лог-файлы различного формата и добавлять засветившиеся там IP адреса в iptables для блокирования. Подробную инструкцию как настроить Asterisk и fail2ban на совместную работу, можно прочитать здесь. Данная схема замечательна, заслуживают самого пристального внимания и оперативного внедрения. Однако я бы хотел обратить внимание на некоторые моменты:

Не доверяйте автоматике на 100%

Автоматической системе на основе fail2ban нельзя доверять на 100%. Дело в том, что использую SIP в Asterisk, мы используем протокол UDP. Реальность такова, что UDP пакеты с поддельным IP адресом отправителя без каких либо проблем проходят несколько автономных систем. Таким образом, автоматическая система на основе fail2ban может быть использована против Вас для отказа в обслуживании Ваших клиентов.

Автоматическую систему на основе fail2ban следует дополнить списком «белых» IP, которые будут игнорироваться при создании блокирующих правил iptables. Все результаты деятельности fail2ban следует регулярно проверять.

Сохраняйте IP адреса для каждого SIP звонка внутри CDR

Стандартные CDR Asterisk-а не содержат IP адреса, с которого был совершён звонок. Это легко исправить. Если Вы используете cdr_addon_mysql для хранения CDR в базе данных, добавьте поле в таблицу cdr:

ALTER TABLE cdr 
add COLUMN remote_signal_ip 
VARCHAR(16) NOT NULL DEFAULT ''

Теперь измените свой диалплан так, что бы cdr переменная remote_signal_ip инициализировалась перед исходящим звонком. Например, вот так:

context dialout {
    _X. => {
        Noop();
        Set(CDR(remote_signal_ip)=${SIPCHANINFO(recvip)});
        Dial(SIP/myprovider/${EXTEN});
    }
}

Вот и всё! Функция SIPCHANINFO(recvip) вернёт IP адрес, с которого клиент производит вызов, а по окончании вызова модуль cdr_addon_mysql сохранит все переменные, имена которых совпадают с названиями колонок в таблице cdr.

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

Используйте встроенные access-листы

chan_sip и некоторые другие модули сетевых протоколов имеют поддержку списков доступа в зачаточном состоянии. С помощью директив permit и deny вы можете ограничивать возможные IP адреса для каждого SIP аккаунта. Если у вас есть офисные номера, работающие в интранете, не ленитесь, пропишите для каждого аккаунта

deny=0.0.0.0/0.0.0.0
permit=192.168.1.0/255.255.255.0

Возможно, это спасёт Вас от судьбы той компании из Австралии.

Подходите к вопросу творчески: комбинируйте, изобретайте!

Не стоит сидеть, сложа руки и ждать, пока появятся проблемы. Лучше потратить немного усилий на превентивные меры, что бы обезопасить себя от форс-мажора. В вопросе безопасности, надо всегда быть на шаг впереди. Анализируйте свой трафик – каждый всплеск мг/мн трафика должен быть тщательно расследован. Не работайте по шаблонам – комбинируйте и изобретайте. Например, можно написать скрипт, который раз в месяц анализирует IP адреса из вашей таблицы cdr, и автоматически генерирует списки доступа (acess-list) для тех аккаунтов, чьи IP не менялись за прошедший месяц. Будьте креативными!

• Fail2ban
• Fail2Ban (with iptables) And Asterisk
• Small business gets $120,000 phone bill after hackers attack VoIP phone
• [asterisk-biz] PBX got Hacked

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

• AST-2009-002
• Diff of /branches/1.6.0/channels/chan_sip.c