Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Введение
Делая выбор в пользу подключения к SOC, компания, зачастую, рассматривает провайдера как «подстраховку» в работе со сложными инцидентами и угрозами, справиться с которыми своими силами для нее потенциально было бы затруднительно. При этом часто бывает, что уже на этапе пилотного тестирования сервиса проявляются узкие места или критичные недоработки в существующей стратегии обеспечения информационной устойчивости цифровых активов. Именно поэтому SOC – это совместный «путь», где компания и провайдер сервиса идут рука об руку, дополняя и помогая друг другу на всей дистанции.
Рис. 1. Распространенные слабые места у компаний
Мы накопили многолетний опыт по обеспечению информационной безопасности: как своей собственной, так и наших клиентов. И хотим им поделиться с читателями. В рамках этой статьи будут приведены несколько кейсов, успешно предотвращенных нашим коммерческим SOC. Из них можно извлечь для себя немало полезного.
Случай 1. «Прокси-обыкновенный»
Дежурным была зафиксирована сетевая атака с адреса 10.X.X.250 на хост 10.X.X.70 (Y.Y.ru)
Выяснилось, что на хосте 10.X.X.250 установлено ПО Kerio WinRoute Firewall. Со слов ответственного за эксплуатацию хоста это ПО использовалось исключительно как межсетевой экран. Сканирование хоста показало нам следующее:
На 443 порту комфортно расположился веб-интерфейс Kerio:
Рис. 2. Kerio, смотрящий прямо в душу
Однако не меньший интерес вызвал открытый порт 3128, на котором работал http-proxy. В продолжении проверки было установлено, что, используя прокси 10.X.X.250:3128, был возможен выход в интернет без необходимости ввода учетных данных. Выход в интернет при этом осуществлялся с внешним IP 89.X.X.18. Сканирование внешнего ip-адреса показало доступность:
3128/tcp – порт прокси сервера Kerio WinRoute Firewall.
Для этого сервиса оказалось частично возможно использование метода Connect:
Итог: через прокси на порту 3128/tcp возможен доступ из сети интернет во внутреннюю сеть компании.
31415/TCP – работа сервиса ПО mrelayd
github.com/thinkberg/jta/blob/master/tools/mrelayd.c
Принцип работы mrelayd похож на telnet-proxy. Для указания адреса подключения используется метод «relay», который указывается в виде строки вида: «relay targethost targetport».
Например:
Для проксирования ssh подключения в этом случае можно использовать опцию ProхyCommand (openssh) или опции подключения в Putty.
Итог: есть возможность доступа к внутренней сети, в том числе по управляющим протоколам.
Данный пример иллюстрирует, несмотря на свою кажущуюся простоту, важность правильной конфигурации прокси-сервера в компании. Ведь в противном случае информационное воздействие на внутренние цифровые активы возможно даже при отсутствии уязвимых служб на сетевом периметре и исключая вариации атак с перебором данных аутентификации протоколов удаленного управления.
Случай 2. Роутер, который смог (на самом деле – нет)
В ходе пилотного проекта внимание специалистов центра оперативного мониторинга привлек доступный из сети интернет веб-интерфейс сетевого оборудования. Пароль по умолчанию не подошёл, но в надежде на звериное везение была предпринята попытка подбора пароля из 6-ти символов к учетной записи admin.
Рис. 3. Выглядит легко доступным (использование дефолтных учётных записей)
Попытка увенчалась успехом, что позволило продолжить изыскания. В перечне интерфейсов, кроме всего прочего, был замечен «пациент» с типом «PPTP client», а в его настройках были заботливо указаны учетные данные для подключения к хосту во внутренней сети компании.
Было осуществлено успешное подключение с найденными учетными данными и определён внешний IP адрес устройства
Сканирование внешнего IP показало наличие портов, ассоциирующихся с майнингом криптовалют (что является признаком возможной компрометации системы). Кроме того, интерес привлек сервис на порту 5000/tcp. На злополучном 5000/tcp расположился уязвимый сервис, позволяющий запуск произвольных скриптов.
Пример эксплуатации:
Рис. 4. Запущенный через web-интерфейс ping на внутренние сервисы
Рис. 5. Вывод файла /etc/shadow
Казалось бы, этого уже более чем достаточно, но в рамках дальнейшей проверки было установлено, что запущенный сервис мониторинга Cacti на 79/tcp использовал пароль доступа по умолчанию.
Рис. 6. Устройства на мониторинге
Факт доступа к Cacti позволял также получить информацию о сборе логов и SNMP community:
Данный пример в очередной раз поднимает вопрос об уже набившей оскомину проблеме использования учетных данных для доступа к системам, не отвечающим парольной политике, принятой в компании.
Случай 3. Пентест vs SOC
Хорошим тоном для компаний в рамках тестирования SOC MTС всё чаще является совмещение пилотного проекта сервиса с регулярным аудитом информационных систем в формате пентест.
Современный SOC обладает возможностью обнаружить в соответствии с SLA как факты первоначальной компрометации системы, так и дальнейшие попытки потенциального «злоумышленника» закрепиться в системе, повысить привилегии и развить атаку на хосты уже внутри корпоративной сети. Для этого соответствующим образом настраиваются политики аудита Windows/Unix систем заказчика, иные имеющиеся СЗИ. Собранные события безопасности проходят обработку, исходя из разработанных правил корреляции, что позволяет аналитику SOC эффективно детектировать возможные инциденты и осуществлять на них реагирование.
Рис. 7. Для рядового пентестера первый раунд «противодействия» с SOC заканчивается очень быстро
Уже после, путём уступок, закрывая глаза на активность подрядчика, клиенты предлагают нанятым специалистам по пентесту продолжить работу. Это ещё раз подчеркивает эффективность SOC — мы сразу вычисляем деятельность пентестеров, нанятых компанией для проверки защищённости инфраструктуры. Вопрос об эффективности и целесообразности использования SOC отпадает сразу.
Ниже приведён короткий кейс с одной из компаний:
Как можно заметить, все действия «злоумышленника», включая момент его изначального подключения к сети, были выявлены и представлены компании.
Была выявлена компрометация аккаунта, IP-адрес потенциального злоумышленника, факт установки пентестером вредоносных служб на хостах заказчика. В случае реального инцидента всей собранной информации было бы более чем достаточно для соответствующего реагирования и защиты цифровых активов компании.
И в качестве заключения
Хочется отметить, что описание реальных кейсов SOC как ничто другое должно позволить компаниям понять важность и целесообразность использования подобного сервиса.
Грамотная настройка сбора событий безопасности, их анализ, написание подходящих для компании правил корреляции, обогащение событий ИБ по средствам платформ киберразведки в проекции на реальные инциденты — дают возможность понять и оценить будущую эффективность от подключения к SOC провайдера.
Нужно всерьез понимать, что отдельные инструменты ИБ обеспечивают защиту от частных угроз, однако, не дают полного представления о том, что происходит «на границе». SOC, объединяя квалифицированных специалистов, инновационные технологии и выстроенные процессы, обеспечивает всестороннюю защиту организации от киберугроз в режиме реального времени.
Например, в рамках SOC МТС мы согласовываем с заказчиками итоговый перечень подключаемых систем-источников и правил корреляции. Вместе с защищаемой компанией подключаемся по организованному и предоставленному заказчиком туннелю доступа к системам-источникам, настраиваем защищённое соединение между ними, сервером сбора логов компании и системой SOC с целью передачи логов с систем-источников, передачу логов на сервер сбора логов компании и с него в систему SOC в режиме реального времени.
Рис. 8. Схема подключения заказчика к SOC провайдера
Команда SOC совместно с сотрудниками компании адаптирует правила выявления инцидентов ИБ, проводит профилирование сетевой и хостовой активности для минимизации ложных срабатываний. Дополнительными возможностями могут быть контроль уязвимостей внешнего периметра и расследования инцидентов ИБ.
По итогам расследования инцидентов формируется отчёт о проделанной работе. Команда SOC, помимо анализа инцидента и установления системы-источника и причин, формирует набор технических рекомендаций, позволяющих предотвратить или снизить вероятность возникновения аналогичных инцидентов в дальнейшем.
Авторы статьи:
Старший эксперт SOC МТС Дмитрий Берковец и руководитель направления по продуктам ИБ провайдера #CloudMTS Александр Карпузиков.
Вакансии
Если вы хотите присоединиться к команде #CloudMTS, то у нас открылись новые вакансии:
Сетевой инженер
UI/UX Дизайнер
Golang developer
DevOps engineer
Делая выбор в пользу подключения к SOC, компания, зачастую, рассматривает провайдера как «подстраховку» в работе со сложными инцидентами и угрозами, справиться с которыми своими силами для нее потенциально было бы затруднительно. При этом часто бывает, что уже на этапе пилотного тестирования сервиса проявляются узкие места или критичные недоработки в существующей стратегии обеспечения информационной устойчивости цифровых активов. Именно поэтому SOC – это совместный «путь», где компания и провайдер сервиса идут рука об руку, дополняя и помогая друг другу на всей дистанции.
Рис. 1. Распространенные слабые места у компаний
Мы накопили многолетний опыт по обеспечению информационной безопасности: как своей собственной, так и наших клиентов. И хотим им поделиться с читателями. В рамках этой статьи будут приведены несколько кейсов, успешно предотвращенных нашим коммерческим SOC. Из них можно извлечь для себя немало полезного.
Случай 1. «Прокси-обыкновенный»
Дежурным была зафиксирована сетевая атака с адреса 10.X.X.250 на хост 10.X.X.70 (Y.Y.ru)
Выяснилось, что на хосте 10.X.X.250 установлено ПО Kerio WinRoute Firewall. Со слов ответственного за эксплуатацию хоста это ПО использовалось исключительно как межсетевой экран. Сканирование хоста показало нам следующее:
На 443 порту комфортно расположился веб-интерфейс Kerio:
Рис. 2. Kerio, смотрящий прямо в душу
Однако не меньший интерес вызвал открытый порт 3128, на котором работал http-proxy. В продолжении проверки было установлено, что, используя прокси 10.X.X.250:3128, был возможен выход в интернет без необходимости ввода учетных данных. Выход в интернет при этом осуществлялся с внешним IP 89.X.X.18. Сканирование внешнего ip-адреса показало доступность:
3128/tcp – порт прокси сервера Kerio WinRoute Firewall.
Для этого сервиса оказалось частично возможно использование метода Connect:
Итог: через прокси на порту 3128/tcp возможен доступ из сети интернет во внутреннюю сеть компании.
31415/TCP – работа сервиса ПО mrelayd
github.com/thinkberg/jta/blob/master/tools/mrelayd.c
Принцип работы mrelayd похож на telnet-proxy. Для указания адреса подключения используется метод «relay», который указывается в виде строки вида: «relay targethost targetport».
Например:
Для проксирования ssh подключения в этом случае можно использовать опцию ProхyCommand (openssh) или опции подключения в Putty.
Итог: есть возможность доступа к внутренней сети, в том числе по управляющим протоколам.
Данный пример иллюстрирует, несмотря на свою кажущуюся простоту, важность правильной конфигурации прокси-сервера в компании. Ведь в противном случае информационное воздействие на внутренние цифровые активы возможно даже при отсутствии уязвимых служб на сетевом периметре и исключая вариации атак с перебором данных аутентификации протоколов удаленного управления.
Случай 2. Роутер, который смог (на самом деле – нет)
В ходе пилотного проекта внимание специалистов центра оперативного мониторинга привлек доступный из сети интернет веб-интерфейс сетевого оборудования. Пароль по умолчанию не подошёл, но в надежде на звериное везение была предпринята попытка подбора пароля из 6-ти символов к учетной записи admin.
Рис. 3. Выглядит легко доступным (использование дефолтных учётных записей)
Попытка увенчалась успехом, что позволило продолжить изыскания. В перечне интерфейсов, кроме всего прочего, был замечен «пациент» с типом «PPTP client», а в его настройках были заботливо указаны учетные данные для подключения к хосту во внутренней сети компании.
Было осуществлено успешное подключение с найденными учетными данными и определён внешний IP адрес устройства
Сканирование внешнего IP показало наличие портов, ассоциирующихся с майнингом криптовалют (что является признаком возможной компрометации системы). Кроме того, интерес привлек сервис на порту 5000/tcp. На злополучном 5000/tcp расположился уязвимый сервис, позволяющий запуск произвольных скриптов.
Пример эксплуатации:
Рис. 4. Запущенный через web-интерфейс ping на внутренние сервисы
Рис. 5. Вывод файла /etc/shadow
Казалось бы, этого уже более чем достаточно, но в рамках дальнейшей проверки было установлено, что запущенный сервис мониторинга Cacti на 79/tcp использовал пароль доступа по умолчанию.
Рис. 6. Устройства на мониторинге
Факт доступа к Cacti позволял также получить информацию о сборе логов и SNMP community:
Данный пример в очередной раз поднимает вопрос об уже набившей оскомину проблеме использования учетных данных для доступа к системам, не отвечающим парольной политике, принятой в компании.
Случай 3. Пентест vs SOC
Хорошим тоном для компаний в рамках тестирования SOC MTС всё чаще является совмещение пилотного проекта сервиса с регулярным аудитом информационных систем в формате пентест.
Современный SOC обладает возможностью обнаружить в соответствии с SLA как факты первоначальной компрометации системы, так и дальнейшие попытки потенциального «злоумышленника» закрепиться в системе, повысить привилегии и развить атаку на хосты уже внутри корпоративной сети. Для этого соответствующим образом настраиваются политики аудита Windows/Unix систем заказчика, иные имеющиеся СЗИ. Собранные события безопасности проходят обработку, исходя из разработанных правил корреляции, что позволяет аналитику SOC эффективно детектировать возможные инциденты и осуществлять на них реагирование.
Рис. 7. Для рядового пентестера первый раунд «противодействия» с SOC заканчивается очень быстро
Уже после, путём уступок, закрывая глаза на активность подрядчика, клиенты предлагают нанятым специалистам по пентесту продолжить работу. Это ещё раз подчеркивает эффективность SOC — мы сразу вычисляем деятельность пентестеров, нанятых компанией для проверки защищённости инфраструктуры. Вопрос об эффективности и целесообразности использования SOC отпадает сразу.
Ниже приведён короткий кейс с одной из компаний:
Как можно заметить, все действия «злоумышленника», включая момент его изначального подключения к сети, были выявлены и представлены компании.
Была выявлена компрометация аккаунта, IP-адрес потенциального злоумышленника, факт установки пентестером вредоносных служб на хостах заказчика. В случае реального инцидента всей собранной информации было бы более чем достаточно для соответствующего реагирования и защиты цифровых активов компании.
И в качестве заключения
Хочется отметить, что описание реальных кейсов SOC как ничто другое должно позволить компаниям понять важность и целесообразность использования подобного сервиса.
Грамотная настройка сбора событий безопасности, их анализ, написание подходящих для компании правил корреляции, обогащение событий ИБ по средствам платформ киберразведки в проекции на реальные инциденты — дают возможность понять и оценить будущую эффективность от подключения к SOC провайдера.
Нужно всерьез понимать, что отдельные инструменты ИБ обеспечивают защиту от частных угроз, однако, не дают полного представления о том, что происходит «на границе». SOC, объединяя квалифицированных специалистов, инновационные технологии и выстроенные процессы, обеспечивает всестороннюю защиту организации от киберугроз в режиме реального времени.
Например, в рамках SOC МТС мы согласовываем с заказчиками итоговый перечень подключаемых систем-источников и правил корреляции. Вместе с защищаемой компанией подключаемся по организованному и предоставленному заказчиком туннелю доступа к системам-источникам, настраиваем защищённое соединение между ними, сервером сбора логов компании и системой SOC с целью передачи логов с систем-источников, передачу логов на сервер сбора логов компании и с него в систему SOC в режиме реального времени.
Рис. 8. Схема подключения заказчика к SOC провайдера
Команда SOC совместно с сотрудниками компании адаптирует правила выявления инцидентов ИБ, проводит профилирование сетевой и хостовой активности для минимизации ложных срабатываний. Дополнительными возможностями могут быть контроль уязвимостей внешнего периметра и расследования инцидентов ИБ.
По итогам расследования инцидентов формируется отчёт о проделанной работе. Команда SOC, помимо анализа инцидента и установления системы-источника и причин, формирует набор технических рекомендаций, позволяющих предотвратить или снизить вероятность возникновения аналогичных инцидентов в дальнейшем.
Авторы статьи:
Старший эксперт SOC МТС Дмитрий Берковец и руководитель направления по продуктам ИБ провайдера #CloudMTS Александр Карпузиков.
Вакансии
Если вы хотите присоединиться к команде #CloudMTS, то у нас открылись новые вакансии:
Сетевой инженер
UI/UX Дизайнер
Golang developer
DevOps engineer
