Краткий курс выживания для админа

14:00 12.03.2018

Краткий курс выживания для админа

Пособие по безопасности для самых маленьких админов. Защитил данные — защитил юзеров — защитил себя. Профит.

Примечание редакции. Это очень узкоспециализированный материал, уж простите. Но полезный. Представитель «Украинского киберальянса» о том, как админу обезопасить данные в эпоху кибервойн.

Секретность ↑ + целостность ↓ = Ø изоляция

Я давно обещал написать небольшое пособие по безопасности. Для самых маленьких администраторов. Начнём с самого простого. У сети должен быть периметр, иначе просто отсутствует охраняемый объект. В физическом мире это может быть забор и ворота, через которые люди входят и выходят, и окошко для выдачи пропусков. Если через забор можно перелезть — изменить шлюз по умолчанию (вот для чего net.ipv4.ip_forward по умолчанию выключен) или пронести модем (или что-то похожее, например, мобильный телефон) и подключить его к рабочему компьютеру, построить туннель через пинги или DNS-запросы, то никакого периметра у вас нет. Защищать нечего.

Но защищать мы собираемся не компьютеры как таковые, а данные, которые они обрабатывают. Какие-то из них являются публичными (то есть должны быть опубликованы в неизменном виде), какие-то — конфиденциальными (те же пароли), для служебного пользования (то, что они не секретные и к ним имеет доступ большое количество людей, совсем не значит, что их не нужно охранять) и секретные, конечно. Для того чтобы отличать одно от другого, необходимо провести классификацию. Если у вас фоточки котов, учебники, документы и бухгалтерия лежат в одной куче, то защищать опять-таки нечего. Классификация — необходимая часть безопасности.

Уже в 1970-е годы появились разнообразные модели, описывающие, как это всё должно работать. Самыми простыми являются модели Белла – Лападулы и Бибы. Первая обеспечивает секретность данных: агент пишет донесение куратору, куратор пишет в центр, и с каждым уровнем секретность повышается. Более секретный документ, условный «отчёт центра», не может спуститься вниз к агенту (read down, write up). А вторая модель обеспечивает целостность данных: полковник приказывает майору, майор — лейтенанту, лейтенант — рядовому. Не наоборот. Приказ должен спуститься вниз в неизменном виде (read up, write down).

Теперь давайте думать, что будет, если нам нужна и целостность данных (чтобы хакеры не написали на официальном сайте какое-нибудь зубодробительное объявление, к примеру, об «объявлении войны ЛНР со стороны ДНР»), и секретность данных (чтобы те же самые хакеры не рылись в почте МИД)? Если модель Белла запрещает write down, а модель Бибы запрещает write up, возникает изоляция. Именно поэтому Джин Спаффорд сказал, что по-настоящему безопасную систему нужно отключить, залить в бетонный блок, поставить в комнате, обшитой свинцом, и приставить вооружённую охрану. И то остаются сомнения.

Итак, безопасность — это изоляция. И она недостижима, потому что ничего не будет работать. Про DAC, MLS, каналы утечки, обход и прочие выверты говорить не будем, но подумаем о том, как достигнуть максимально возможной изоляции, чтобы не затра*ать пользователей вусмерть, а безопасность — это всегда неудобно. (Проще держать дверь открытой, чем открывать её тремя ключами и снимать с сигнализации.) Людям нужно оставить какую-то отдушину, иначе они начнут ломать ваши стены изнутри. В ход идёт принцип наименьших привилегий.

Если публичный сервис можно выключить, то он должен быть выключен. На практике публичному сервису не нужны открытые порты MySQL/Postgre, ident, svn, POP3 и прочее. Всё, что можно отключить, отключите, лучше даже не запускать, если не знаете, что это такое. В идеале публичный сервер должен принимать (но не отдавать) почту, отвечать на DNS-запросы, раздавать web-страницы, принимать VPN-соединения (очень желательно, чтобы это был не один тазик с Linux-ом, а хотя бы тот же Linux, порезанный на виртуалки). Спрячьте админки, web-морды от почты и прочие кишки в демилитаризованной зоне, которая отделена и от Интернета, и от локальной сети. Изоляция.

Сама сеть, в свою очередь, должна быть разделена на сегменты, чтобы из колл-центра не был виден сервер бухгалтерии. И если уж в исключительных случаях вашему главному бухгалтеру приспичит в 02:00 ночи исправить годовой отчёт из дому, то прорубите ему (или ей) отдельный туннель (причём не тот, что заканчивается в DMZ — напоминаю, что локальная сеть из DMZ не видна, в этом смысл). Себе можете оставить, какую-нибудь нычку на чёрный день, но уж обойдитесь, пожалуйста, без ssh по паролю на 2222-порту, и если вы не понимаете почему, то перечитывайте всё с начала. Изоляция.

Разрешите пользователям притаскивать каких-нибудь котиков, но объясните им, почему котиков и ДСК в одной свалке хранить нельзя, тогда можно будет худо-бедно настроить права доступа. Если вы думаете, что система юниксовых прав 3*3+3 — вершина человеческой мысли, то и тут вынужден вас разочаровать. Но уж хоть что-то. Изоляция. О том, что хорошо для пользователей, можно почитать у Владимира Стирана («Як не стати кібержертвою»). И не нужно начинать с должностной инструкции на 150 пунктов с приложениями — никто её не прочитает, объясняйте вещи по одной в максимально доходчивой форме.

Итак, изолируйте друг от друга данные с разной классификацией. Изолируйте сегменты локальной сети друг от друга, а локальную сеть — от Интернета. Дружите с пользователями вместо того, чтобы заставлять их соблюдать правила, которые они не понимают, — и у вас получится система если и не идеальная, то хотя бы управляемая, а это уже неплохо.