[FrontPage] [TitleIndex] [WordIndex

This is a read-only archived version of wiki.centos.org

Компьютерная безопасность вновь становится горячей темой для администраторов. Создаются дюжины новых сайтов повсеместно и каждый предлагает свои 'Идеальные' инструкции по установке. Они обычно содержат массу хороших советов и консультаций, которые очень эффективно оставят вас с кучей тлеющего щебня там, где у вас были данные. Здесь мы собираемся обсудить запирание на замок системы CentOS 5 надлежащим образом. Эти надлежащие образы основаны на Путеводителе NSA RHEL5, презентации Стива Грабба Закаливание RHEL и других авторитетных источниках.

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

Разметка файловой системы

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

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

1. Модификация fstab

Как только ваши разделы разбиты и соответственно задан их объем, вы можете по возможности ввести ограничения для разнообразных точек монтирования. Вам следует добавить nodev, noexec, и nosuid всюду, где это возможно. Пример достойного ограничения файла /etc/fstab представлен ниже:

/dev/VG_OS/lv_root          /        ext3      defaults     1 1
/dev/VG_OS/lv_tmp           /tmp     ext3      defaults,nosuid,noexec,nodev  1 2
/dev/VG_OS/lv_vartmp        /var/tmp ext3      defaults,nosuid,noexec,nodev 1 2
/dev/data_vol/lv_home       /home    ext3      defaults,nosuid,nodev  1 2
/dev/VG_OS/lv_var           /var     ext3      defaults,nosuid     1 2
/dev/data_vol/lv_web        /var/www ext3      defaults,nosuid,nodev  1 2
/dev/sda1                   /boot    ext3      defaults,nosuid,noexec,nodev  1 2
tmpfs                       /dev/shm tmpfs     defaults 0 0
devpts                      /dev/pts devpts    gid=5,mode=620 0 0
sysfs                       /sys     sysfs     defaults    0 0
proc                        /proc    proc      defaults    0 0
/dev/_VG_OS/lv_swap         swap     swap      defaults    0 0

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

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

Установка пакетов

Когда дело доходит до установки пакетов в вашу систему, хорошо помнить, что чем меньше (пакетов, функций), тем лучше. Больший функционал на одной системе означает больше точек приложения сил в ракурсе уязвимостей и обновлений, а также становится больше вещей, которые потенциально можно получить в процессе вашей деятельности. С увеличением разнообразия серверных задач, я бы не хотел даже пытаться предоставить список того, что должно или не должно быть установлено. Вместо этого я рекомендую выработать основную стратегию настройки списка пакетов и отключения всего, кроме основы. Как только это будет сделано, сгенерируйте список того, что в данный момент установлено и в дальнейшем обрезайте все, что вам не требуется.

yum list installed >> ~/installed.txt

ArtWork/WikiDesign/icon-admonition-attention.png

Для пользователей x86_64: Если вам не требуются i386/i686 пакеты для осуществления совместимости, удалите их все с помощью команды yum remove *.i?86, после этого заблокируйте их установку путем добавления exclude = *.i?86 в конфигурационный файл /etc/yum.conf

1. Регулярные обновления

Теперь, когда у нас есть минимальный набор пакетов, нам потребуется периодически обновлять их. Я не рекомендую использовать yum-updatesd. У меня неоднократно был негативный опыт работы с этим пожирателем ресурсов, чтобы посоветовать его. Вы можете установить задачу cron по обновлению или проверке обновлений, как рекомендует путеводитель NSA. Вы можете просто вручную применять обновления на еженедельной основе или пойти ва-банк и настроить сервер для управления обновлениями нескольких систем. Так или иначе, все сводится к тому, что вам придется решать, какой политики обновления придерживаться. Применяйте обновления своевременно с целью избежать проблем. В качестве дополнения, будет хорошим решением подписаться на почтовую рассылку CentOS-Announce. Таким образом, вы будете получать уведомление каждый раз, когда выходит обноление и вы сможете применять критические патчи раньше, если потребуется.

Как только ваши списки пакетов будут достаточно обрезаны и обновлены, вы захотите пройтись по списку служб и отключить все, что не будет использоваться на вашем сервере. Опять же, учитывая то, что каждое окружение уникально, я не буду претендовать на советы по поводу того, что должно быть включено, а что нет; в любом случае, вам нужно спросить себя самого, ДЕЙСТВИТЕЛЬНО ли нужна запущенная bluetooth служба на сервере :-P

Основная закалка

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

1. Физическая защита

Для получения указаний по защите загрузчика grub обратитесь к Защита BIOS и загрузочной программы. Для установки пароля суперпользователя root для однопользовательского режима, вы можете воспользоваться:

echo "# Запрашивать пароль root в процессе загрузки однопользовательского режима" >> /etc/inittab
echo "~~:S:wait:/sbin/sulogin" >> /etc/inittab
echo "Отключение возможности убить сервер"
perl -npe 's/ca::ctrlaltdel:\/sbin\/shutdown/#ca::ctrlaltdel:\/sbin\/shutdown/' -i /etc/inittab

Теперь отключите USB накопители, если вы не будете использовать их в своем окружении.

echo "Отключение USB накопителей"
echo "blacklist usb-storage" > /etc/modprobe.d/blacklist-usbstorage

2. Права пользователей

Это самая крупная категория с некоторыми особо важными моментами. Учитывая, что каждая организация особенная, не все из них могут быть применимы вами, но вы обязаны рассмотреть всё.

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

2.1. Ограничения пользователя Root

Когда сервер включен и работает, root не должен входить в систему напрямую за исключением чрезвычайных ситуаций. Такие ситуации требуют вмешательства у консоли, поэтому это единственное место, откуда учетная запись root должна быть доступна для использования. Чтобы сделать это, нужно модифицировать /etc/securetty. Дополнительно, ни один другой пользователь, кроме root, не должен иметь доступ к домашней директории root'а. Настройки по умолчанию близки к этому, но с позиции паранойи не достаточно близки.

echo "tty1" > /etc/securetty
chmod 700 /root

После эффективного отключения возможности входа пользователя root откуда угодно кроме локальной консоли, возникает необходимость использования su или sudo. Так можно извлечь второстепенную выгоду в окружении с множеством административных учетных записей.

2.2. Парольная политика

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

echo "Срок действия паролей истекает каждые 180 дней"
perl -npe 's/PASS_MAX_DAYS\s+99999/PASS_MAX_DAYS 180/' -i /etc/login.defs
echo "Пароли могут быть изменены только один раз в день"
perl -npe 's/PASS_MIN_DAYS\s+0/PASS_MIN_DAYS 1/g' -i /etc/login.defs

Следующая команда обновит вашу систему таким образом, что будет использоваться криптография SHA512 вместо MD5 для защиты паролей. Это смягчает количество бюрократических проблем с безопасностью касательно MD5 для защиты паролей.

authconfig --passalgo=sha512 --update

2.3. Ограничения Umask

Модификация umask по умолчанию может сделать некоторые вещи интереснее. Рекомендуемый для усиления защиты umask 077 может обернуться болью для пользователей, которые регулярно обмениваются файлами. Будьте осторожны в своем решении внедрить это, прислушайтесь к вашим пользователям.

perl -npe 's/umask\s+0\d2/umask 077/g' -i /etc/bashrc
perl -npe 's/umask\s+0\d2/umask 077/g' -i /etc/csh.cshrc

Теперь, когда все стало немного сложнее, если пользователь провалит получение корректных полномочий, pam_tally2 будет запрещать доступ до тех пор пока значение unlock_time не будет достигнуто. Иными словами, если вы провалите авторизацию 3 раза подряд, вы будете вынуждены ждать определенный период времени перед тем, как сможете повторить попытку.

2.4. Модификация Pam

И теперь нам нужно обновить /etc/pam.d/system-auth

touch /var/log/tallylog
cat << 'EOF' > /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so
auth        required      pam_tally2.so deny=3 onerr=fail unlock_time=60

account     required      pam_unix.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so
account     required      pam_tally2.so per_user

password    requisite     pam_cracklib.so try_first_pass retry=3 minlen=9 lcredit=-2 ucredit=-2 dcredit=-2 ocredit=-2
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok remember=10
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
EOF

Файл /var/log/tallylog - это бинарный лог, содержащий записи о сбоях авторизации для pam. Вы можете наблюдать провальные попытки путем запуска команды pam_tally2 без опций и разблокировать учетные запили пользователей преждевременно с помощью pam_tally2 --reset -u username.

2.5. Уничтожение неактивных пользователей

С тех пор как введены опции ограничения входа на сервер, давайте выгоним всех неактивных пользователей, для этого будет использована переменная bash в /etc/profile. Конечно, есть тривиальные пути для этого, но все должно быть сделано с учетом слоев безопасности.

echo "Неактивные пользователи будут удалены через 15 минут"
echo "readonly TMOUT=900" >> /etc/profile.d/os-security.sh
echo "readonly HISTFILE" >> /etc/profile.d/os-security.sh
chmod +x /etc/profile.d/os-security.sh

2.6. Ограничения cron и at

В некоторых случаях, администраторы могут пожелать иметь возможность запускать задачи cron с помощью пользователя root или с помощью других доверенных пользователей, запускать скрипты расписанию с at. В порядке блокировки этих возможностей вам следует создать файлы cron.deny и at.deny в директории /etc с именами заблокированных пользователей. Проще всего это реализовать путем парсинга /etc/passwd. Следующий скрипт сделает это для вас.

echo "Блокировка Cron"
touch /etc/cron.allow
chmod 600 /etc/cron.allow
awk -F: '{print $1}' /etc/passwd | grep -v root > /etc/cron.deny
echo "Блокировка AT"
touch /etc/at.allow
chmod 600 /etc/at.allow
awk -F: '{print $1}' /etc/passwd | grep -v root > /etc/at.deny

Сетевая безопасность

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

1. Безопасность сети на уровне ядра

Есть ряд методов усилить безопасность сети путем незначительных модификаций и добавлением модулей в черный список.

1.1. Беспроводная сеть

В рамках серверной безопасности беспроводная сеть не должна быть реальной проблемой. Если вам потребуется беспроводная сеть, можете пропустить этот пункт, потому что здесь мы говорим об отключении всех драйверов беспроводной сети. Вы можете рассмотреть содержимое /lib/modules для вашего текущего ядра и удалить все драйверы беспроводных сетей. Это основательно отключит беспроводную сеть, но это не перманентное решение. При следующем обновлении ядра, модули вернутся на свои места и вы будете делать это снова и снова. Вместо этого используйте простой способ отключить их путем добавления в файл черного списка blacklist в /etc/modprobe.d:

for i in $(find /lib/modules/`uname -r`/kernel/drivers/net/wireless -name "*.ko" -type f) ; do echo blacklist $i >> /etc/modprobe.d/blacklist-wireless ; done

1.2. Безопасность Sysctl

Теперь нам следует взглянуть внутрь /etc/sysctl.conf и сделать некоторые базовые изменения. Если следующие строки существуют, модифицируйте соответствующим образом как показано ниже. Если они не существуют, просто добавьте их. Если у вас есть множество сетевых интерфейсов на сервере, некоторые из них (строк) могут вызвать проблемы. Протестируйте это перед продуктивным внедрением. Если вы хотите узнать больше об этих опциях, установите пакет kernel-doc и изучите файл Documentation/networking/ip-sysctl.txt.

net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.tcp_max_syn_backlog = 1280
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.tcp_timestamps = 0

1.3. Использование обёрток TCP

Обёртки TCP (wrappers) могут предоставлять быстрый и легкий метод контроля доступа к связанным с ними приложениям. Примеры TCP обёрток известных приложений - sshd и portmap (неточность перевода). Ограничивающий пример предоставлен ниже. Этот пример блокирует все, крмое SSH.

echo "ALL:ALL" >> /etc/hosts.deny
echo "sshd:ALL" >> /etc/hosts.allow

1.4. Укрепление IPTables

Набор правил iptables по умолчанию в CentOS немного мягкий. Политика по умолчанию позвляет движение трафика, имеются открытые порты и нет настоящей подотчетности по трафику. Мы можем это улучшить.

Откройте конфигурационный файл /etc/sysconfig/iptables в текстовом редакторе и давайте взглянем на него. В первых трех строчках уже имеется 2 проблемы. Таблицы INPUT и FORWARD уже установлены на прием абсолютно всего. Далее мы видим, что порты 50, 51, 5353, 631 и 22 открыты. Сейчас у меня нет проблем с портом 22. Большую часть этих портов нужно закрыть до тех пор, пока вам не понадобится доступ к mDNS, cups и ipsec с внешней стороны. В общем, мне не нравятся незнакомцы, использующие мой принтер.

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

#Сбрасываем все, кроме того, что дозволено. Весь исходящий трафик допускается.
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type echo-reply -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
# Принимаем ping'и
-A RH-Firewall-1-INPUT -p icmp --icmp-type echo-request -j ACCEPT
# Логируем все на интерфейсе eth0 из локальной или немаршрутизируемой сети
# Если вы используете одну из этих локальных сетей, удалите ее из списка ниже
-A INPUT -i eth0 -s 10.0.0.0/8 -j LOG --log-prefix "IP DROP SPOOF A: "
-A INPUT -i eth0 -s 172.16.0.0/12 -j LOG --log-prefix "IP DROP SPOOF B: "
-A INPUT -i eth0 -s 192.168.0.0/16 -j LOG --log-prefix "IP DROP SPOOF C: "
-A INPUT -i eth0 -s 224.0.0.0/4 -j LOG --log-prefix "IP DROP MULTICAST D: "
-A INPUT -i eth0 -s 240.0.0.0/5 -j LOG --log-prefix "IP DROP SPOOF E: "
-A INPUT -i eth0 -d 127.0.0.0/8 -j LOG --log-prefix "IP DROP LOOPBACK: "
# Принимать все для установленных соединений
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Принимать трафик ssh. Ограничить до известных адресов, если это возможно.
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
#Логирование и сброс всего остального
-A RH-Firewall-1-INPUT -j LOG
-A RH-Firewall-1-INPUT -j DROP
COMMIT

Теперь возможно с тех пор как мы отвечаем на ping'и, сброс трафика вместо его отклонения никого не выставит дураками. Это на самом деле персональное предпочтение. Если вы решите отклонять трафик, вы можете изменить последнюю строку перед COMMIT следующим образом:

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

Противостояние проникновению

С тех пор как вы потратили достаточно своего времени на закаливание системы и ее конфигурацию, хорошая идея - удостовериться в том, что никто не придет, когда вас не будет и не испортит всё. Это актуально для магазинов с множеством администраторов и помогает не спускать глаз с плохих парней. Есть два очень хороших инструмента, встроенных в CentOS для защиты вашей системы. Первый из них - aide. Aide представляет собой что-то вроде растяжки, может быть настроена на периодическую проверку модификаций в хэшах ключевых файлов. Второй - это auditd. Подсистема аудирования в CentOS будет наблюдать за вашей системой в реальном времени, основываясь на правилах, которые вы установите. Она будет логировать все и делать все, что вы ей скажете и возможно даже больше.

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

1. Aide

Вместо того, чтобы заново изобретать колесо и рассказывать вам про конфигурацию aide, вместо этого, пожалуйста, посмотрите этот веб сайт.

<!> С четверга, 1 августа 2013 года, ссылка предоставленная выше больше не работает, но содержимое все еще доступно для обозрения в интернет архиве WayBack Machine.

2. Auditd

Будет написано позже.


2023-09-11 07:23