Защита Linux-сервера

Оригинал: Securing Linux
Автор: Chris Binnie
Дата публикации: 1 февраля 2016 г.
Перевод: А.Панин
Дата перевода: 18 марта 2017 г.

При настройке нового Linux-сервера следует выполнить несколько дополнительных операций для его защиты от внешних воздействий.

Недавно я арендовал новый облачный сервер взамен моего последнего физического сервера, который практически не использовался. Процесс аренды сервера был достаточно простым, хотя мне пришлось передать информацию о моей кредитной карте хостинг-провайдеру, после чего в течение примерно одной минуты в мое распоряжение был передан новый сервер с предустановленным дистрибутивом Debian 8.1 "Jessie" и статическим адресом IPv4.

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

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

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

Системные службы

После того, как я изменил настройки DNS на своем компьютере для перехода по IP-адресу, предоставленному моим хостинг-провайдером, я сразу же вошел в систему по SSH и изменил пароль пользователя root по своему усмотрению (разумеется, он должен отличаться от того пароля, который был получен в сообщении электронной почты от хостинг-провайдера!). Вообще, я бы посоветовал хостинг-провайдеру предоставлять доступ к предустановленному паролю пользователя root исключительно посредством веб-интерфейса (который доступен по протоколу HTTPS). Электронная почта является слишком небезопасным механизмом передачи данных, а мы настраиваем сервер, который не должен быть скомпрометирован в течение длительного времени. К чести хостинг-провайдера, в случае SSH пользователю сразу же предлагается создать SSH-ключ, который безопаснее обычного пароля.

Сразу же после входа в систему под именем пользователя root по SSH я обратил внимание на одну проблему. Суперпользователь не должен иметь возможности удаленного доступа к системе по SSH при наличии в системе пользователя с более низкими привилегиями, посредством учетной записи которого и должен осуществляться вход в систему. Я разберусь с этой проблемой немного позже.

Первой командой, которую я выполнил, была команда для проверки корректности выделения хостинг-провайдером ресурсов для моей машины. По сути, я проверил объем доступной оперативной памяти с помощью следующей команды:

# free -m

Обратитесь к Рисунку 1, если вас интересует пример вывода команды free -m. Меня же интересовало главным образом первое значение в столбце "used", на основании которого несложно сделать вывод, что для загрузки моей системы под управлением Debian с малым количеством системных служб потребовалось всего 93 МБ оперативной памяти (сравните это сотнями мегабайт, необходимыми для загрузки свежеустановленной системы Windows).

Рисунок 1: Проверка объема доступной оперативной памяти с помощью команды free -m.

Кроме того, при рассмотрении данного вывода можно обнаружить объем свободной оперативной памяти, а именно значение 401 МБ в столбце "free", на основе которого несложно сделать вывод о том, что в мое распоряжение действительно был предоставлен сервер с 512 МБ оперативной памяти. Этой оперативной памяти вполне хватит для моих целей, так как Linux является крайне эффективной системой.

Далее я приступил непосредственно к выполнению мероприятий по защите сервера. На данном этапе я решил отключить все системные службы, которые используют доступные из сети Интернет порты; единственным исключением должна была стать служба сервера SSH. Для этой цели я выполнил следующую команду:

# lsof -i | grep LISTEN

В результате я обнаружил в левой части вывода имена системных служб (обычно совпадающие с именами файлов из директории /etc/init.d), а в правой - открытые сетевые порты. Номера этих портов обычно заменяются на названия служб, приведенные в файле /etc/services.

Я сразу же обратил внимание на две не нужные мне системные службы (потенциально связанные с различными рисками в плане безопасности системы), которые следовало бы отключить. После непродолжительных исследований системы стало ясно, что за управление состоянием первой службы отвечает сценарий /etc/init.d/rpcbind, но ввиду того, что система инициализации init уже в прошлом, я воспользовался возможностями Systemd посредством следующей команды:

# systemctl stop rpcbind

после которой следует выполнить еще одну команду для того, чтобы служба rpcbind не запускалась после перезагрузки системы:

# systemctl disable rpcbind

Далее я обнаружил еще один открытый порт, связанный с системной службой nfs-common, которую тоже пришлось отключить путем исполнения двух предыдущих команд с заменой rpcbind на имя этой службы.

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

# lsof -i | grep LISTEN | awk '{print $1,$3}'
rpcbind rpc
master root
sshd root
httpd root
httpd apache

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

Ssshhhh!

На следующем шаге я решил изменить стандартный номер порта 22 сервера SSH под названием sshd. Для этого следует отредактировать файл конфигурации /etc/ssh/sshd_config с особой осторожностью, раскомментировав первую представленную на Рисунке 2 строку и заменив значение 22 на любой желаемый номер порта, например, 2222. Данная манипуляция позволит защититься от автоматизированных атак на порт 22 вашего сервера.

Рисунок 2: В файле конфигурации следует заменить номер порта 22 на другой номер, к примеру, 2222 или любой другой произвольный номер порта после раскомментирования строки путем удаления первого символа решетки.

Вы также можете запретить пользователю root осуществлять удаленный доступ к системе, о чем упоминалось ранее. Для этого достаточно заменить значение параметра PermitRootLogin на no:

PermitRootLogin no

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

AllowUsers lionel, luis, neymar

Теперь лишь три перечисленных пользователя смогут удаленно входить в систему по SSH. Необходимо создать учетные записи этих пользователей перед выходом из системы или перезапуском сервера OpenSSH, иначе вы не сможете администрировать свой сервер. Для создания учетных записей пользователей достаточно выполнять аналогичные команды и отвечать на задаваемые системой вопросы:

# adduser lionel

Дополнительные модификации файла конфигурации сервера SSH могут быть осуществлены в будущем (но вам наверняка придется осуществить их и разобраться с их последствиями). Для перезапуска службы sshd достаточно выполнить следующую команду:

# systemctl restart ssh

Для того, чтобы развеять все сомнения в корректности конфигурации, я быстро проверил возможность входа в систему по SSH и заглянул в журнал Systemd для ознакомления с возможными сообщениями об ошибках (для этого достаточно выполнить команду journalctl -a и изучить несколько последних строк). Я все еще не привык к форматированию вывода журнала Systemd, но, так как в выводе не было каких-либо сообщений, связанных с внесенными мною изменениями, я посчитал, что у сервера SSH не возникло каких-либо проблем с новой конфигурацией.

На следующем шаге я открыл файл /etc/hosts.allow и немного отредактировал параметры стека TCP, удалив все незакомментированные строки и добавив IP-адреса, с которых я буду соединяться с сервером:

sshd: 11.22.33.44, 123.123.123.123, 9.8.7.6

Теперь по SSH в систему смогут входить лишь клиенты с тремя перечисленными IP-адресами, причем ими должны использоваться перечисленные выше имена пользователей, такие, как lionel. После этого я добавил следующую строку в файл hosts.deny:

sshd: ALL

И на этом настройка сервера SSH может считаться оконченной. Помните о том, что нельзя закрывать окно с первой открытой сессией SSH, пока вы протестируете возможность входа в систему с использованием новых параметров.

История команд

Мне неудобно использовать сочетание клавиш Ctrl+R для обратного поиска в истории команд командной оболочки, поэтому я предпочитаю активировать клавиши PageUp и PageDown. Данное действие никак не связано с безопасностью сервера, но позволяет более эффективно перемещаться по истории команд.

На Рисунке 3 приведены две строки файла конфигурации /etc/inputrc, которые следует раскомментировать. Для того, чтобы изменения вступили в силу, нужно всего лишь дождаться следующей перезагрузки системы; данная функция не особо важна, пока вы не выполните большое количество команд.

Рисунок 3: Оптимизируйте скорость ввода команд путем активации клавиш PageUp и PageDown.

Дом, милый дом

Не во всех существующих дистрибутивах уделяется должное внимание правам доступа к данным, размещенным в домашних директориях пользователей. Предположим, что я работаю с учетной записью пользователя lionel и не хочу, чтобы пользователи Luis и Neymar имели возможность просматривать файлы из моей домашней директории. Для того, чтобы другие пользователи не имели возможности доступа к моей домашней директории достаточно выполнить следующую команду от лица пользователя root:

# chmod -R 750 /home/lionel

Если вы хотите защитить аналогичным образом все домашние директории пользователей, просто замените lionel на символ звездочки.

Эй, почтальон!

На следующем шаге я настрою утилиту logwatch [1] для отправки ежедневного дайджеста важных событий из системных журналов по электронной почте. Имейте в виду, что по окончании данного процесса в вашей системе появится полнофункциональный SMTP-сервер. Предупреждаю, что я буду описывать последовательность выполняемых действий максимально кратко; рекомендую вам читать инструкции по нескольку раз, если вы не уверены в том, что делаете.

Сразу же после установки почтовый сервер Postfix является полнофункциональным. В процессе его конфигурации вам придется лишь выбрать вариант "Internet Site" и ввести полное имя узла (включая FQDN, то есть, полностью определенное имя домена). Чуть позже вы сможете изменить содержимое классического, также используемого в Sendmail файла конфигурации /etc/aliases для отправки предназначающейся пользователю root почты на ваш адрес электронной почты.

Вы можете установить Postfix с помощью следующей команды:

# apt-get install postfix

Далее нужно отредактировать файл конфигурации aliases, добавив в него ваш адрес электронной почты для приема сообщений, предназначенных для пользователя root:

# pico -w /etc/aliases

Убедитесь в том, что начинающаяся с root: строка этого файла конфигурации выглядит аналогичным образом:

root: chris@binnie.tld

Обновите базу данных адресов электронной почты Postfix с помощью команды newaliases:

# newaliases

Наконец, установите пакет программного обеспечения Logwatch; сразу же после установки данная утилита будет корректно функционировать:

# apt-get install logwatch

Простейший способ вызова утилиты Logwatch заключается в создании файла задачи cron в стандартной директории cron.daily для ежедневного исполнения в заданное время, например, в 06:25, как в моей системе Jessie 8.1. Добавьте время исполнения задачи в файл /etc/crontab или переместите файл /etc/cron.daily/00logwatch в какую-либо другую директорию и вызывайте его в другое время из файла /etc/crontab.

После этого запустите Logwatch вручную и проверьте входящую почту:

# /etc/cron.daily/00logwatch

Результаты должны поразить вас. Если же вас интересуют все аспекты процесса мониторинга системных журналов с помощью Logwatch, вы сможете найти дополнительную информацию в статье из журнала ADMIN Magazine [2].

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

Список пакетов программного обеспечения также предусмотрительно разделен на категории Installed (Установленные), Upgraded (Обновленные) и Removed (Удаленные). Я считаю данные списки, отправляемые в рамках сообщений с темой "Logwatch for <имя узла> (Linux)" на мой адрес электронной почты чрезвычайно важными для последующих исследований.

Если вы обнаружите несоответствия между версиями или функциями программного обеспечения на двух серверах, вам придется потратить лишь пару секунд на поиск различий в версиях пакетов программного обеспечения и параметрах их сборки. Если вы не хотите, чтобы сообщения отправлялись пользователю root и переадресовывались в ваш почтовый ящик с помощью директивы в файле конфигурации aliases, вы можете добавить директиву MailTo = с вашим адресом электронной почты в качестве параметра в файл конфигурации /etc/logwatch/conf/logwatch.conf. Возможно, вам придется создать этот файл конфигурации вручную, если его не существует.

Я не буду останавливаться на важном вопросе защиты вашего нового SMTP-сервера. Даже учитывая отключенную по умолчанию функцию ретрансляции, вам придется выполнить несколько дополнительных действий для защиты SMTP-сервера. На веб-сайте Ask Ubuntu размещено полезное сообщение с описанием мероприятий по защите почтового сервера Postfix [3].

Пароли

Я рассчитываю на то, что системой будут пользоваться еще несколько человек (не являющихся администраторами), поэтому стоит рассмотреть вопрос безопасных паролей. Если вы когда-либо сталкивались со списками стандартных паролей вы наверняка догадываетесь, почему системные администраторы не стремятся предоставлять доступ к обслуживаемым серверам обычным пользователям [4].

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

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

Следующая конфигурация отлично работала в моей системе Debian "Wheezy". В первую очередь следует установить пакет программного обеспечения libpam-cracklib:

# apt-get install libpam-cracklib

После этого следует отредактировать следующий файл конфигурации:

# pico -w /etc/pam.d/common-password

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

password requisite pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=2 ocredit=2

Описанная защищенная конфигурация позволяет пользователю допустить лишь две ошибки при вводе пароля и требует использования пароля как минимум из 10 символов.

Моим любимым параметром (который очень надоел коллегам) является параметр difok=6, позволяющий повторно использовать лишь шесть символов последнего пароля в новом пароле, причем в этом пароле должны присутствовать как минимум две цифры и два символа (или "специальных символа"). Для активации описанной конфигурации в Wheezy достаточно было выполнить следующую команду:

# pam-auth-update

После этого вы можете протестировать новую конфигурацию, проявляя особую осторожность, так как при неудачном стечении обстоятельств вы не сможете войти в систему под своим именем. Если вы столкнетесь с проблемами в процессе тестирования, вам нужно будет в первую очередь убедиться в наличии параметра UsePAM с значением yes в файле конфигурации /etc/ssh/sshd_config. В случае добавления этого параметра в файл конфигурации вам придется перезапустить системную службу OpenSSH с помощью команды systemctl restart ssh.

Таблица 1 содержит описания полезных параметров, позволяющих ужесточить правила установки паролей, со страницы руководства pam_cracklib, относящейся к программному компоненту libpam-cracklib. Поэкспериментируйте с данными параметрами до достижения оптимальной конфигурации.

Таблица 1. Параметры проверки паролей с помощью Cracklib

Если вы хотите получить опыт конфигурирования Cracklib, вы можете внести коррективы в файл конфигурации для использования собственных словарей паролей. Также вы можете найти в сети довольно старый, но отлично оформленный пример использования Cracklib в Django [5].

Другие идеи

После выполнения описанных выше действий я задумался над тем, как осуществлять мониторинг состояния файловой системы. Вы можете создать файл с контрольными суммами MD5 ключевых файлов для последующей проверки в случае подозрений на компрометацию сервера. Также вы можете установить специальный инструмент для проверки целостности файлов, например, утилиту AIDE (Advanced Intrusion Detection Enviroment), позволяющую отслеживать все изменения файловой системы.

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

Другой интересный подход к защите вашей системы заключается в использовании механизма скрытия портов (port knocking) [6]. Этот механизм позволяет вам закрыть порт сервера SSH для внешнего мира - вы сможете даже заблокировать пинг-пакеты и сделать свой сервер полностью невидимым. После его использования единственным способом получения доступа к серверу SSH будет соединение с предварительно заданной последовательностью портов.

Если вы предоставляете пользователям своей системы возможность организации удаленного доступа к файлам посредством протокола SFTP, вам придется ограничить возможность перемещения по файловой системе рамками домашних директорий и запретить исполнение некоторых системных команд. Для этого просто придется активировать поддержку chroot в вашем SFTP-сервере [7].

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

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

Этот процесс никогда не заканчивается

Разумеется, вопросы безопасности не ограничиваются корректной настройкой сервера. Я мог бы рассказать гораздо больше о настройке вашего сервера, попутно затронув другие элементы сети. Как насчет проверки на наличие в системе опасных исполняемых файлов с битами setuid? Да, вам стоит ограничить количество исполняемых файлов с правами доступа, предполагающими запуск процесса с привилегиями инициирующего этот запуск пользователя.

Попытайтесь использовать данную команду, если вас беспокоит этот вопрос:

# find / -xdev \( -perm -4000 \) -type f -print0 | xargs -0 ls -hal

С помощью данной команды вы можете найти в системе все файлы с правами доступа 4000 или битом SUID (который отображается с помощью буквы s в блоке прав доступа листинга содержимого директории). Вы можете застраховаться от неприятных сюрпризов, причиной которых может оказаться файл с маркировкой "s", следующим образом:

# chmod -s /home/chrisbinnie/nasty_file

Для дополнительной защиты файловой системы я мог бы порекомендовать использовать технологию SELinux. Но в этом случае придется примерить роль секретного агента и заглянуть в рекомендации Агентства национальной безопасности США [10].

В случае установки на рассматриваемый сервер веб-сервера Apache я бы сразу же скрыл содержимое директории cgi-bin и изменил значение параметра ServersTokens на Prod. Также настоятельно рекомендую прочитать отличную статью на веб-сайте Geekflare с рекомендациями по защите веб-сервера Apache [11].

Длинный список проверок безопасности едва ли когда-либо закончится. Если вы хотите ознакомиться с дополнительной информацией по теме, вы можете обратиться к руководству по OpenSCAP от сотрудников Национального института стандартов и технологий США [12]. OpenSCAP осуществляет "автоматическую проверку наличия патчей, проверку безопасности параметров конфигурации, а также выявление признаков компрометации системы".

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

Источники дополнительной информации

1. Logwatch: http://www.logwatch.org/
2. "Lean on Logwatch" за авторством Chris Binnie, ADMIN, выпуск 25, 2015: http://www.admin-magazine.com/Archive/2015/25/Lean-on-Logwatch/%28language%29/eng-US
3. How to Secure Postfix on Ubuntu Server: http://askubuntu.com/questions/418340/how-to-secure-postfix-on-ubuntu-server
4. "Revealed: The Top 25 Most Common Passwords": http://news.sky.com/story/1412124/revealed-the-top-25-most-common-passwords
5. "Using Cracklib to Require Stronger Passwords": http://thegarywilson.com/blog/2006/using-cracklib-to-require-stronger-passwords/
6. "Protect Your Network with Port Knocking" за авторством Chris Binnie, ADMIN, выпуск 23, 2014: http://www.admin-magazine.com/Archive/2014/23/Port-Knocking
7. "Limiting Access with SFTP Jails on Debian and Ubuntu": https://www.linode.com/docs/tools-reference/tools/limiting-access-with-sftp-jails-on-debian-and-ubuntu
8. Bastille Linux: http://bastille-linux.sourceforge.net/
9. Lynis: https://cisofy.com/lynis/
10. NSA Guide for Secure OS Configuration: https://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/operating_systems.shtml
11. "Apache Web Server Hardening and Security Guide": http://geekflare.com/apache-web-server-hardening-security/
12. OpenSCAP Portal: http://www.open-scap.org/page/Main_Page

http://rus-linux.net/MyLDP/server/securing-server-debian.html