Как не надо защищать свои системы в облаке24.03.2020 10:33

anr88ju9vtr97gbe1rhoz3yhfmm.jpeg

Часто, когда я говорю кому-то про уязвимость, на меня смотрят как на сумасшедшего с табличкой «Покайтесь, ибо конец света близок»!

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

Как обнесли сервер


Стоял сервер в дата-центре. Олдскульный такой, железный, безо всяких модных контейнеров и виртуализации. Несколько поколений сотрудников назад кто-то из разработчиков сконфигурировал его «временно, чтобы только несколько крупных файлов для проекта принять». Компания при этом на самом деле очень заботилась об информационной безопасности, но, как это часто бывает, коллеги из ИБ пошли навстречу нуждам бизнеса и согласовали временный вариант с полноценным выходом в интернет.

К счастью, сервер находился в серой зоне DMZ и не мог подключаться напрямую к критичным сервисам внутреннего контура. Наружу выставили 22-й порт, а внутри просто добавили несколько локальных пользователей с индивидуальными паролями для входа по ssh/sftp. Доступ по сертификатам посчитали слишком неудобным. Потом прибежали разработчики из другого проекта и попросили помочь автоматизировать регулярные выгрузки с сервера контрагентов, ведь «у вас есть удобный сервер с согласованным выходом в сеть». Потом ещё.

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

Решили поставить на мониторинг, раз уж сервер такой важный, и в графиках CPU сразу полкой на 100%. Полезли разбираться:, а там куча процессов rand от имени подозрительного пользователя test и куча сожранной ими памяти, а в логах непрерывный брутфорс со всего света.

Перед преданием сервера забвению потыкали в процессы палочкой: lsof сразу показал удалённые, но незакрытые файлы, которые ещё висели в оперативной памяти. К сожалению, точно понять, что делал злоумышленник не получилось, но поведение было похоже скорее на человека, чем на отработку скрипта. При обследовании висевшего в RAM скрипта очень порадовали вставки вроде scanez clasa (сканирую класс) на румынском языке: 

#!/bin/bash
while["1"];do
class="
#168
"
classb="`seq 1 255`"
classb2=($classb)
num_classb=${#classb2[*]}
b=${classb2[$((RANDOM%num_classb))]}
classc="`seq 1 255`"
classc2=($classc)
num_classc=${#classc2[*]}
c=${classc2[$((RANDOM%num_classc))]}
classes=($class)
num_class=${#classes[*]}
a=${classes[$((RANDOM%num_class))]}
echo "scanez clasa ${a}.${b}"
./a ${a}.${c}
done


Насколько мне известно, ничего серьёзного не утекло (или мне про это не рассказали) и во внутренний периметр атакующему попасть не получилось, но с тех пор в компании ходит история о цыганских хакерах-конокрадах.

Правила


  1. Не позволяйте временным удобным, но небезопасным решениям закрепляться в инфраструктуре. Да, я знаю, что они непостоянные, а только перетерпеть карантин, но просто договаривайтесь, когда вы их будете убирать. Через сколько дней или часов. И убирайте не откладывая. Ну хотя бы проговаривайте это окружающим, пожалуйста. Ведь выставленный наружу сервис начинают ломать в среднем через 20 минут.
  2. Не показывайте ssh и чистый RDP наружу, лучше предоставляйте доступ через VPN или сервисы web-туннелирования. Уж не знаю почему, но для них люди ответственнее подходят к набору разрешённых учётных записей и их паролям.
  3. Если уж открыли ssh — запретите вход по паролю. Используйте ключи. А лучше вообще не используйте пароли для ssh, даже для внутренних сервисов.
  4. Если у вас всё-таки пароли — ограничивайте брутфорс чем-то вроде fail2ban, иначе велик риск, что чей-то простой пароль переберут. И вопрос взлома перейдёт из плоскости «если» в плоскость «когда». И не забывайте, что современные алгоритмы позволяют подобрать большинство паролей за несколько часов. Решите, наконец, для себя, что если вы не ограничиваете брутфорс — пароля нет.
  5. Если ни одна из вышеприведённых рекомендаций вам не подходит, то обязательно задайте себе вопрос: «А что здесь вообще может пойти так?» и переходите к следующему пункту.
  6. В случае компрометации уничтожайте и перезаливайте с нуля машины. Никогда не пробуйте их вычищать от руткитов. А все данные, хранящиеся и проходящие через сервер, считайте утёкшими.


Публичные IP — это так удобно, а firewall мешает!


Я прекрасно понимаю, что NAT был необходимым костылём, который портил жизнь разработчикам и не давал реализовывать варианты быстрого подключения узлов между собой. Тем не менее его побочный эффект от сокрытия внутренней структуры сети весьма полезен с точки зрения усложнения обычной автоматизированной атаки. И да, я отлично понимаю, что наиболее правильным вариантом является использование firewall, работающего по белому списку, чтобы явно разрешить только необходимые соединения. Проблема в том, что в мире непрерывного аджайла на такие мелочи как жёсткое конфигурирование firewall или не дай бог SELinux никогда нет времени и бюджета. И вообще, они мешают отладке, снижают критический показатель time-to-market и не дают спокойно жить разработчикам и девопсам.

Ситуация стала ещё интереснее, когда облачная инфраструктура, развёртываемая автоматически по требованию, стала отраслевым стандартом. Дело в том, что большинство облачных решений предполагают, что защита вороха из поднятых контейнеров и виртуальных машин лежит на конечном пользователе. Как правило, вам предоставляют инфраструктуру, выделяют белые IP-адреса и на этом всё, по сути, дают набор возможностей, а не готовые решения. По умолчанию всё закрыто, но это же неудобно и так мешает разработке. Поэтому давайте всё откроем и будем спокойно тестировать, а на продакшене уже сделаем как положено.

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

Оказалось, что вся инфраструктура, включая фронтенд, бэкенд и базу данных, просто торчали открытыми портами во внешний мир. А какой самый вероятный пароль у пользователя sa если БД доступна всему интернету? Правильно, тоже sa! В итоге самое сложное это разобраться со структурой таблиц.

Похожая история была с одним заказчиком, который открыл себе удалённый доступ к админской панели для домашней машины, на время пока работает из дома. Естественно, что админская панель была без авторизации, так как считалась безопасным внутренним ресурсом. А заказчик не стал заморачиваться и просто открыл порт для всего интернета сразу.

А открытые всему миру ELK-серверы всплывают каждую неделю. Чего только не находят в их содержимом. Начиная от личных данных, заканчивая номерами кредиток.

Правила


  1. Firewall должен работать по белому списку. Бэкенд ни в коем случае не должен быть доступен извне. И не стесняйтесь спросить подрядчиков и удалённых сотрудников с какого IP они будут подключаться. В конце концов, выделенный IP стоит около 150 р/мес., это вполне посильная трата для возможности работать из дома.
  2. Всегда используйте HTTPS и полноценную аутентификацию, даже если это «всего лишь» тестовые машины.
  3. Жёстко разделяйте тестовое и продуктивное окружение. Никогда, совсем никогда, не используйте одинаковые учётные записи в обоих окружениях.


Samba


Особенно часто меня радует Samba-сервер, который традиционно используется для организации совместного доступа к ресурсам. Почему бы не настроить гостевой доступ для коллег из соседнего отдела, чтобы удобно меняться файлами?

В небольшой компании всё шло неплохо, пока отделов не стало больше. Через какое-то время потребовалось настроить доступ к удалённым филиалам. И вполне «разумным» решением было открыть доступ к samba извне. Ну у всех же свои пароли, что может пойти не так? Про гостевой доступ никто не вспоминал, пока не выяснилось, что ощутимая часть HDD забита чьими-то данными. Автоматические сканеры быстро нащупали бесплатное файлохранилище, и HDD начали быстро забиваться чьими-то шифрованными архивами. А ещё в одном из каталогов мы обнаружили при аудите коллекцию отборных фильмов для взрослых с участием актрис 60+ (и повезло ещё что не 18-, а то бы прилетело от правоохранительных органов).

Выводы


  1. Никогда не давайте общего доступа к хранилищу без VPN.
  2. Всегда закрывайте гостевые доступы на всевозможных samba и ftp-серверах. По опыту, боты начинают раскладывать свои файлы и рекламу в первые же сутки после открытия доступа к ресурсу.
  3. Помните, что вы можете понести ответственность за не самые законные данные, которые кто-то может положить в ваши хранилища.


Бэкапы придумали те, кто не знает теории вероятности


У меня был один заказчик, который совершенно не понимал, зачем ему нужно тратить дополнительные суммы на резервное копирование, если у него всё работает. Это же дорого. А ещё у него всё отлично настроено. В итоге сотрудники, которые открывают и запускают всё подряд, что им присылают на почту, благополучно поймали вирус-шифровальщик. Базу 1С потеряли и восстановить смогли только благодаря бумажному архиву и одному подрядчику, который когда-то копировал базу себе.

Я пообщался с руководителем, объяснил ключевые моменты, которые нужно изменить в компании, чтобы устранить риски потери базы. Он кивал в течение всей беседы и в итоге выдал замечательную фразу: «Снаряд не попадает в одну лунку дважды. Теперь-то уже нечего бояться». От бэкапов снова отказался и закономерно потерял все данные по тому же сценарию через полгода.

Правила


  1. Вопрос не в том, потеряете ли вы данные (из-за вируса или аварии). Вопрос в том, когда это произойдёт и как всё будет восстанавливаться.
  2. Не забывайте хранить резервные копии за пределами одной площадки. Дата-центры иногда становятся недоступными целиком, а из площадки в офисе оборудование могут изъять или украсть.
  3. Научите уже сотрудников не открывать всё подряд из почтовых сообщений. Это правда бывает болезненно. Если сомневаетесь, поделитесь сомнениями с админом или helpdesk.


Управление УЗ вручную удобнее!


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

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

В отдельном здании у них было административное крыло, где мы закопались уже непосредственно в организацию информационной части производства. На первый взгляд у них была организована довольно логичная схема, когда доступ к базе данных клиентов предоставлялся только по внутренней учётной записи в AD с согласованием руководителя. Когда человек увольнялся — он пробегал с чек-листом, сдавал оборудование, карточки и ему деактивировали учётку. Всё это делалось вручную, так как средства на полноценный Identity management не выделялись.

В процессе аудита мы обнаружили, что у них много лет назад был реализован самописный портал для того, чтобы продажники могли удалённо получать нужные им данные по клиентам. Они даже начали миграцию своей инфраструктуры в облако, но в итоге остановились на полпути из-за каких-то внутренних сложностей. Причём AD интегрировать туда не смогли и учётные записи удалялись точно так же по чек-листу при увольнении. Вроде бы всё нормально, но в логах мы обнаружили активный аккаунт некоего Василия, который был уволен несколько лет назад и сейчас благополучно работал в конкурирующей компании. Причём, судя по логам, он минимум раз в месяц выгружал почти полную клиентскую базу.

Учётную запись тут же заблокировали и начали смотреть, как человек смог обойти внутренние регламенты. Оказалось, что Василий вначале получил доступы к порталу как менеджер по продажам, а затем перевёлся на управляющую должность непосредственно в цех, после чего уволился. А чек-лист при увольнении в цеху совсем другой и деактивация учётки от портала там не числилась. Хотя, казалось бы, сделать общий чек-лист на проверку доступа во всех системах и проблему можно было бы избежать.

Правила


  1. Если у вас больше 100 сотрудников — подумайте о внедрении полноценной IDM-системы.
  2. Данные об увольнении получайте не из обходного листа, а напрямую из отдела кадров. Увольнения бывают разными и обходной лист вам могут не принести.
  3. Если сотрудник переходит на другую должность в другой отдел — у него нужно обязательно отозвать все старые доступы. Иначе старые сотрудники при миграции внутри компании накапливают неприлично широкие права и доступы. Понимаю, что часто перевод происходит по методу «он пока работает и там и там, а дальше посмотрим», тогда при увольнении надо проверять наличие доступа во все системы, включая внешние (порталы подрядчиков, управление облаками и облачными сервисами, взаимодействие с поставщиками и тендерные площадки и т. д.).
  4. Никогда не назначать доступы по методу «такие же как у», иначе из-за накопления доступов через несколько лет новые сотрудники будут получать полный доступ всюду.
  5. Регулярно проводите аудит активных пользователей и сверяйте их со списком действующих сотрудников. Иначе могут быть сюрпризы.
  6. Всегда ведите логи. Если у вас на руках есть доказательство, что бывший сотрудник получает закрытую информацию — это вполне себе статья УК. Иначе вы ничего не сможете доказать в суде.


Как дальше жить?


Почему-то ИБ традиционно воспринимают как недружелюбных личностей, которые бегают за всеми со своими скучными регламентами и мешают работать. На самом деле при всей гротескности примеров выше — они довольно часто встречаются в реальных кейсах и именно безопасники и параноидальность админов помогают их избежать.

Просто постарайтесь найти общий язык. В первую очередь сами сотрудники ИБ не должны становиться вахтёрами, которые занимаются только вынесением мозга очередной парольной политикой без объяснения причин. Правильный подход — встретиться с разработчиками и девопсами, погрузиться в их проблемы. После чего разработать правильный компромиссный вариант, который не только не будет светить беспарольными доступами во внешний мир, но и будет при этом удобен в работе.

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

Текст подготовлен Владимиром Чикиным, руководителем направления ИБ Техносерв Cloud.

© Habrahabr.ru