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

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

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

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

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

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

Пока не работал сервер Oracle, соответственно не работала исходящая связь, т.к. Mera не могла авторизовать заонки. Так же стали отваливаться регистрации. Но самое интересное началось тогда, когда сервер Oracle поднялся через пару часов – исходящая связь так и не заработала, проблемы с авторизацией – остались. После нескольких дней (!) размышлений, служба технической поддержки Mera выдала ответ, ради которого, собственно, и написан весь этот текст :) Далее позволю себе процитировать:

Мера v1.3 не рассчитана на такой шквал одновременных запросов авторизации. Ее максимум 7-10, а было ~85. Предлагают резать фаерволом сети и открывать по очереди.

Т.е. на выставке мы вроде-бы и энтерпрайз, а вот на деле – не пробуйте включать больше 7-10 клиентов разом – устанете фаервол перенастраивать. Будь у знакомых Asterisk – всё сложилось бы иначе (с)

В качестве исходных данных были взяты CDR трёх Российских операторов связи, предоставляющих возможность подключиться к ТФОП по протоколу SIP. CDR были взяты за период с 1 ноября 2009 года по 1 ноября 2010 года. Исходные данные были подвергнуты простейшей обработке – агрегации. Так, например, записи содержащие в Useragent значения CUCM, Cisco-CCM4.1, Cisco-CCM5.1 – были объединены под общим названием CUCM/Cisco Call Manager, различные версии оборудования Linksys – Linksys/SPA1001-3.1.19(SE), Linksys/SPA8000-6.1.3 и прочие – под общим названием Linksys и так далее.

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

По оси Х отложены % от Совокупного трафика. Кому недостаточно картинки, тот может посмотреть на конкретные цифры:

Серьёзные пацаны на ЛОРе решают – дорос ли Asterisk до ентерпрайза или нет, и на сколько далёк он ещё от CUCM/Cisco Call Manager, а тем временем, этот самый недорощенный Asterisk забрал на себя 42% трафика, а значит реальных денег. Богато представлено оборудование под названием Linksys – российские пользователи IP телефонии по достоинству оценили высокое качество при минимальной цене. Судя по тому что в двадцатку попал T38Modem – каждый 150ый звонок совершаемые в России по IP телефонии – это отправка спама по факсу :) Удивил чрезвычайно низкий процент трафика приходящийся на оборудование D-Link. Судя по частоте упоминания в рунете, железки D-Link должны встречаться на порядок чаще оборудования Linksys. Вероятно голосовые шлюзы D-Link, в отличие от Linksys, предназначены не для передачи голоса по IP, а для общения в соответствующих форумах :)

Классическая операция получения данных из MySQL выглядит следующим образом:

snprintf(sqlcmd, sizeof(sqlcmd) - 1,
        "select n.id,n.name,n.ip,n.port,n.capacity,COUNT(c.node) 
         from cluster_nodes n left join active_calls c on (n.name=c.node) 
         where online=1 group by n.name");
sql_cmd.s = sqlcmd;
sql_cmd.len = strlen(sqlcmd);
LOG(L_DBG, "Trying to execute SQL: '%s'\n", sqlcmd);
fres = dbf.raw_query(db_handle, &sql_cmd, &res);
if (fres == 0) {
        total = RES_ROW_N(res);
        if (total > 0) {
                for(i = 0; i < total; i++) {
                        node = shm_malloc(sizeof(struct ci_li_node));
                        if (node == NULL) {
                                LM_ERR("Could not allocate shared memory\n");
                                return -1;
                        }
                        node->id = RES_ROWS(res)[i].values[0].val.int_val;
                        node->calls_init = RES_ROWS(res)[i].values[5].val.int_val;
                        node->calls_current = node->calls_init;
                        node->calls_max = RES_ROWS(res)[i].values[4].val.int_val;
                        node->port = RES_ROWS(res)[i].values[3].val.int_val;
                        snprintf(node->name, sizeof(node->name), "%s", 
                                (char*)RES_ROWS(res)[i].values[1].val.str_val.s);
                        snprintf(node->ip, sizeof(node->ip), "%s", 
                                (char*)RES_ROWS(res)[i].values[2].val.str_val.s);
                        node->next = NULL;
 
                        total_max += node->calls_max;
                        if (mylist->last == NULL) {
                                mylist->last = node;
                                mylist->first = node;
                        } else {
                                mylist->last->next = node;
                                mylist->last = node;
                        }
                }
                LOG(L_DBG, "PRELOAD TOTAL: [servers] %d items = %lu bytes.\n", 
                        i, i * sizeof(struct ci_li_node));
                mylist->dt = time(NULL);
        }       
        dbf.free_result(db_handle, res);
}

Как видим из простого примера, получение данных из MySQL сводится к трём действиям:

1. Отправляем SQL запрос с помощью команды raw_query.
2. Читаем результаты с помощью макросов RES_ROW_N и RES_ROWS
3. Подчищаем за собой память с помощью free_result

Пока мы действуем по шаблону – всё отлично работает.

Но стоит нам захотеть чего то большего – и подход придётся менять. Например приведенным выше кодом нельзя загрузить за раз большую таблицу (тысячи записей). Прокладочные интерфейсы БД и памяти – накладываются друг на друга и возникают интересные эффекты. Дело в том, что при попытке загрузить большую таблицу целиком – db_mysql выделяет память под неё – одним куском. С другой стороны, pkg_free не освобождает память моментально, а лишь помечает её как готовую к очистке. Всё это приводит к тому, что загрузка большой таблицы срабатывает 2 раза подряд, а на третий возникает ошибка – недостаточно памяти.

Зачем загружать всю таблицу целиком – спросите вы? Вариантов может быть очень много – самый распространённый, пожалуй, – для того, что бы закешировать данные из БД. На одной СУБД далеко не уедешь, даже на такой быстрой как MySQL. Итак, что же нужно сделать для того, что бы обойти проблемы с памятью? Ответ очень простой: нужно воспользоваться вызовом fetch_result. К сожалению, применение этого вызова не расписано в KAMAILIO (OPENSER) Devel Guide, но, как известно, лучшая документация это исходный код. С практикой применения этого вызова можно ознакомиться в модулях Kamailio:

[root@sipproxy kamailio-3.0.3]# grep -l fetch_result */*/*.c
...
modules_k/dialog/dlg_db_handler.c
modules_k/drouting/dr_load.c
modules_k/htable/ht_db.c
modules_k/pdt/pdt.c
...

Вызов fetch_result позволяет указать сколько строк мы хотим поместить в память. Таким образом, вызывая fetch_result в цикле – мы обработаем все строки возвращённые базой данных по порциям. Если вы планируете использовать fetch_result самостоятельно, необходимо передать NULL в качестве указателя db_res_t** _r у функций raw_query(…) и query(…). Для наглядности, рассмотрим похожий кусок кода, написанный с использованием вызова fetch_result. Параметр ci_preload_chunk задаёт количество строк загружаемых в память за 1 вызов:

snprintf(sqlcmd, sizeof(sqlcmd) - 1,
        "select name,owner from sip where host='dynamic' and owner>0"
);
sql_cmd.s = sqlcmd;
sql_cmd.len = strlen(sqlcmd);
LOG(L_DBG, "Trying to execute SQL: '%s'\n", sqlcmd);
fres = dbf.raw_query(db_handle, &sql_cmd, NULL);
if (fres == 0) {
        LOG(L_DBG, "Trying to fetch first %d items.\n", ci_preload_chunk);
        if (dbf.fetch_result(db_handle, &res, ci_preload_chunk) < 0) {
                LM_ERR("Error while fetching result\n");
                if (res) {
                        dbf.free_result(db_handle, res);
                }
                return 0;
        }       
        total = RES_ROW_N(res);
        LOG(L_DBG, "%d first items fetched.\n", total);
        if (total > 0) {
                do {
                        for(i = 0; i < total; i++) {
                                row = RES_ROWS(res) + i;
                                u = shm_malloc(sizeof(struct ci_li_sipuser));
                                if (u == NULL) {
                                        LM_ERR("Could not allocate shared memory\n");
                                        return -1;
                                }       
                                u->sipaccount = atoi((char*)VAL_STRING(ROW_VALUES(row)));
                                u->customer = VAL_INT(ROW_VALUES(row) + 1);
                                u->next = NULL;
                                if (mylist->last == NULL) {
                                        mylist->last = u;
                                        mylist->first = u;
                                } else {
                                        mylist->last->next = u;
                                        mylist->last = u;
                                }
                                mylist->elements++;
                                cnt++;
                        }
                        if (dbf.fetch_result(db_handle, &res, ci_preload_chunk) < 0) {
                                LM_ERR("Error while fetching result\n");
                                if (res) {
                                        dbf.free_result(db_handle, res);
                                }
                                return 0;
                        }
                        total = RES_ROW_N(res);
                } while (total > 0);
                dbf.free_result(db_handle, res);
        }
}

Более подробную информацию и тарифы можно получить на сайте услуги.

• Минимизация отклонений от стандартной конфигурации Asterisk-realtime.
• Вся аутентификация — внутри Kamailio.
• Все звонки, в т.ч. и локальные — проходят через Asterisk.
• Все media потоки — проходят через Asterisk.
• Обработка SIP сообщений не связанных со звонками выполняется с помощью Kamailio.

Согласно предложенной схеме, регистрация выглядит следующим образом:

Аппарат А, отправляет запрос REGISTER и после успешной аутентификации регистрируется на Kamailio. Kamailio регистрируется на сервере Asterisk от имени клиента, указав в качестве котакта свой IP адрес. Таким образом при звонке с Asterisk к абоненту A, Asterisk отправит INVITE к Kamailio, а тот в свою очередь передаст его клиенту. Кстати о звонках, звонок между абонентами A и B выглядит следующим образом:

Для установки соединения между аппаратами A и B, аппарат A отправляет запрос INVITE по IP адресу сервера Kamailio. После успешной аутентификации, Kamailio отправляет INVITE к Asterisk. Asterisk, отправляет INVITE к абоненту B, однако в качестве контакта для абонента B указан IP адрес Kamailio. Получив INVITE от Asterisk для абонента B, Kamailio проверяет базу зарегистрированных пользователей (usrloc) и пытается перенаправить INVITE для абонента B по его фактическому адресу.

На мой взгляд: просто, элегантно, и, самое главное, масштабируемо. Я обычно использую несколько иную балансировку нагрузки, однако предложенная схема заслуживает самого тщательного изучения. Автор документа, Daniel-Constantin Mierla, обещает регулярно обновлять инструкцию, поддерживая её в актуальном состоянии.

1. Voice Over Internet Protocol Providers (VoIP) +179035%
2. Search Engines +1656%
3. eCommerce & Online Auctions +469%
4. Online Dating & Matchmaking +249%
5. Tank & Armored Vehicle Manufacturing +245%
6. Petrochemical Manufacturing +221%
7. Mining Support +187%
8. Wireless Telecommunications Carriers +183%
9. Biotechnology +182%
10. Warehouse Clubs and Supercenters +147%

Рынок VoIP вырос за 10 лет в 1790 раз! Это почти в 1000 раз больше роста рынка танков и броневиков. На первый взгляд, рост в +179035% выглядит подозрительно. Сразу же вспоминается VNIX с его ростом +2421,84 %. С другой стороны, вспомним ситуацию в 1999-2000 годах: операторов связи можно было пересчитать по пальцам одной руки, а их клиентов – по пальцам другой. Качество интернета вообще и «последней мили» в частности – было большой преградой для повсеместного внедрения IP телефонии. Сегодня, мы имеем качественно иную ситуацию. Широкополосный интернет есть везде, даже в России. А появление новых инструментов для IP-телефонии (в первую очередь Asterisk) позволило стать оператором связи – любому студенту :) Вероятней всего, большой рост рынка VoIP обусловлен эффектом мизерной базы. Вряд ли компания IBISWorld, функционирующая с 1971 года, позволит себе допустить ошибку в несложных расчётах.

Другой интересный нюанс, на который я хотел бы обратить внимание – структура десятки лидеров. Половина десятки это IT рынки, причём первая половина. Рост IT рынков существенно опережает рост рынков реального сектора экономики. Исследование никак не объясняет этот момент. Хочется верить что это, так же как и в случае с VoIP – лишь проявление эффекта малой базы, а не предвестие очередного пузыря доткомов.

• IBISWorld
• VoIP Named As Fastest Growing Technology Of The Past Decade

Не получилось и у талантливого программиста Jeremy McNamara, создателя chan_h323, основателя компании Nufone. В мае этого года он в очередной раз объявил о закрытии своей компании Nufone и приурочил к этому событию серию заметок «How Not To Do Business» первая из которых называется «How The Hell Happened To NuFone?» Но обо всём по порядку.

В 2002 году, работая инженером в VoIP компании штат Мичиган, Джереми предложил своему работодателю использовать Asterisk в качестве универсальной платформы предоставления услуг. По его словам, на тот момент в компании был зоопарк из разнородного оборудования: Cisco, Clarent и собственных разработок на базе Dialogic. Asterisk был отвергнут, только из-за того что он OpenSource.

Сразу после релиза Asterisk-oh323, Джереми вновь предложил работодателю использовать Asterisk. На этот раз дело дошло до тестов, однако реализация протокола H323 была очень слаба и Asterisk был снова отвергнут. Не смотря на провал попыток внедрить Asterisk у себя на работе, Джереми продолжил «играться» с ним, в свободное от работы время. Попытки исправить Asterisk-oh323 натолкнулись на нежелание автора вносить какие-либо чужие изменения в свой код. Тогда, за одни выходные, Джерими написал первый работоспособный вариант chan_h323, было это в январе 2003 года.

Проводя большое количество времени в Asterisk сообществе (IRC, список рассылки и т.д.). Джереми заметил, что существует большой неудовлетворенный спрос на «Asterisk-friendly» провайдеров. На этот раз он предложил своему работодателю партнёрскую схему: колокейшен, электричество и PRI в обмен на любые настройки и консультации по Asterisk. Работодатель не устоял и сдался под натиском Джереми. Так появился nufone.

Первый сервер был обычным компьютером, с чужой Zaptel/DAHDI картой на 4 потока без каких либо отказоустойчивых/дублированных подсистем. Более года аккаунты заводились вручную в текстовом файле. С появлением «портала», в июне 2004 года, где пользователи могли регистрироваться самостоятельно, рост клиентской базы и трафика получил взрывной характер. За несколько дней были выбраны все 4 имевшихся потока, и срочно понадобилось расширение. По словам Джереми, «Nufone рос быстрее, чем желал расти вышестоящий оператор». За полтора года деятельности Джереми из наёмного работника превратился в крупнейшего клиента. Вероятно, вышестоящего оператора не устраивала маржа получаемая с Nufone, поэтому у Джереми начались неприятности.

Первой ласточкой было письмо о якобы неоплаченном счёте на 125 000 $. На основании этого письма, оборудование Nufone (тот самый суперсервер) выключали несколько раз. Не сложно представить, что такое для телефонной компании, отключение на 5 минут. Это колоссальный удар по репутации. Последнее отключение продлилось несколько дней. Это, фактически, была первая (клиническая :) ) смерть nufone.

Во время вынужденного простоя, Джереми сумел оперативно переехать на колокейшен к другому оператору. На этом увлекательное повествование заканчивается, Джереми обещал продолжить рассказ, но прошло уже пол года, а продолжения пока нет.

Возвращаясь к тому, с чего я начал: невозможно стать хорошим бизнесменом в одно мгновение. Бизнес это не только успешные продажи, бизнес, в первую очередь, это план развития. Успешно начав, можно потерять всё, только потому, что инфраструктура не будет успевать за клиентской базой. Не стоит так же забывать про организованность и порядок, про хороший – здоровый педантизм. Нельзя заниматься бизнесом с бардаком в голове, есть риск остаться без головы :) .

В общем случае система мониторинга состоит из 3х частей: сбор данных, обработка и уведомления. К слову, Nagios использует именно это концепцию, дополняя её разнообразными удобствами (визуальное отображение, расписания и т.д.). Уведомление по электронной почте, первое, что приходит в голову, однако оно не всегда оперативное. Самым оперативным уведомлением на сегодня является SMS сообщение. Отправку SMS сообщений можно организовать «на коленке» с помощью мобильного телефона подключенного к серверу.

Большинство телефонов представляют собой модем, к которому можно подключиться через интерфейс RS-232 (COM порт). Основным отличием мобильного телефона от обычного модема является поддержка расширенных AT команд. Эти команды используются для управления функциями специфичными для мобильного телефона, например, приёмом и отправкой коротких сообщений (SMS).

Традиционно считается, что для отправки SMS с ПК лучше всего подходят мобильные телефоны Siemens. Для реализации мобильных уведомлений, я запасся несколькими моделями: парочкой ME45 и одним A50. Первая неудача с телефонами Siemens ждала меня на этапе подсоединения к ПК. Оказывается, не все дата-кабели одинаковые.

Вот, этот например, определялся телефоном как гарнитура, и имел большое количество распаянных контактов внутри. Однако соединение по RS-232 установить с таким кабелем невозможно. Конечно, нельзя исключать, что мне попался бракованный экземпляр, но, как говорится, осадок то остался.

А вот так выглядит правильный дата-кабель доработанный мной. GND, RX, TX – все что нужно для работы по RS-232. Однако после доработки кабеля всплыла вторая проблема с телефонами Siemens. Все аппараты, имевшиеся у меня, выключались вскоре после того как аккумулятор был полностью заряжен. Т.е. их невозможно было эксплуатировать постоянно подключенными к сети. Вероятно это такой способ защиты аккумуляторов. Списать это на случайность не получится при всём желании.

В принципе, на этом можно было и остановить некрофильские эксперименты с аппаратурой фирмы Siemens, однако совесть потребовала идти до конца. Как я уже писал выше, для приёма и отправки текстовых сообщений через GSM модем используется специальный набор AT команд. Подробней об этом наборе можно почитать здесь. В общем случае отправка SMS выглядит вот так:

# picocom /dev/ttyS0
AT
OK
AT+CMGF=1
OK
AT+CMGS="+85291234567"
It is easy to send text messages.^Z

Если телефон поддерживает текстовый режим отправки SMS, или вот так:

# picocom /dev/ttyS0
AT
OK
AT+CMGS=42
07915892000000F0
01000B9158922143
65F7000021493A28
3D0795C3F33C88FE
06CDCB6E32885EC6
D341EDF27C1E3E97
E72E^Z

- если текстовый режим телефоном не поддерживается. Для активации текстового режима используется команда AT+CMGF=1, чтобы узнать, какие режимы поддерживаются Вашим телефоном, следует выполнить команду AT+CMGF=?.

Как вы уже догадались, третья проблема с телефонами Siemens заключалась в том, что ни один из имевшихся телефонов не поддерживал текстовый режим. Работая с PDU режимом Вы вынуждены генерировать сложную структуру содержащую в себе множество разнообразных параметров. Для работы с данной структурой Вам придётся либо изобрести велосипед и написать собственное API либо воспользоваться одной из существующих библиотек/программ (gsmlib, xgsmlib, Gammu и т.д.). Лучшим вариантом, на мой взгляд, является программа Gnokii

Намучавшись с сименсами, я решил опробовать устройство, которое изначально было бы рассчитано на постоянное использование в паре с ПК. Выбор мой пал на GSM/GPRS модем Teleofis RX201 (USB EDGE).

Приобрел я этот девайс за 3700 рублей, дороговато, по сравнению с рекламируемыми GPRS модемами от БиЛайн/Мегафон/МТС. По заверениям производителя (ООО КБ «Телеофис»), устройство произведено в России – мелочь, а приятно.

При подключении к ПК с linux, устройство определяется как «USB FTDI Serial Converter». Соответствующий модуль (ftdi_sio) автоматически создаёт файл устройства /dev/ttyUSBN. Этот файл вы можете использовать для связи с модемом, с помощью вашего любимого терминала (например picocom). Хочу обратить внимание на то, что устройство RX201 по умолчанию рассчитано на скорость 460800 кб/сек. Драйвер, идущий с Fedora 10 (ftdi_sio: v1.4.3) такую скорость не поддерживает. Что бы понизить скорость на модеме, к нему необходимо подключиться из альтернативной ОС и выполнить команду AT+IPR=115200&W.

Модем Teleofis RX201 отлично подружился с программой gnokii. Для отсылки sms с помощью gnokii сперва необходимо изменить конфигурационный файл /etc/gnokiirc. Вот пример рабочего конфига:

[global]
port = /dev/ttyUSB0
model = AT
initlength = default
connection = serial
use_locking = no
serial_baudrate = 115200

Обратите внимание на параметр use_locking, если Вы собираетесь рассылать SMS из Nagios, следует использовать use_locking = yes, что бы избежать конфликтов при рассылке уведомлений нескольким адресатам. Отправляется SMS очень просто:

echo 'ya sms-ko !' | gnokii --sendsms +79260000000

Вот и всё! SMS с текстом ‘ya sms-ko !’ будет отправлена на номер +79260000000.

Модем Teleofis RX201 работает уже почти месяц. В среднем в сутки отправляется около 10 сообщений. Никаких претензий и нареканий за этот небольшой срок не возникло, однако настораживает наличие модели Teleofis RX201-R единственное отличие которой – встроенный таймер перезагрузки.

• Nagios
• Short Message Service / SMS Tutorial
• Gnokii
• ООО КБ «Телеофис»

Лёгкость в установке и настройке 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