Безопасность Linux в простых советах

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

Чтобы сервер был безопасен, надо соблюдать ряд действий и правил. Простых и не очень. Опишу все по порядку, а именно:

1. Ставить везде разные и везде сложные пароли

Ну я думаю, зачем это, объяснять не нужно, если с фантазией сложно, можно использовать утилиту pwgen, которая сгенерирует их за Вас.

2. Не использовать стандартные порты

Это, как ни странно, полезно. Многие сканеры уязвимостей ищут их только на определенных портах. Если даже у Вас есть уязвимая служба на другом порту, сканер может ее не определить.

3. Читать и проверять логи

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

4. Не сидеть постоянно под рутом

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

5. Выставлять безопасные права на файлы и папки, владельцев

Также хочу заметить, что не повредит selinux (модуль ядра, разработанный американскими военными для более сложных уровней доступа) и bindfs (можно примонтировать папку, как отдельную файловую систему)

6. chroot'ить все, что можно, что может дать доступ к системе

Черут — это создание окружения с нужными файлами и утилитами, после этой команды корень файловой системы будет именно в этом каталоге, в который вы черутите. Разумеется, там нужны многие системные файлы, но плюсы в том, что Вы можете скопировать только нужные утилиты в папку /bin/ и у людей, закрытых в этой директории будут урезанные возможности, и даже если они что-то натворят, то только в этой папке. Поэтому надо черутить все, что так или иначе может дать доступ к системе, например апач. Многие программы в конфиге позволяют настроить черут для некоторых юзеров. Например пользователей proftpd можно закрыть в любом каталоге и выше него они не подымутся, это делается все также, черутом, но уже без Вашего участия, а автоматически программами.

7. Запускать службы и демоны, которые могут дать доступ к системе, под отдельным пользователем, урезанным в правах

И снова, можно привести пример с апачем. Если в нем найдется уязвимость, то можно будет выполнять команды от юзера, запустившего его, поэтому стоит позаботится об ограничении прав для этого пользователя. В убунте уже есть юзер специально созданный для этого дела — www-data и веб серверы запускаются от его имени.

8. Использовать программы для безопасной работы, фаерволы, блокировщики (iptables, fail2ban и т.п.)

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

fail2ban, к примеру, блокирует пользователей по ssh или другим службам (можно настроить) после некоторых попыток неправильного ввода пароля. Позволяет защититься от перебора паролей автоматически.

Подобных программ много интересных (пишите в каменты, делитесь опытом)

9. Использовать антивирусы

Вирусы в линукс, конечно, не так опасны, но могут причинить вред пользователям, если речь идет о сайте и он заражен. Я использую на своем сервере clamav

10. Отключать неиспользуемые протоколы

Действительно, зачем они нам, если косвенно могут предоставлять опасность? ЛУчше их отключить, например IPv6, если не используем.

11. Дополнительная авторизация для служб, которые вещают в сеть, вешать на https

Яркий пример — phpmyadmin, лучше его повесить на https, чтобы никто не перехватывал трафик с паролями, а также для большей безопасности лучше повесить на дополнительную авторизацию веб сервера (скоро напишу в блоге, как сделать)

12. Ограничить подключения только c localhost, если не планируется подключаться удаленно

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

13. Авторизация ssh по ключу, ограничение доступа

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

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

14. Регулярный бэкап

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

Я сейчас занят тем, что хочу сделать ежедневный полный бэкап и раз в два часа инкрементальный (созданные и измененные файлы за 2 часа). Автоматически заливка образов бэкапа на три других пк и облачный сервис от мамазон (маньяк я, да?). Скрипты пишу свои. Уж лучше будет мой косяк, не могу я доверить сторонним разработчикам свои труды и данные.

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

За материалы спасибо Сергей butteff