История эта приключилась с одним крупным брендом, работающий на внутреннем рынке не самой маленькой южной страны бывшего СССР, назовём его просто — БРЕНД.
— Сеть построена на Cisco с небольшими вкраплениями из свичей и серверов от HP. VPNы до штаб-квартиры и удалённых офисов;
— Интернет по собственному оптоволокну от одного из ведущих провайдеров столицы;
— ISDN-телефония от другой тоже весьма известной международной компании. На эти номера привязана реклама, так что отказаться от них нельзя!
— Собственный штат IT-специалистов у БРЕНДа небольшой и постоянно задействован в решении текущих задач, поэтому активно пользуется услугами IT-аутсорсинга;
— Ежемесячные траты БРЕНДа только на услуги связи составляют около 3000$, что является у нас весьма неплохим показателем и выводит в VIP, и вроде бы всё было хорошо, но вдруг приходит счёт сначала на 20K$, а потом еще на 40К$.
И тут внезапно стало приходить понимание, что вечер уже перестаёт быть томным, а события начинают разворачиваться по классической схеме:
1. Поиск виноватых
2. Наказание невиновных
3. И награждение непричастных
Примерно за пару месяцев до истории, в связи с кризисом и с целью оптимизации расходов, было принято решение отказаться от ежемесячной поддержки IT-аутсорсера, а перейти на оплату по вызову.
В принципе решение является экономически выгодным, но вдруг в один из дней, поставщик телефонии, (получив в свою очередьпинок информацию от международного коммутатора гостелекома), сообщает БРЕНДу, что идёт необычно много звонков по неспецифичным ранее для него, направлениям (Куба, Нигерия и т.д.)
IT-департамент БРЕНДа, проверив биллинг на своей внутренней АТС, записей не обнаружил и, пожав плечами, сказал что у них всё нормально. Менеджер провайдера, зевнув, пошёл дальше заниматься своей рутиной.
И всё затихло опять примерно на месяц, пока не пришли счета, о которых говорилось в начале повествования.
IT-шники БРЕНДа поначалу заявили чтоя не я и корова не моя «так как во внутреннем биллинге записей нету, значит мы звонков не совершали и платить не будем», но потом изменили позицию на то, что раз среди условий получения телеком лицензии имеется обязательный пункт борьбы с фродом (что является правдой в нашей стране), то в возникновении счёта виноват сам провайдер телефонии, так что пусть он сам и оплачивает его.
Поставщик резонно возразил, что за состояние оборудование клиента он не отвечает, разговоры зафиксированы не только им, но и центром международной связи и однозначно осуществлялись со стороны клиента, так что предъявленный счёт необходимо оплатить клиенту.
Компания IT-аутсорсинга провела своё исследование и дала заключение что «оборудование клиента было взломано» и, хотя кем и когда совершено было сие противоправное деяние, установить они не могут «по причине отсутствия логов» но, злоумышленники, захватив права, «налили» на оборудование клиента голосовой международный VoIP трафик.
В качестве решения, БРЕНДу надо срочно! купить у них дополнительное оборудование, услуги на N-ую сумму, взять на работу ещё одного специалиста по безопасности и выработать правила по обнаружения таких ситуаций и т.д. и т.п.
Вообщем, как всегда, все старались свалить вину с себя и, если получится, нарубить бабла.
В правоохранительные органы, уже имея опыт, никто из сторон обращаться не захотел.
Осознав что все в одной лодке, провайдер согласился списать частично сумму за телефонные разговоры, исключив весь свой профит, но клиент настаивал на разделении и остаточной суммы поровну. Дело дошло до приглашения команды «боевых» юристов, которые, уже в свою очередь, позвали на переговоры своих технических специалистов (то есть нас).
Несколько совещаний всех заинтересованных сторон позволило выяснить что, по сути дела грамотный мониторинг событий отсутствует как данность и у клиента и у поставщиков услуг. Тикетная система у аутсорсера безвременно почила. Обсуждение SLA с любой из сторон вызываломысли о суициде стойкое ощущение что, никто из присутствующих, в том числе и нас, не понимает как это возможно обеспечивать и контролировать.
Ну что же, будем работать с тем что в наличии.
Как известно с незапамятных времён, у Cisco в реализации VoIP, по умолчанию имеется баг, позволяющий отправлять VoIP-трафик в PSTN просто указав номертелефонакудазвонить@адресциски и это необходимо закрывать соответствующими правилами через access-list.
Не став сильно вдаваться в юридические аспекты, просто чтобы убедиться в обратном, мы захотели ознакомиться с текущей конфигурацией сетевой инфраструктуры, и в процессе ознакомления, несмотря на уверения IT-аутсорсера в обратном, выяснилось, что логи и конфигурационные файлы все же собирались на сервере хранения данных.
Уже легче.
В первую очередь попросили самих аутсорсеров предоставить нам для анализа логи и файлы настроек взломанного оборудования, которое подверглось атаке.
Стали смотреть на предмет ошибок и вроде бы всё было верно, но тут обратили внимание на не состыковку дат между более поздними и более ранними файлами. Скажем выглядело это примерно так:
Ранний файл:
Поздний файл:
Кроме того, у обоих файлов в свойствах время создания и последнего изменения имели абсолютно одно и то же значение, что в принципе невозможно без внешнего вмешательства.
Заподозрив неладное, получили доступ к файлам уже непосредственно через начальника IT-департамента и на его ноутбуке, мы открыли сервер хранения данных.
Операционная система SUSE (это важно!)
Логи подтёрты, но вот разбор истории команд показал что пользователь под именем сотрудника аутсорсера, перед передачей файлов нам на исследование, вносил в них изменения. А также менял значения «время создания» и «время последней модификации» указанных файлов, заменив далее оригиналы на сервере своими переделками. После чего, видимо, чтобы стереть следы своих действий, удалил всё из директории /var/log/.
У SUSE есть одна интересная особенность по сохранению временных файлов, перед отправкой их на сервер TFTP. Всё описывать не буду, кто знает и так понимает, что имеется ввиду, другим рекомендую обратиться в Google. Так что приложив совсем незначительные усилия, мы получили оригиналы всех старых файлов конфигураций, которые нам открыли следующую картину:
У компании IT-аутсорсинга около года как сменился основной инженер по сопровождению клиента, а клиент как раз в то время решил сменить провайдера Интернет. В процессе настройки нового интерфейса сотрудник аутсорсера по какой-то причине оставил эту дыру открытой.
Хмм… почему-то с самого начала нам так и казалось. Далее, после того как уже пришёл счёт и выяснилась собственная ошибка, сотрудники стали «валять дурака» и попытались обмануть клиента. Грустно!
Экспертное заключение нашей компании с техническими и юридическими обоснованиями, а также слепок дисков сервера, с материалами для возможности возбуждения уголовного дела были выданы руководству БРЕНДа. Далее, руководство клиента пригласило руководство IT-аутсорсера, где им в глаза объяснили, что произошло и что им может за это быть.
Поначалу конечно же они сделали удивлённые лица, но через 2 дня, попросив подписать NDA, пообещали всё оплатить.
Так как руководство БРЕНДа, к своей чести, с самого начала заявляли, что они не ставят целью уголовное преследование, а лишь хотят выяснить, что произошло, и что надо сделать, чтобы предотвратить такое в будущем, то этот инцидент теперь считается исчерпанным.
Это был не первый и не самый значительный в денежном эквиваленте опыт нашего участия в расследовании IT-преступлений, но стоит помнить, что везде, где нету порядка в учёте, имеется огромное поле для воровства и обмана.
Ведь в принципе, если у аутсорсера стояла задача сымитировать преступление, и организовав саботаж, навязать свои услуги, то при грамотной организации они вполне могли бы добиться успеха. Поэтому считаем необходимым собирать логи действий всех администраторов и хранить их в недоступном для них месте. Например у начальника собственной Службы Безопасности. Не потому что ты не доверяешь, но чтобы потом в случае инцидента быть уверенными, что это не кто-то из твоих людей попытался тебя «кинуть». Это как сейф в доме, чтобы точно знать, что твои дети не причём, когда пропали деньги. Или же «чёрный ящик» на самолёте. Не потому, что мы не доверяем пилоту, а просто потому, что шит хэппенс!
Мы рекомендовали клиенту:
» Развернуть сервер сбора логов действий IT-администраторов с доступом только начальнику Службы Безопасности.
» Сервер мониторинга событий для инвентаризации оборудования, отслеживания состояния и контроля качества получаемых услуг (по SLA).
» Настроить способы и правила автоматического оповещения на триггеры возникновения нетипичных ситуаций.
Но об этом уже в следующих статьях, если будет вам интересно.
— Сеть построена на Cisco с небольшими вкраплениями из свичей и серверов от HP. VPNы до штаб-квартиры и удалённых офисов;
— Интернет по собственному оптоволокну от одного из ведущих провайдеров столицы;
— ISDN-телефония от другой тоже весьма известной международной компании. На эти номера привязана реклама, так что отказаться от них нельзя!
— Собственный штат IT-специалистов у БРЕНДа небольшой и постоянно задействован в решении текущих задач, поэтому активно пользуется услугами IT-аутсорсинга;
— Ежемесячные траты БРЕНДа только на услуги связи составляют около 3000$, что является у нас весьма неплохим показателем и выводит в VIP, и вроде бы всё было хорошо, но вдруг приходит счёт сначала на 20K$, а потом еще на 40К$.
И тут внезапно стало приходить понимание, что вечер уже перестаёт быть томным, а события начинают разворачиваться по классической схеме:
1. Поиск виноватых
2. Наказание невиновных
3. И награждение непричастных
Сама история
Примерно за пару месяцев до истории, в связи с кризисом и с целью оптимизации расходов, было принято решение отказаться от ежемесячной поддержки IT-аутсорсера, а перейти на оплату по вызову.
В принципе решение является экономически выгодным, но вдруг в один из дней, поставщик телефонии, (получив в свою очередь
IT-департамент БРЕНДа, проверив биллинг на своей внутренней АТС, записей не обнаружил и, пожав плечами, сказал что у них всё нормально. Менеджер провайдера, зевнув, пошёл дальше заниматься своей рутиной.
И всё затихло опять примерно на месяц, пока не пришли счета, о которых говорилось в начале повествования.
IT-шники БРЕНДа поначалу заявили что
Поставщик резонно возразил, что за состояние оборудование клиента он не отвечает, разговоры зафиксированы не только им, но и центром международной связи и однозначно осуществлялись со стороны клиента, так что предъявленный счёт необходимо оплатить клиенту.
Компания IT-аутсорсинга провела своё исследование и дала заключение что «оборудование клиента было взломано» и, хотя кем и когда совершено было сие противоправное деяние, установить они не могут «по причине отсутствия логов» но, злоумышленники, захватив права, «налили» на оборудование клиента голосовой международный VoIP трафик.
В качестве решения, БРЕНДу надо срочно! купить у них дополнительное оборудование, услуги на N-ую сумму, взять на работу ещё одного специалиста по безопасности и выработать правила по обнаружения таких ситуаций и т.д. и т.п.
Вообщем, как всегда, все старались свалить вину с себя и, если получится, нарубить бабла.
В правоохранительные органы, уже имея опыт, никто из сторон обращаться не захотел.
Тут необходимо пояснить: с учётом сложившейся на местах практики, обычно в таких случаях у нас выявляется какая статья УК нарушена и кто отвечает за данное поле деятельности у потерпевшего. Выносится приговор специалисту/руководителю потерпевшей стороны, поставщикам и причастным лицам, далее бюджет пополняется на сумму выписанных штрафов и дело считается успешно раскрытым. Разумеется что ни деньги, ни тем более, самих злоумышленников искать никто практически и не пытается.
Осознав что все в одной лодке, провайдер согласился списать частично сумму за телефонные разговоры, исключив весь свой профит, но клиент настаивал на разделении и остаточной суммы поровну. Дело дошло до приглашения команды «боевых» юристов, которые, уже в свою очередь, позвали на переговоры своих технических специалистов (то есть нас).
Несколько совещаний всех заинтересованных сторон позволило выяснить что, по сути дела грамотный мониторинг событий отсутствует как данность и у клиента и у поставщиков услуг. Тикетная система у аутсорсера безвременно почила. Обсуждение SLA с любой из сторон вызывало
Ну что же, будем работать с тем что в наличии.
Как известно с незапамятных времён, у Cisco в реализации VoIP, по умолчанию имеется баг, позволяющий отправлять VoIP-трафик в PSTN просто указав номертелефонакудазвонить@адресциски и это необходимо закрывать соответствующими правилами через access-list.
Не став сильно вдаваться в юридические аспекты, просто чтобы убедиться в обратном, мы захотели ознакомиться с текущей конфигурацией сетевой инфраструктуры, и в процессе ознакомления, несмотря на уверения IT-аутсорсера в обратном, выяснилось, что логи и конфигурационные файлы все же собирались на сервере хранения данных.
Уже легче.
В первую очередь попросили самих аутсорсеров предоставить нам для анализа логи и файлы настроек взломанного оборудования, которое подверглось атаке.
Стали смотреть на предмет ошибок и вроде бы всё было верно, но тут обратили внимание на не состыковку дат между более поздними и более ранними файлами. Скажем выглядело это примерно так:
Ранний файл:
! Last configuration change at 18:54:05 Tue Feb 10 2015 by ит@аутсорсер
!NVRAM config last updated at 19:02:08 Tue Feb 10 2015 by ит@аутсорсер
Поздний файл:
! Last configuration change at 13:38:58 Fri Jan 15 2016 by ит@аутсорсер
! NVRAM config last updated at 13:38:59 Fri Jan 15 2016 by ит@аутсорсер
Кроме того, у обоих файлов в свойствах время создания и последнего изменения имели абсолютно одно и то же значение, что в принципе невозможно без внешнего вмешательства.
Заподозрив неладное, получили доступ к файлам уже непосредственно через начальника IT-департамента и на его ноутбуке, мы открыли сервер хранения данных.
Операционная система SUSE (это важно!)
Логи подтёрты, но вот разбор истории команд показал что пользователь под именем сотрудника аутсорсера, перед передачей файлов нам на исследование, вносил в них изменения. А также менял значения «время создания» и «время последней модификации» указанных файлов, заменив далее оригиналы на сервере своими переделками. После чего, видимо, чтобы стереть следы своих действий, удалил всё из директории /var/log/.
У SUSE есть одна интересная особенность по сохранению временных файлов, перед отправкой их на сервер TFTP. Всё описывать не буду, кто знает и так понимает, что имеется ввиду, другим рекомендую обратиться в Google. Так что приложив совсем незначительные усилия, мы получили оригиналы всех старых файлов конфигураций, которые нам открыли следующую картину:
У компании IT-аутсорсинга около года как сменился основной инженер по сопровождению клиента, а клиент как раз в то время решил сменить провайдера Интернет. В процессе настройки нового интерфейса сотрудник аутсорсера по какой-то причине оставил эту дыру открытой.
Хмм… почему-то с самого начала нам так и казалось. Далее, после того как уже пришёл счёт и выяснилась собственная ошибка, сотрудники стали «валять дурака» и попытались обмануть клиента. Грустно!
Заключение
Экспертное заключение нашей компании с техническими и юридическими обоснованиями, а также слепок дисков сервера, с материалами для возможности возбуждения уголовного дела были выданы руководству БРЕНДа. Далее, руководство клиента пригласило руководство IT-аутсорсера, где им в глаза объяснили, что произошло и что им может за это быть.
Поначалу конечно же они сделали удивлённые лица, но через 2 дня, попросив подписать NDA, пообещали всё оплатить.
Так как руководство БРЕНДа, к своей чести, с самого начала заявляли, что они не ставят целью уголовное преследование, а лишь хотят выяснить, что произошло, и что надо сделать, чтобы предотвратить такое в будущем, то этот инцидент теперь считается исчерпанным.
Послесловие
Это был не первый и не самый значительный в денежном эквиваленте опыт нашего участия в расследовании IT-преступлений, но стоит помнить, что везде, где нету порядка в учёте, имеется огромное поле для воровства и обмана.
Ведь в принципе, если у аутсорсера стояла задача сымитировать преступление, и организовав саботаж, навязать свои услуги, то при грамотной организации они вполне могли бы добиться успеха. Поэтому считаем необходимым собирать логи действий всех администраторов и хранить их в недоступном для них месте. Например у начальника собственной Службы Безопасности. Не потому что ты не доверяешь, но чтобы потом в случае инцидента быть уверенными, что это не кто-то из твоих людей попытался тебя «кинуть». Это как сейф в доме, чтобы точно знать, что твои дети не причём, когда пропали деньги. Или же «чёрный ящик» на самолёте. Не потому, что мы не доверяем пилоту, а просто потому, что шит хэппенс!
Мы рекомендовали клиенту:
» Развернуть сервер сбора логов действий IT-администраторов с доступом только начальнику Службы Безопасности.
» Сервер мониторинга событий для инвентаризации оборудования, отслеживания состояния и контроля качества получаемых услуг (по SLA).
» Настроить способы и правила автоматического оповещения на триггеры возникновения нетипичных ситуаций.
Но об этом уже в следующих статьях, если будет вам интересно.
