Pull to refresh

Надёжный и безопасный Linux (наш ответ Чемберлену)

System administration *
Sandbox
После прочтения на Хабре недавних статей, посвящённых теме безопасности линукс систем, у меня возникло желание поделиться своей точкой зрения на этот вопрос.
Статья в целом рассчитана на начинающих администраторов, поэтому в ней изложены очевидные для хорошего специалиста вещи. Ценные дополнения и замечания приветствуются.
Копи-пейст выдержки из конфиг файлов я почти не буду приводить по трём причинам:
  1. Это приведёт с излишнему разрастанию статьи
  2. Маны и гугл никто не отменял
  3. Пункт 2 очень полезен для развития специалиста


Итак, как повысить безопасность и надёжность сервера (да и рабочей станции) на базе линукс?



Эту задачу я разделю на 3 части:
  1. (Про)активное обеспечение безопасности — ужесточение настроек системы и демонов. Сюда же относится настройка файрвола.
  2. Пассивное обеспечение безопасности и надёжности — мониторинг системы.
  3. Бэкапы

Ужесточение настроек системы

  1. Отключить неиспользуемые сервисы/демоны. Внимательно просмотреть список процессов (например по команде ps -ef | less ) и определить те из них, которые вам не нужны. Убедиться в том, что они не нужны самой системе. Отключить.
  2. Если это возможно, то изменить стандартные порты и интерфейсы на которых слушают оставшиеся сервисы и настроить дополнительные ограничения по безопасности средствами самих сервисов (т.е путем редактирования их конфигурационных файлов / добавления ключей к параметрам запуска).
    Проиллюстрирую на примере sshd. Здесь необходимо сделать следующее — изменить стандартный порт с 22-го на любой свободный, например на 6622. Запретить доступ под логином root. Жёстко задать список разрешённых для доступа имён пользователя. Разрешить sshd прослушивать только определённый адрес. Как вариант разрешить доступ только по ключу, но мне это не очень нравится
    UPD Ключи единогласно признаны отличным способом доступа к серверу, поэтому используйте их (но не отключайте окончательно парольный вход).
  3. Все сервисы, которые используются только системным администратором либо ограниченным кругом лиц должны быть доступными только через vpn либо ssh соединения.
  4. Везде, где это возможно перейти на использование шифрованного соединения (pop3->pops3, http->https итд)
  5. Iptables
    Настройка файрвола очень интересная тема, которой нужно посвятить отдельную статью.
    Основные принципы таковы:
    Файрвол должен работать по принципу белого списка, т.е всё что не разрешено явно, является запрещённым.
    Этого можно достичь двумя способами:
    Способ №1
    Установка политики файрвола по умолчанию командами iptables -P INPUT DROP, iptables -P OUTPUT DROP и iptables -P FORWARD DROP. После выполнения этих команд весь входящий, исходящий и транзитный трафик, для которого не создано разрешающих правил будет заблокирован, поэтому выполнять их следует с осторожностью.
    Перед тем, как хоть что-то делать с iptables настоятельно рекомендую изучить отличное руководство от Oskar Andreasson
    При его прочтении обратите внимание на цель (действие) LOG, которое позволяет записывать в лог различные данные по попадающим в систему пакетам. Это очень сильно помогает при первоначальном написании файрвола. Могу посоветовать примерно такой порядок настройки файрвола:
    a) Написать все нужные правила
    б) В конец каждой цепочки добавить правило логирования (оно будет отлавливать все пакеты, которые вы не учли в предыдущих правилах и записывать информацию о них в сислог)
    в) Включить файрвол
    г) Находить неучтённые вами соединения в сислоге и добавлять правила для них в файрвол.
    Пункт (г) повторять до исчезновения записей в сислоге.
    Понятно, что не следует бездумно добавлять всё, что появляется в сислоге т.к там будут видны и результаты попыток несанкционированного доступа.
    Отмечу, что политику по умолчанию DROP нужно включать лишь после успешного завершения пункта (г) — это гарантирует, что существующие сервисы продолжат свою работу во время отладки файрвола.
    Также отмечу один не совсем явный для начинающих момент:
    Вот выдержка из того, что должен содержать шаблон стандартного файрвола.
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
    iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

    Эти правила разрешают входящие и исходящие пакеты, которые принадлежат уже установленным сессиям.
    Работает это конечно только для stateful протоколов, в частности для протокола tcp.
    Если не использовать эти правила, то для каждого приложения придётся писать по 2 правила — одно для цепочки INPUT, а второе для OUTPUT.
    Если же их использовать, то можно ограничиться лишь одним, тем которое позволит установить изначальное соединение.

    Способ №2
    В конце каждой цепочки прописать правило, отправляющее все пакеты в REJECT.
    Т.е в стандартном случае нужно добавить три правила — iptables -A INPUT -j REJECT, iptables -A OUTPUT -j REJECT и iptables -A FORWARD -j REJECT.
    В результате добавления этих правил, все пакеты которые явно не разрешены предыдущими правилами будут отвергнуты с сообщением port-unreachable.
    Всё остальное нужно делать точно так же, как и в способе №1, включая добавление правил с --state RELATED,ESTABLISHED.

    Способ №2 является наиболее верным идеологически и я советую использовать именно его, но выбор остаётся за вами.
  6. SELinux
    Очень интересная и перспективная вещь. Ограничивает права процессов по доступу куда-либо. Каждое действие, которое разрешено делать процессу должно быть прописано в политике, сопоставленной с ним.
    Существует ещё одна аналогичная система — Apparmor (насколько я знаю она используется в ubuntu linux).
    Честно говоря с обеими системами я ещё не работал вплотную (поэтому рекомендаций особых дать не могу), частично использовал SELinux в одном проекте, но ввиду цейтнота по времени, в котором я тогда находился, пришлось временно эту задачу отложить. В скором времени однозначно вернусь к настройке SELinux т.к он мне весьма понравился.

Мониторинг

Взломы и аварии, как известно лучше предотвращать, чем устранять их последствия.
В этой связи очень актуальна грамотно настроенная система мониторинга, которая при первых признаках проблемы сразу подаст сигнал администратору.
  1. Nagios
    Существует несколько крупных систем мониторинга (nagios, zabbix, cacti, munin).
    Я пробовал их все и в итоге остановился на Nagios. Очень удобная и гибкая в настройке система.
    Огромное количество плагинов для мониторинга, а если подходящего плагина нет, можно написать свой на любом удобном вам языке (я например использую для этого bash и python).
    Как минимум необходимо настроить мониторинг загрузки процессора, памяти, свапа, свободного места на диске, load average. Очень желательно мониторить доступность критичных сервисов (например apache, mysql, nginx, tomcat итд).
  2. MRTG/RRD
    Динамику изменения различных показателей удобно просматривать на графиках, генерируемых с помощью MRTG.
    MRTG позволяет просмотреть в удобном виде зависимость различных системных параметров от времени.
    Например можно посмотреть то, как изменяются загрузка процессора и памяти в зависимости от времени суток. Рисовать графики можно практически для любых показателей — от температуры процессора, до количества запросов к базе данных. MRTG это инстумент, крайне полезный для анализа состояния системы.
    У MRTG есть несколько ограничений и недостатков, которые можно обойти воспользовавшись утилитой RRD от того же автора.
  3. Smartd + smartmontools
    Позволяет мониторить состояние жёстких дисков и выявлять подозрительные показания на самом раннем этапе. Можно интегрировать в Nagios.
    Например отличное от нуля значение переменной Reallocated_Sector_Ct указывает на то, что на диске появились бэд секторы, причём появились уже давно т.к smart узнаёт о наличии бэдов только после того, как переполняется заводская remap таблица (тут могу немного ошибаться, теорию по этому поводу давно не обновлял, возможно у современных жёстких дисков бэды сразу видны через smart).
    Можно и нужно настроить smartd так, чтобы все подозрительные показания сразу же высылались по электронной почте администратору.
  4. Анализаторы логов
    Ясно, что вручную мониторить логи системы на предмет ошибок занятие неблагодарное.
    Для этой цели уже давно существует много анализаторов логов.
    Советую поставить сразу несколько систем и выбрать ту, что понравится больше.
    Начать можно с logwatch.
  5. Remote syslog
    Как вы думаете, какова первая цель злоумышленника, проникшего в какую-либо систему?
    Цель — скрыть своё присутствие.
    Для этого он обязательно удалит все упоминания о своих действиях из логов системы (а также попробует подменить некоторые системные утилиты, но об этом ниже).
    Для того, чтобы защититься от негативных последствия удаления логов необходимо организовать их запись на удалённый сервер. Желательно, чтобы ssh доступ на этот сервер был невозможен (самому можно заходить через IP KVM) либо сильно затруднён, иначе ничего не помешает взломщику удалить хранящуюся там немодифицированную копию логов. На самом лог сервере удобнее всего хранить логи в какой-либо СУБД.
  6. HIDS и NIDS
    HIDS мониторит состояние системы (логи, целостность системных утилит итд) и при подозрении на нарушение безопасности информирует об этом администратора. Она поможет в случае, если злоумышленник из предыдущего пункта подменит какую либо системную утилиту с целью скрыть своё присутствие либо обеспечить себе вход в систему. Например можно подменить утилиты ps, who, w, last с тем, чтобы администратор не мог видеть кто залогинен в системе в настоящий момент. Заменить утилиты iptables и sshd с тем, чтобы они позволяли злоумышленнику свободно входить в систему.
    HIDS конечно не сможет помешать таким действиям, но вполне сможет уведомить о них администратора.
    Одним из примеров HIDS является OSSEC.

    NIDS Если HIDS мониторит внутреннее состояние системы, то NIDS анализирует подозрительную сетевую активность (сканирование портов, попытки подбора паролей, различные атаки против сервисов системы итд). Наиболее известной NIDS является Snort.


Бэкапы

  1. Как известно системные администраторы делятся на тех, кто не делает бэкапы, на тех, кто их уже делает и на тех, кто думает, что их делает.
    Это изречение наполнено глубоким смыслом.
    Бэкапы могут понадобиться во многих случаях, например после аппаратных проблем с системой, после её взлома, после некорректных действий администратора или разработчика.
    Можно условно разделить бэкапы на бэкапы файловой системы и бэкапы баз данных.
    Очень желательно иметь отдельный сервер для хранения бэкапов, в идеале ещё и находящийся отдельно от всего остального оборудования. Отдельно значит на расстоянии километров 5, не меньше.

    Для бэкапа написано много разнообразного ПО, но я предпочитаю использовать скрипты, написанные лично мной. Так я получаю полный контроль над процессом.
    Для бэкапа файловой системы проще использовать rsync с подходящими ключами. В большинстве случаев удобнее делать инкрементальный бэкап.
    Для бэкапов баз данных лучше всего использовать утилиты, предоставленные производителями СУБД, но в случае с mysql я немного отошел от этого правила.
    Стандартная утилита для бэкапа — mysqldump не очень хорошо ведёт себя при снятии бэкапа, а именно — она «лочит» таблицы на запись, запрещая писать в них в момент бэкапа (хотя в случае с innodb этого можно было бы вполне избежать, но mysqldump не умеет этого делать). Это очень актуально при использовании больших баз, размером хотя бы 10-20 Гб, где блокировка таблицы может длиться 10-20 минут. Кроме того восстановление больших баз из такого бэкапа занимает многие часы.
    В такой ситуации более разумно использовать систему master->slave.
    На бэкап сервере настраивается mysql slave для той базы, которую необходимо бэкапить. В дальнейшем бэкапы снимаются уже не с основной базы, а с её slave-а. В случае же аварии можно даже сразу не восстанавливать базу, а просто перенаправить все запросы на slave сервер, что позволит сильно сэкономить время. Для снятия бэкапов со slave сервера и для его первичной подготовки удобно использовать утилиту Innobackupex от компании Percona. Она например позволяет сделать бэкап, пригодный для последующего поднятия slave сервера без остановки основной базы (без блокировки её на запись).
    Есть ещё один очень важный момент — необходимо периодически проверять бэкапы на предмет их корректности, иначе вы рискуете в самый неподходящий момент обнаружить пустые или битые архивы.


Очень важно вести документацию (например в wiki) по всем обслуживаемым серверам и не забывать обновлять её при любых изменениях настроек серверов. Очень часто встречаются случаи, когда системный администратор не может вспомнить деталей настройки системы, с которой он долго не работал.

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

P.S В статью внесены некоторые правки по результатам обсуждений в комментариях. Спасибо всем высказавшимся.
Tags:
Hubs:
Total votes 86: ↑78 and ↓8 +70
Views 18K
Comments 59
Comments Comments 59