Содержание статьи
Сегодня мы поговорим о такой важной составляющей ИБ, как укрепление сервера (hardening). Мы рассмотрим базовый подход к укреплению классического Linux сервера и разберем, насколько данный процесс важен и полезен.
Введение
Hardening - процесс усиления защищенности системы с целью снижения рисков от возможных угроз. Данный процесс применяется ко всем компонентам системы, тем самым, в идеальном случае, делая сервер неприступной крепостью. Судя по описанию, штука скучная и нехакерская, но с другой стороны, именно это и есть то, что мы называем процессами ИБ.
Более того, часто можно слышать о том, как безопасно писать код, какие страшные есть на свете уязвимости и т.д., но харденинг - это базис всего подхода к защите, поэтому не мудрено, что фактически именно этот процесс лежит в основе требований такого стандарта, как PCI DSS. Во всех организациях, где ИБ - это не мерзкая обязанность из-за того, что какие-то "бумажные специалисты" этого требуют, а реальная необходимость, именно харденинг является одним из главных атрибутов любой выкатываемой в продакшн системы.
Моя платформа - моя крепость
Допустим у нас есть система, построенная на Linux/Apache/MySQL/PHP. Мейнстрим, но мы потерпим. Давай предположим, что у нас есть фронт-енд, торчащий в интернет (Linux/Apache/PHP) и бэк-енд (Linux/MySQL). Мы опустим бэкапы, балансировку и защиту от DDoS на уровне архитектурных решений, ну и о MySQL, PHP и Apache мы поговорим, может быть, потом. Сегодня только ОС.
Здесь и далее: все советы нужно применять с умом, то есть надо понимать, на что влияет та или иная настройка, чтобы финальная конфигурация не убила функционал системы. В любом случае, принцип подхода - отключи то, что не нужно, остальное настрой так, чтобы работало согласно требованиям, а не по умолчанию. Это относится и к ядру. Все ненужные модули можно смело отключить. Тот же принцип и для пакетов - все ненужные сервисы и пакеты можно смело отрубить/отключить.
Linux Hardening
"Сеть — это Компьютер" (с), так что начнем наш процесс с настроек TCP/IP. В целом, еще нет глобальной поддержки ipv6, поэтому можно смело отключать поддержку этого протокола на сетевых интерфейсах. IPv6 довольно молодой и дырявый протокол, лишних проблем с его настройками нам не надо, как и лишних угроз.
# Проверка ядра
[ -f /proc/net/if_inet6 ] && echo 'IPv6 ready system!'
# Вывод интерфейсов с включенной поддержкой IPv6
ip -o -6 addr
Остальные сетевые настройки: отключим поддержку ICMP редиректов, форвардинг пакетов, ответы на широковещательный пинг - все эти чеки можно легко автоматизировать на bash:
# Проверяем IP Forwarding (не роутер же у нас, а просто сервер…)
if grep -q -P "^\s*net\.ipv4\.ip_forward\s*=\s*1\s*$" /etc/sysctl.conf; then echo "IP Forwarding enabled"; fi
# Но одно дело в конфиге, другое дело в памяти. Так даже будет надежнее. В конфиге может быть ничего не указано, а в памяти есть все текущие настройки:
if ! grep -q -P "^\s*0\s*$" /proc/sys/net/ipv4/ip_forward; then echo "IP Forwarding enabled"; fi
# Проверяем поддержку маршрутизации от источника (проверяем сразу для all и default и сразу в памяти)
if (! (grep -q -P "^\s*0\s*$" /proc/sys/net/ipv4/conf/all/accept_source_route && grep -q -P "^\s*0\s*$" /proc/sys/net/ipv4/conf/default/accept_source_route)); then echo "Source routing enabled"; fi
Таким же образом проверяем остальные сетевые настройки:
- net.ipv4.conf.(all|default).accept_redirects - ставим 0, игнорируем ICMP редиректы, так как не хотим, чтобы маршрут мог быть изменен.
- net.ipv4.icmp_echo_ignore_broadcasts - ставим 1, кому нужны широковещательные пинги в 21 веке?
- net.ipv4.icmp_ignore_bogus_error_messages - зачем нам разбирать кривые ICMP пакеты? Что там может быть хорошего, только логи засорять. В топку!
- net.ipv4.tcp_syncookies - тут надо ставить 1. Классическая защита от SynFlood атак, лишней не будет 8).
- net.ipv4.conf.(all|default).rp_filter - тут конечно 1. Верификация IP источника, полезная фича для защиты IP Spoofing атак.
Есть и другие фичи для параноиков, но это базовые. Кто-то не любит пинги вообще, а у некоторых так health_check делается, поэтому здесь советовать сложно. Все проверки легко автоматизируются, что полезно, если ты производишь авто-деплоймент.
Кое-что про фаервол. Это вопрос архитектуры системы, то есть, например, если наша машинка работает в Амазоне или же вся сетка режется каким-то красивым роутером/межсетевым экраном или хитрыми VLAN'ами, то ясно, что вся фильтрация и логика доступа будет там, но если мы закидываем сервак в непонятный дата-центр, где у нас куча других проектов, то возникает угроза горизонтальных атак в пределах дата-центра. То есть наш MySQL сервер не видит инета, и его не видно из инета, но другие хосты дата-центра его видят. В таком варианте локальные правила фильтрации будут нелишними. Проверить это автоматом сложно, так как по умолчанию, особенно если проектов много, ты не знаешь, кому какие правила доступа требуются, и нужно все внимательно изучать и допиливать. Но вот быстрый чек замутить можно:
if (iptables -S|grep -P "^\-P\s+((INPUT)|(FORWARD)|(OUTPUT))\s+ACCEPT$"); then echo "Your firewall suck"; fi
Аккаунты
Кроме сети, у нас еще есть стандартные сервисы, типа SSH. Требования здесь достаточно просты:
- У каждого юзверя свой аккаунт.
- Админы заходят через свой аккаунт. Если нужен root, аккуратно помещаем их учетки в sudoers.
- Никаких паролей - вся аутентификация только по ключам.
- В sudoers никаких палевных записей, типа "tomcat ALL=NOPASSWD: /bin/sh -c cat *".
Большая часть чеков так же легко автоматизируется, не буду тут это расписывать.
Файловая система
Это самая важная часть. Например, классикой жанра является уязвимость LFI, и раньше было модно инъектить в логи апача PHP код для дальнейшего RCE. Это, конечно, старый и унылый пример, но это показывает силу хардининга. Дело в том, что Апач у нас пишет логи от рута, а вот дочерние процессы (форки) запущены с правами непривилегированного пользователя, например apache. Так вот, в идеальном мире этот юзер не должен иметь прав на чтение в директории /var/log/httpd/, что сведет к неудаче попытку чтения через LFI (но мы-то, конечно, знаем про phpinfo и upload директорию…) И это минимальный пример. В других примерах есть куча директорий и файлов, которые не желательны для доступа другим юзерам, типа apache. Это различные конфиги, логи и бэкапы, в которых может быть чувствительная информация и, о нет, персональные данные. Для автоматизации этого чека можно запилить скрипт, который проверяет права чтения и записи "для всех". Может оказаться полезным.
Кроме того, имеет смысл сварганить скрипт, который ищет чувствительные данные по ФС. Зачем это нужно? Очень просто, запускаем этот скрипт от юзера апач или даже рута, он мучается несколько минут, а затем должен показать, что он ничего не нашел в открытом и доступном виде. Этот трик применяется всеми вменяемыми PCI DSS аудиторами, которые по регекспам ищут следы номеров кредитных карт, и если такой скрипт находит их, то аудитор справедливо выписывает пачку люлей 8). Соответственно, мы определяем, какие данные для нас важны, и какие данные мы защищаем, затем пишем их фингерпринт и чекаем автоматом, что фактически означает быструю проверку на тему "не может ли хакИр, в случае RCE, LFI или Traversal, найти что-то ценное". Примеры таких данных:
- Маска номеров кредитных карт
- Логины и пароли
- Персональные данные
- Коды активных сессий
Кроме того, несмотря на все вышесказанное, все равно следует проверять /etc/passwd, /etc/shadow, /etc/group - на наличие аккаунтов со слабыми паролями (MD5 хэшами), аккаунтов без паролей, и проверить все акки с логин-шеллом. Это так же легко автоматизируется на баше с грепом.
SeLinux/AppArmor
Отдельно хочется сказать про этот слой защиты. На самом деле, данные системы контроля доступа на уровне ядра являются очень эффективными инструментами. Но вот их настройка дело сложное, и не всегда тривиальное. Крайне рекомендую озаботиться, но стоит помнить, что любые изменения в логике работы системы могут быть заблокированы SeLinux/AppArmor, что приводит к дополнительным проблемам с поддержкой системы.
Итд Итп
Продолжать описывать рекомендации можно долго: и поиск SUID бит исполняемых бинариков, и настройки Апача, MySQL - все эти вещи должны быть выполнены, но поверь - это того стоит, даже если программист совершит ошибку, даже если атакующий проведет атаку, именно hardening будет последней надеждой на то, что урон окажется минимальным. Усиление сервера можно проводить до бесконечности - установить системы контроля целостности, систему мониторинга логов, контроля WAF и т.д.
WWW
- Руководство VMware hardening
- Повышение безопасности RHEL 5.0
- Усиление защиты web-серверов
- Настройка php.ini
- Харденинг MySQL
Главный месседж, что я хотел донести: ИБ - это не только хак, безопасное программирование или слабые пароли - ИБ, это процесс, и вот эту часть с базовыми настройками системы очень многие пропускают - в банках, в госучреждениях, в крупных энтерпрайз-компаниях. Если тебе интересна эта тема, и ты хотел бы помочь в создании единой базы знаний по hardening различных систем и платформ - пиши на defconrussia@gmail.com. Может получиться интересный проект, как по самой базе, так и по автоматизации этого дела ;).
