Каждый безопасник в своей жизни сталкивался с тем, что сотрудники ходят в Интернет, минуя прокси, качают фильмы через торрент и пользуются TeamViewer'ом. В этом посте мы немного расскажем о том, как решаем проблемы с организацией безопасного доступа в Интернет по сервисной модели и поделимся адскими кейсами, с которыми сталкиваемся у заказчиков.
Не так давно мы рассказывали про архитектуру Единой платформы сервисов кибербезопасности (ЕПСК), которая является ядром экосистемы управляемых сервисов кибербезопасности Solar MSS. ЕПСК включает и сервис по защите от сетевых угроз — Unified Threat Management (UTM).
У каждого производителя UTM свой набор функций. У нас он следующий:
- межсетевой экран;
- система предотвращения вторжений;
- сетевой антивирус;
- фильтрация веб-трафика;
- контроль использования приложений.
Часто бывает так (особенно это характерно для банков или ритейла), что у компании есть головной офис, в котором информационная безопасность находится на более-менее приемлемом уровне, а еще есть филиальная сеть, где все не так просто. В каждом офисе свой системный администратор и свои погремушки. И за защиту всей этой инфраструктуры отвечает один безопасник. Ну, или ИБ-департамент, но, так или иначе, — удаленные специалисты.
Здесь обычно возникают следующие проблемы: во-первых, надо как-то контролировать действия каждого удаленного системного администратора. Во-вторых, что даже более важно, надо каким-то образом раскатить на все филиалы единые настройки средств защиты, а потом проверять, что они обновляются корректно и быстро. Многие безопасники в такой ситуации также довольно быстро приходят к идее централизовать для всех филиалов выход в интернет, что тоже весьма непросто. Для этого нужно установить связность между всеми филиалами и головным офисом (или ЦОД) и направить весь трафик с периферии в центр. Это довольно дорого, плюс, остаются не решенными первый и второй вопросы.
Наша бизнес-модель строится на том, чтобы предложить решение всех этих задач сразу. Мы организуем связность площадок заказчика через платформу виртуализованных сервисов ИБ. В итоге весь трафик из офисов в интернет и обратно идет через UTM.
Таким образом мы получаем централизованный выход в интернет, единые настройки на все филиалы и единую точку управления средством защиты информации. Это гарантирует, что не возникнет ситуаций, когда системный администратор один раз открыл порты удаленного администрирования и забыл их закрыть, а потом через них взломали компанию. Параллельно это решает задачу объединения филиалов организации в единую КСПД (про «плюшки» технологии SD-WAN мы уже говорили ранее).
Дополнительно такой подход помогает снизить риски использования запрещенных в компании приложений. Обычно после подключения заказчика к платформе мы в первую очередь смотрим на самые популярные приложения и оцениваем, сколько трафика они потребляют. Это позволяет оперативно выявить использование средств для удаленного администрирования, торрентов, хакерских утилит и пиратского ПО.
Майнил-майнил, да не вымайнил
В одной из организаций мы выявили системного администратора, который использовал Kryptex — парень майнил,
Вообще я не слежу за курсами криптовалют, но, судя по всему, они снова на подъеме – в последнее время мы опять стали часто сталкиваться с кейсами, когда администраторы пытаются майнить на корпоративных серверах.
Лейтесь, файлы
Пример из другой оперы. Мы подключили к платформе очередного заказчика, который официально разрешал всем своим администраторам использовать TeamViewer. Вообще-то мы не приветствуем такую практику, но она сейчас встречается повсеместно, да и, в общем-то, наше дело — предупредить. И вот в какой-то момент мы видим, что к рабочей станции одного из админов раз в сутки устанавливается подключение через малоизвестное средство удаленного администрирования Splashtop.
Оповестили заказчика — как и ожидалось, действия не были санкционированы. Посмотрели сессии с хоста: оказалось, что в момент запуска Splashtop устанавливается соединение с внешним файлообменником, куда передается порядка 500 МБ. К сожалению, логирование на хосте настроено не было, поэтому быстро установить причину инцидента не удалось. Стали анализировать жесткие диски и обнаружили индикатор компрометации — хэш одного из файлов, занесенных в нашу базу Threat Intelligence. Этим файлом оказалась утилита PassView, которая используется для извлечения скрытых паролей. Антивирус определил ее просто как нежелательное ПО (not a virus) и не произвел никаких действий. А в сборке этой утилиты оказалось средство удаленного администрирования — Splashtop.
Из-за отсутствия логов неизвестно, как долго злоумышленник находился в инфраструктуре, но при последнем соединении из компании «ушли» многие внутренние документы, в том числе с грифом «ДСП».
Псевдоадмин местного разлива
По нашим данным, около 50% всех внутренних инцидентов ИБ — это именно утечки конфиденциальной информации. Надо сказать, за свою многолетнюю практику мы сталкивались с огромным количеством внутренних нарушений. Часто их выявление — это фактически поиск иголки в стоге сена: в условиях малого количества источников информации приходится решать множество рутинных задач, В UTM же с утечками помогает бороться модуль фильтрации веб-траффика. Так можно выявлять и/или блокировать обращения к файлообменникам.
У одного из наших заказчиков администраторам было разрешено пользоваться файлообменниками, а остальным сотрудникам — нет. При составлении отчета мы обратили внимание на то, что один из администраторов выгружает на внешние ресурсы гораздо больше информации, чем остальные. Сообщили заказчику — его данный факт немало удивил. Администратор утверждал, что вообще не пользовался файлообменником в этом месяце.
Стали анализировать логи UTM и увидели, что под учетной записью администратора происходит аутентификация с двух разных хостов. Один из пользователей украл пароль администратора и без ограничений выгружал чувствительные для организации данные. Вычислить пользователя не предоставляло труда: он заходил под учеткой админа и под своей собственной с одного и того же хоста.
Под присмотром Solar JSOC
Таки да, было бы глупо отказываться от уже имеющихся наработок, поэтому платформа ЕПСК максимально использует опыт и знания нашего SOC — например, в части сбора и агрегации информации по угрозам. Это здорово помогает выявлять и предотвращать различные инциденты.
Так, на этапе пилотного подключения у одного из заказчиков благодаря нашей базе индикаторов компрометации, накопленной в рамках расследований, мы обнаружили, что некоторые хосты обращаются к IP-адресам, которые принадлежат хакерской группировке Cobalt.
Изучили эти хосты— выяснилось, что на них больше года (всего-то!) не обновлялись антивирусные сигнатуры и машины заражены трояном. К счастью, это был не банк, поэтому компанию спасло только то, что они были банально не интересны злоумышленникам.
Другая компания пришла к нам на пилот из-за проблем со своим межсетевым экраном. Каждые два дня он «падал» без объявления войны. Точную проблему заказчик выявить не смог — предположил, что виной всему объемы трафика. Но, так как денег на новый межсетевой экран нет, решили рассмотреть вариант перехода на сервисную модель.
В первые 10 минут после подключения к нашей платформе мы увидели интересную и одновременно ужасную картину: четыре хоста организации сканируют весь Интернет по 445, 22, 3389 портам, а еще с них идут обращения к известным C&C-серверам.
Заказчика сразу же уведомили, хосты заблокировали. В ходе разбирательств выяснилось, что они принадлежат специалистам подрядчика, которые ведут какие-то работы на площадке заказчика и используют при этом свои личные ноутбуки, зараженные самым разнообразным вредоносным ПО. Если бы с публичных IP-адресов заказчика произошла атака, это было бы, мягко говоря, неслабым репутационным ударом.
Артем Кильдюшев, группа экспертного пресэйла продуктов и сервисов Solar JSOC
Комментарии (23)
Revertis
10.10.2019 13:03Интересно, вот если есть сеть, в которой прокси явно не задаётся, но доступ к внешним портам запрещён, то каким лучше инструментом проверить, какие порты разрешены?
Например, разрешены TCP-коннекты на 22,80,443, это точно. А есть какие-то UDP порты, которые обычно разрешают?
SolarSecurity Автор
10.10.2019 18:21+1Каждая компания для себя сама определяет список разрешенных портов, в зависимости от нужд персонала и сервисов компании.
Revertis
10.10.2019 18:56А есть что-нибудь часто используемое?
slonopotamus
10.10.2019 21:16UDP 53 (DNS)?
Revertis
10.10.2019 21:25Это первое, что приходит на ум. Но его часто принудительно заворачивают на свои сервера. А что есть ещё?
slonopotamus
10.10.2019 21:51Из часто используемого UDP еще приходит в голову NTP. И кажется всё. Дальше начинаются экзотические частные случаи. Допустим, мне по работе было необходимо поиграть в CS:GO. И понеслась.
Revertis
10.10.2019 13:12В UTM же с утечками помогает бороться модуль фильтрации веб-траффика. Так можно выявлять и/или блокировать обращения к файлообменникам.
Когда у юзера есть домашний Nextcloud, на него можно выложить хоть всю организацию :)
PyerK
10.10.2019 17:44Помнится когдато давным давно сильно сильно надо было скопировать файлы, а был только порезанный по фунционалу RDP. Задача решилась за 40 минут 5ю программистами. Написали 2 программы, одна рисовала части многотомного архива на экране, другая парсила их на стороне клиента и склеивала. Из проблем была только искаженная цветопередача. Потом рассказали заказчикам, они очень удивлялись нашей находчивости. Сильно не ругали, за что мы им еще с десяток способов для утечки придумали.
Вряд ли таким или подобным утечкам можно чтото противопоставить даже чисто теоретически.
SolarSecurity Автор
10.10.2019 18:22Для этого есть модуль контроля использования приложений, с помощью которого можно сформировать белые списки и который не допустит использование неразрешенных приложений.
Revertis
10.10.2019 18:47Так дело не в приложении. Заходим через веб-интерфейс на свой домен, там установлен Nextcloud, и туда в браузер перетаскиваем файлы. Никаких проблем.
Revertis
10.10.2019 13:16Майнер был установлен на тестовом сервере и потому оставался незамеченным, пока заказчик не подключил свою инфраструктуру к нашей платформе.
Значит, надо ставить obfsproxy, понятно :)
whyme
10.10.2019 16:50В примерах статьи нужно менять системных администраторов, а не только обвешиваться системами контроля. Даже в маленьких компаниях до 20 человек я обычно настраиваю на клиентских устройствах фаерволы, если на винде то стандартные виндовые через GPO, в том числе на исходящий трафик. Любые невнесенные в правила приложения не получат доступ в интернет. Опять же для винды через GPO вешаются software restriction policies по сертификатам/путям, не одобренные приложения не только не получать доступ в интернет, но и не запустятся. Настройка занимает прилично времени, зато потом можно спать спокойно, лет 10 уже не ловил ни одного вируса/шифровальщика ни в одной из компаний, которые обслуживаю, так же могу быть уверен что ни одно приложение не будет запущено/установлено без моего ведома.
SolarSecurity Автор
10.10.2019 18:24Повезло тем компаниям, в которых Вы являетесь системным администратором. Но все же есть масса нюансов, например, недоменные пользователи, или в компании разрешено использование собственных компьютеров. Если взять компании больше 300 человек, ходить по каждому пользователю и проверять/настраивать их компьютеры уйдет слишком много времени, которого как правило нет, да и использование белых списков в таких компаниях не практикуется, всегда есть сотрудники, например, разработчики, которым необходимо огромное количество различного софта.
whyme
11.10.2019 17:27Да, я работаю в основном с небольшими компаниями, есть на 150 человек. Настраивать можно гибко, естественно, что у всех свои нюансы.
Если взять компании больше 300 человек, ходить по каждому пользователю и проверять/настраивать их компьютеры уйдет слишком много времени, которого как правило нет
Оставить без контроля 300 компьютеров, они через пару месяцев превратятся в ботнет, вы больше времени потратите на устранение проблем/восстановление от шифровальщиков, чем на настройку. У каждого, конечно, свои случаи, но наверняка в этой сети стоит AD/LDAP, а с ними что 30, что 300, разница не очень небольшая.
На разные группы пользователей вешают разные политики ограничений, а не всем одно и то же, для тех, для кого критично — все строго, для остальных, к примеру, разработчиков менее строгие политики ограничений.
Не обязательно прямо белые списки, можно просто запретить запуск исполняемых из профиля пользователя, все остальное оставить разрешенным, к примеру софт ставят админы на местах, даже если они не настраивают SRP (в случае windows), они ставят программы в Program Files, и эти программы без проблем будут работать. Т.е. корпоративный teamviewer установленный администратором будет работать, а teamviewer/вирус который запускает пользователь из профиля — нет (права обычных пользователей, да и для рабочих аккаунтов админов, ограничены, нет записи в системные папки типа Program Files). Для разъездных/недоменных настраиваются локальные политики, создается локальный администратор, в случае необходимости пароль выдается пользователю, он ставит все что нужно, потом приезжает, компьютер проверяется, пароль локального админа меняется. В случае, когда свои компьютеры, мне предложить тут нечего — останутся без ограничений, но и отвественность за них я не несу в этом случае, раз руководство готово на такие риски, ничего не поделать.
Как я уже упоминал настройка занимает время, SRP включается вначале в режиме логгирования, т.е. Вы уже пишите правила, но они не блокируют ничего, а просто логгируют. Вы просматриваете логи, составляете группы, заодно видите кто и что запускает «запрещенного». Если разработчикам нельзя составить правила по сертификатам или указать директорию, из который они могут запускать свои бинари, то тогда правила для них не включаются, тут уже да, желательно повесить какую-то систему контроля.
В общем я не предлагаю прямо для всех применять строгие белые фильтры наподобие SRP в windows, я просто указываю на то, что они прекрасно работают вместе с системами контроля и настолько упрощают работу как системным администраторам так и безопасникам, что не использовать этот удобный инструмент, там где возможно, просто халатность, а в Ваших примерах в статье очень сильно на это похоже. Админ у которого украли пароль, вообще что-то невообразимое.
slonopotamus
10.10.2019 21:21не одобренные приложения не только не получать доступ в интернет, но и не запустятся.
Расскажите, как в таких условиях работают программисты? После каждого нажатия "Compile" бегут к вам получать разрешение на запуск получившегося бинаря? А как ограничивается запуск интерпретируемых языков?
sergey-b
13.10.2019 01:52Тоже придерживаюсь таких правил. Однако на винде столкнулся с массой проблем. Вот например. Запускаю git clone. Он ругается Permission Denied. Причем не везде, а на определенных репозиториях. На все известные мне бинарники гита есть правила с разрешениями. В каталоге 263 exe-файла. Как понять какой из них не может установить соединение с сервером? Пришлось отключить файервол. И такая ерунда происходит постоянно. Например, при обновлении браузеров.
teecat
11.10.2019 16:50Антивирус определил ее просто как нежелательное ПО (not a virus) и не произвел никаких действий
Типовая проблема, не настраиваются действия антивируса на потенциально опасное ПО (программы удаленного действия теже)
Andrey_Rogovsky
У вашей системы есть недостаток — она замечает вещи постфактум. Нормальные системы имеют uba/euba.
Без этого — только постмортемы писать.
ANosarev
Насколько мне известно, ни одна ueba\uba система не обладает предсказывающими алгоритмами. Хотя как бы они могли работать — вообще загадка, разве что экстраполировать текущий тренд в будущее с большей или меньшей точностью.
Таким образом, они точно также базируют свой анализ на уже случившихся, собранных сборщиком и обработанных системой событиях. Никакой дополнительной магии они в описанный в статье процесс не принесут, разве что упростят процесс threat hunting-а.
SolarSecurity Автор
Статья касается тематики ЕПСК, а используемые там технологии как раз блокируют вредоносные действия. Но, помимо простой блокировки, даже UTM даёт возможности для большой аналитики, о чем мы и пытались рассказать/
Технологии UBA достаточно полезны, но пока лежат за рамками ЕПСК, хотя частично применяются в нашем SOC и активно используются в нашем DLP.