Аббревиатура KSS расшифровывается как Kaspersky Subscription Service – Служба Подписок Касперского. Предназначение этой службы – распространение продуктов лаборатории Касперского с помощью подписок. Подписка, это когда вы единожды подписываетесь на услугу и забываете о ней, дальнейшая пролонгации происходит автоматически, пока на вашем счету (кредитная карта, аккаунт у провайдера и т.д.) не кончатся деньги или же пока вы не откажитесь от подписки. Подписка, это очень удобный и современный способ оплаты услуги, чья стоимость не меняется из месяца в месяц. Впервые о том, что таким способом можно приобретать лицензии на продукты Касперского я услышал в апреле 2010 года.

Ознакомившись с документацией я немного приуныл. Под видом технической документации софткей подсунул бумагу со своими хотелками, где самыми конкретными фразами были «будет реализовано», «появится возможность» и т.п. Забегая вперёд скажу, что унылость и документация софткея – идут друг с другом под руку. Даже если отбросить невероятное количество орфографических ошибок/опечаток, останется масса технических неточностей и, что самое смешное, описание того, чего нет в природе. Т.е. что-то подробно расписано в документации, а на практике этого нет. Бывают недокументированные фичи, а здесь, видимо, нереализованные :) По моим субъективным ощущениям, так называемая документация соответствует реализованному функционалу процентов на 50.

К февралю 2011 года хотелки материализовались в якобы работающую систему. Для обмена данными с софткеем необходимо с помощью openssl сгенерировать пару ключей (открытый/закрытый) которыми потом вы будите шифровать или подписывать данные. Так написано в документации. на самом деле можно только подписывать. Кроме того, Ваш сертификат может потеряться. Однажды в мае, на все запросы стал приходить один и тот же ответ – мол не авторизован по причине неверного сертификата. На все запросы Софткеевские технари отвечали в лучших традициях отечественной школы: «Мы ничего не меняли, ошибка где-то у Вас». Недолго думая предложил установить новый сертификат и форварднул письмо с оригинальным – от февраля – всё чудным образом заработало.

Проработало оно недолго, где-то через месяц после ввода в коммерческую эксплуатацию веб сервер Софткея перестал отвечать совсем – даже ошибкой на любые запросы. Здесь необходимо сделать отступление и рассказать как происходит обмен данными между сервером софткея и провайдером, интегрирующим у себя подписки. Провайдер посылает HTTP POST запрос, на который софткей формирует ответ. Ответ состоит из традиционных HTTP заголовков и XML документа после них. Перестав работать, веб сервер софткея выдавал ответ, оборванный на середине HTTP заголовка Date. При обращении в Софткей, технари, как это ни странно, не стали рассказывать что у них всё в порядке, а оперативно устранили проблему.

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

Вот так, со скрипом и скрежетом работает KSS – сервис подписок от Касперского. По стилю работы всё это очень напоминает Chronopay (Хронопей). Возможно, технической частью обоих проектов занимались одни и те же люди. Тем не менее от чистого сердца желаю Софткею улучшения сервиса подписок, реализации нереализованного функционала и повышение уровня общения технарей с клиентами (ну что бы исключить ответы в стиле «сам дурак») – затея то хорошая.

Арестовали Павла Олеговича на основании чисточердечного признания некоего Игоря Артимовича, утверждающего что он летом 2010 года положил ддос-ом платёжную систему Assist по заказу Врублёвского Павла Олеговича. Чем это может обернуться для законопослушных пользователей сети интернет?

Как можно судить по информации опубликованной в redeye-blog.com, в хронопее царит бардак и многое, если не всё, держится на Врублёвском. Если ситуация с арестом не разрешится быстро в его пользу, Хронопей может развалиться со всеми вытекающими последствиями. Теперь все транзакции через хронопей стоит рассматривать как крайне рискованные. Хотя может быть всё не так плохо, и друзья из единой россии не дадут пропасть?

Лично я не особо боюсь того, что к моей системе подберут пароль одного из клиентов. Вероятность данного события мала, поскольку все пароли в системе стойкие. И даже если пароль подберут, у большинства клиентов установлено ограничение на 1-2 одновременных вызова. Для меня неприятность SIP брутфорса заключается в другом. Дело в том, что в Asterisk вся SIP UDP сигнализация обрабатывается одним единственным тредом. Обработка SIP трафика – ресурсоёмкий процесс, 7-8 мегабит мусорных запросов заставляют Asterisk полностью скушать ядро процессора (например Intel E5335, E5405). Когда ядро полностью съедено, происходит вытеснение полезного SIP трафика – мусорным. Перестают работать DTMF у клиентов использующих SIP INFO. Начинаются проблемы с установкой новых и завершением существующих соединений. И вот это – основная угроза которую несут роботы-брутфорсеры.

Так как же бороться с проблемами о которых нет сообщений в логах? Очень просто – необходимо сгенерировать сообщение о проблеме самому, тогда всю остальную часть нашей системы противодействия (например программу fail2ban) можно будет оставить без изменений. Характерным признаком брутфорса является большое количество SIP пакетов в единицу времени. Посчитать количество пакетов в единицу времени можно с помощью модуля iptables под названием recent. В интернете есть много примеров как с помощью модуля recent отбрасывают пакеты приходящие с частотой выше определённой. Мы, вместо отбрасывания, будем генерировать сообщения для нашей системы обнаружения атак (например fail2ban). Такой подход имеет свои недостатки и преимущества. Основным недостатком является, то что на обработку сообщений будут тратиться ресурсы системы, тогда как отбрасывание пакета условно бесплатное. Преимуществ чуть больше: мы сможем воспользоваться всеми возможностями нашей системы обнаружения атак, такими как белые списки IP адресов, единообразный учёт всех обнаруженных атак и так далее.

От теории – к практике! Подготовим скелет из правил iptables:

-A INPUT -p udp --dport 5060 -j SCAMBLOCK
-A INPUT -p udp --dport 5060 -m recent --set --name SIP
-A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP \
-j LOG --log-prefix "SIP flood detected: "

Первое правило проверяет наш пакет по цепочке SCAMBLOCK. В данной цепочке хранятся заблокированные IP адреса, если пакет совпадает с одним из адресов этой цепочки – он отбрасывается. Если пакет не отброшен, то во втором правиле он помечается для учёта под именем SIP. Третье правило считает не превысил ли данный пакет указанное количество (60) за указанное время (2 секунды). Если количество не превышено – правило игнорируется, если превышено – выполняется действие. В нашем случае в системный лог пишется детальная информация о пакете начинающаяся со строки «SIP flood detected: «. Количество пакетов и время считаются отдельно для каждого источника. Таким образом получается, что мы ограничили скорость приёма SIP пакетов от каждого незаблокированного IP адреса на уровне 30 пакетов в секунду. Для меня данное ограничение является комфортным, с одной стороны все клиенты, даже самые крупнные, шлют пакеты с одного IP адреса со скоростями ниже 30 пакетов/с, с другой стороны, 30 пакетов в секунду практически не отражаютя на работе системы. Возможно, что эту величину следует подправлять в ту или иную сторону в зависимости от производительности сервера, количества и типа абонентов.

В некоторых системах встроенное ограничение модуля recent на параметр hitcount весьма небольшое, например в CentOS это ограничение составляет 20 пакетов. Если вы попробуете выполнить приведенную выше команду, то получите следующую ошибку:

iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP \
-j LOG --log-prefix "SIP flood detected: "
iptables: Unknown error 4294967295

Или вот так, для 64 битных систем:

iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP \
-j LOG --log-prefix "SIP flood detected: "
iptables: Unknown error 18446744073709551615

Изменить максимальное ограничение можно передав модулю recent специальный параметр при загрузке. Для этого создадим файл /etc/modprobe.d/ipt.conf и пропишем в нём интересующий нас параметр:

options ipt_recent ip_pkt_list_tot=60

Будьте осторожны увеличивая данное ограничение, помните что вместе с ним увеличивается память, требуемая для хранения последних пакетов, а также количество циклов процессора требуемые на их обработку.

Ну вот и всё, теперь любой флуд на порт 5060 будет обнаружен с помощью модуля recent пакета iptables. Сообщение об обнаруженном флуде будет направлено в системный лог где его сможет увидеть наша любимая система обнаружения атак (например fail2ban). iptables не ограничивает нас одним лишь системным логом, действию LOG можно указать уровень (level) и facility сообщения, а в настройках Syslog перенаправить данные сообщения в отдельный файл. Сами же сообщения о SIP флуде будут выглядеть вот так:

Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:7f:08:00 SRC=184.172.62.3 DST=192.168.224.217 LEN=370 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=350
Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:7f:08:00 SRC=184.172.62.3 DST=192.168.224.217 LEN=369 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=349
Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:7f:08:00 SRC=184.172.62.3 DST=192.168.224.217 LEN=370 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=350

Пока лента.ру была занята публикацией опровержения – в сети появился кусок дампа с кредитными картами, а некоторые пользователи – нашли среди них свои. Уважаемый мной аналитик – Эльдар Муртазин, склонен считать что на Хронопей ведётся информационная атака, Эльдар не верит в то, что Хронопей мог хранить у себя полные данные по кредитным картам. Детально изучив корявое API Chronopay, перечитав несколько раз документацию, переполненную опечатками, орфографическими и грамматическими ошибками заявляю: Хронопей, с большой долей вероятности, хранил все данные по картам с которых совершались платежи.

На последок не могу не сослаться на блог бывшего партнёра Врублёвского Павла – Гусева Игоря. Вот здесь Игорь перечисляет другие проекты своего партнёра: порнография, spyware, незаконная банковская деятельность, спам. Большинство этих проектов функционируют и сегодня. Кому мы доверяем свои деньги?

На мой взгляд, самое интересное в этом анонсе – технология с непонятным названием NFC (Near Field Communication) представленная под занавес. NFC это технология связи способная, помимо прочего, работать с RFID метками. Если внимательно присмотреться к ролику, то можно заметить, что с помощью мобильного телефона считывается метка mifare ultralight. Внедрение технологии NFC делает работу с метками mifare доступной любому обладателю телефона с Android. Если кто не в курсе, mifare очень любят в России транспортные компании. Различные версии mifare используются в бесконтактных проездных на метро, электрички, автобусы, троллейбусы и т.д. С появлением в широком доступе телефонов способных читать/писать метки mifare – можно ожидать всплеска интереса к генерации/клонированию транспортных карт.

Часть 1: Анонимности нет, смиритесь.

Главное что изменилось – больше ничего не удаляется, не стирается, и не забывается. Все что вы когда-либо сделали, каждый глупый фотоснимок, каждый злобный троллящий пост в блоге, каждое сообщение, написанное по пьяни, все хранится вечно. ВЕЧНО! Оно сохраняется, и не просто сохраняется. Оно индексируется, и связывается, и привязано к вашему имени навсегда.
…
Мне принадлежит peoplefinder.net. Я всасываю каждую страницу MySpace.com, каждую страницу Facebook, каждую ленту Twitter. На всякий случай, а вдруг вы поумнеете и решите их удалить. А фиг, не получится!
…
Мы нашли сообщение о том, как один чудак набухался, через несколько месяцев он вел машину в Техасе, выехал на встречную, и сбил кого-то. В больнице не сделали анализ на алкоголь, а он клялся, что он был трезв как стеклышко, и что-то случилось с его здоровьем, спазм артерий, что-то такое уже не помню, было два года назад. И мы нашли фото его пьянок, и обсуждение его друзей, где его называли конченым алканавтом, и он сел на восемь лет за убийство.

Часть 2: Мы гуглим Интернет а Гугл имеет НАС.

Слушайте, ребята. У Google есть свой чертов спутник. Скайнет!!! Я не параноик, я пользуюсь всей этой информацией для своих целей, и признаю что это двигатель капитализма. Google прекрасно справляется с тем, за что берется. В результате я купил акции Google. Пользуюсь кучей их продуктов. Но я должен вам сказать, Google всасывает все, что вы делаете. У Google достаточно RAM, не серверов, у Google сейчас, в их серверных фермах, достаточно RAM, чтобы сохранить всю информацию Сети. Подумайте об этом.
Это не преувеличение, я это не выдумал, это на самом деле так. Просто чтобы вы могли себе представить, насколько гигантская это компания. Они добавляют хранилища не дисками, не стойками, а комнатами, и планируют серверные фермы не в квадратных метрах, а в гектарах. Которые соединены их частной оптической сетью, их выделенными сетями, и питаются энергией от частных электростанций. Это Скайнет.
…
В 2006м, хотя мой доклад прервали, я говорил, что будет убийство, которое будет раскрыто благодаря Google. Так вот, жизнь преподнесла пример. Был человек, он пришел домой, и якобы сидел женой на кухне, несколько плохих людей в лыжных масках врываются в дом, он с ними борется, его ранят, убивают его жену, и убегают, он звонит 911. Ну, Боже благослови следователя из Флориды, который расследовал это дело, потому что он обнаружил, что несколько месяцев назад этот парень гуглил «травма вызываемая ранением в правую часть груди». Мистер Барбер был приговорен к смертной казни, и приговор принесен в исполнение. Вы – это то, что вы гуглили.

Как говорится: если вы не параноик, то это не значит что за вами не следят :)

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