Cервера под управлением OS семейства Linux стабильны в работе, гибки в настройке, и менее подвержены взлому. Это действительно так, при условии, что администратор уделил время обеспечению безопасности сервера. Ни одна статья о настройке безопасности Linux не может претендовать на всеобъемлемость, этому вопросу можно посвятить доброе многотомное книжное издание. В этой статье мы рассмотрим необходимый минимум рекомендаций, взяв во внимание которые, администратор может существенно защитить свой сервер от злоумышленника.
Оглавление:
- Сложность пароля
- Безопасность SSH соединения
- Настройка Fail2ban
- Настройка firewall
- Настройка NTP сервера
- Аудит безопасности Linux систем
- Своевременное обновление ПО
1. Сложный пароль.
Сложность пароля играет большую роль. Это первый барьер перед злоумышленником для защиты информации от несанкционированного доступа. Он должен состоять не менее из 12 символов для учетных записей администрирования сервера, и не менее 8 символов для пользователей. Он может состоять из строчных латинских букв, заглавных латинских букв, цифр и спецсимволов («!», «@», «#», «$», «%», «^», «&», «*», «(», «)», «_», «+», «?»). Пример плохого пароля: dima1234. Пример хорошего пароля: DM!t84riY#. Защита сервера должна иметь комплексный характер, сложные пароли необходимо ставить так же и пользователям, которые пользуются сервисами, которые Вы им предоставляете.
Рассмотрим довольно распространенный пример и последствия. Пароль администратора сложный. Но пароли пользователей, которые этот сервер используют - легкие. Как правило это касается почтового сервера. Пароли должны быть сложные и не быть созвучными с названием почтового ящика пользователя. Логика обычно простая: отдельным пользователям трудно запомнить сложные пароли и администратор идет на уступки. Обычно это заканчивается взломом почтового ящика, рассылкой спама от имени взломанного почтового ящика, попаданием ip адреса почтового сервера во внешние базы «спамеров» (black-list), в следствие чего почтовый сервис парализован для всей организации, что негативно влияет на функционирование всего бизнес-процесса. Это же касается FTP пользователей, паролей на сайт, базы данных и другие сервисы.
2. Безопасность SSH соединения.
Прежде чем мы перейдем к настройке безопасности, установим openssh-server и рассмотрим пути к конфигурационным файлам и каталогам, которые нам понадобятся.
root@host:~$ sudo apt-get install openssh-server
Файлы конфигурации:
/etc/ssh/sshd_config - главный конфигурационный файл openssh
~/.ssh/ - каталог с пользовательскими настройками
~/.ssh/authorized_keys - файл с ключами RSA для удаленного подключения
/etc/hosts.allow и /etc/hosts.deny — файлы для ограничения и разрешения сетевого доступа
Перед настройкой ssh службы скопируем наш главный конфигурационный файл настроек, чтобы в случае ошибок всегда можно было вернуться к исходному состоянию, и приступим к его редактированию:
root@host:~$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.default root@host:~$ sudo vim /etc/ssh/sshd_config
По умолчанию, за службой SSH зарезервирован порт 22, и обычно для подключения к удаленному серверу используется команда:
root@host:~$ ssh root@remote_host
Первым делом изменим стандартный порт для подключения. Для этого нам нужно найти строку «port» в файле sshd_config. Если перед значением предшествует знак комментария (#), удалите спецсимвол # и укажите свой порт. В примере мы будем использовать порт 2303. Вторая строка говорит нам о том, что сервер принимает подключение для всех ip адресов IPv4, третья строка - что использование IPv6 запрещено.
Port 2303 ListenAddress 0.0.0.0 #ListenAddress ::
Выполнив эту настройку, порт SSH для злоумышленника будет неизвестен и для удаленного подключения мы будем использовать следующую команду:
root@host:~$ ssh root@remote_host -p 2303
Опционально рассмотрим так же другие полезные параметры sshd_config.
PermitRootLogin yes - Разрешает вход в систему под суперпользователем root. Пользователь root является целью #1 для хакера, потому не будет лишним запретить вход на сервер под суперпользователем выставив значение no. Выполнив эту настройку, войти на сервер можно будет под любым другим предварительно созданным пользователем. Переключение в консоль пользователя root можно будет выполнив команду su, которая запросит пароль пользователя root. Для PermitRootLogin доступны таки события: вход для пользователя root разрешен («yes»), вход для пользователя root запрещен («no»), авторизация для root запрещена по паролю, но разрешена для входа по открытому ключу («without-password»), последнее мы рассмотрим ниже.
AllowUsers - Возможность подключиться к серверу с помощью root мы отключили, отлично. Однако на сервер можно подключиться под любым другим логином, что так же можно ограничить. Особенно это актуально, если на сервере несколько учетных записей. По умолчанию AllowUsers отсутствует в конфигурационном файле, потому её нужно добавить отдельной строкой, перечислив через пробел всех пользователем которым разрешено подключаться по SSH.
DenyUsers - аналогично, через пробел перечисляем пользователей которым запрещено авторизироваться на сервере, руководствуясь принципом «Разрешено всем, кроме тех кому запрещено». Если Вы используете AllowUsers, то параметр DenyUsers не обязателен.
SyslogFacility AUTH - Удаляем перед строкой комментарий (#) и оставляем AUTH, это позволит журналировать все события отвечающие за авторизацию на сервере в /var/log/auth
LogLevel INFO - Удаляем перед строкой комментарий (#) и оставляем уровень детализации событий для записи в журнал (/var/log/auth.log) по умолчанию. В случае необходимости, вы всегда можете повысить уровень детализации событий выбрав другой уровень детализации: SILENT, QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, DEBUG3
PubkeyAuthentication yes - Директива должна быть включена, потому удаляем комментарий (#) перед ней. Она позволяет проводить аутентификацию по открытом ключу.
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 — Так же удаляем комментарий (#). Этим мы указываем стандартные пути к открытым ключам для ssh соединения.
Теперь внимательно проверяем все свои правки, иначе рискуем потерять связь со своим сервером, и перезагружаем демон sshd:
root@host:~$ systemctl sshd restart
Следующим этапом рассмотрим организацию доступа к серверу по открытым ssh-ключам. SSH-ключ является более защищенным вариантом подключения к серверу, чем использование обычного пароля.
Первым делом, на клиентской машине, с которой вы планируете подключаться к серверу, мы сгенерируем пару открытых ключей следующей командой:
root@host:~$ ssh-keygen -t rsa
Для генерации ключей достаточно несколько раз нажать клавишу Enter, игнорируя варианты которые предлагаются. Однако для опытных пользователей, во время генерации ключа будет предложено ввести секретный пароль (Enter passphrase (empty for no passphrase): ). Это существенно повысит безопасность вашего соединения, но будьте готовы вводить этот пароль каждый раз при подключении к серверу. Использование секретного пароля к ключу сделает невозможным использование ключа третьими лицами в случае его кражи.
Процесс генерации ключа выклядит следующим образом:
root@host:~$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/username/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/username/.ssh/id_rsa. Your public key has been saved in /home/username/.ssh/id_rsa.pub. The key fingerprint is: 80:5d:6f:c7:39:9a:5g:da:48:26:8d:59:22:6d:63:34 username@hostname The key's randomart image is: +--[ RSA 2048]----+ | Oo+o | | . +oE= | | o + * = . E | | . = + . | | * S *.* | | o . o.o + | | . S | | *.*+ | | | +-----------------+
Мы только что создали зашифрованную пару ключей. Открытый ключ хранится в файле /home/username/.ssh/id_rsa.pub, закрытый - /home/username/.ssh/id_rsa. Если Вы эту операцию делали под пользователем root, то расположение ключей будет следующее: открытый ключ хранится в файле /root/.ssh/id_rsa.pub, закрытый - /root/.ssh/id_rsa.
Для того, чтобы мы могли подключаться на сервер по ключу без использования пароля, необходимо ключ который храниться в файле id_rsa.pub скопировать на сервер в ~/.ssh/authorized_keys. Где тильда («~») - домашний каталог пользователя.
Копирование ключей в текстовом виде неудобно и неправильно, воспользуемся утилитой ssh-copy-id:
root@home-host:~$ cd .ssh root@home-host:~$ ssh-copy-id -i id_rsa.pub username@serverhost
Если вы следовали рекомендациям выше, и сменили стандартный порт ssh с 22 на 2303, тогда при использовании утилиты ssh-copy-id необходимо указать этот порт:
root@home-host:~$ ssh-copy-id " -p 2303 -i id_rsa.pub username@serverhost "
Обратите внимание, если на клиентском ПК и сервере есть пользователь dmitry, для которого сгенерирование пара ключей, то авторизироваться на сервере можно будет не вводя логин, в терминале клиентской машины достаточно ввести:
root@home-host:~$ ssh xxx.xx.xxx.xx
где xxx.xx.xxx.xx — ip вашего сервера.
3. Настройка Fail2ban.
Fail2ban - это бесплатная популярная программная платформа с открытым исходным кодом, разработанная для предотвращения вторжений, которую можно использовать для защиты вашего сервера от атак методом перебора. Подробнее о настройке Fail2ban вы можете ознакомиться в нашей статье «Защита сервера средством утилиты Fail2ban».
4. Настройка firewall.
В нашем примере мы будем использовать Debian10, где по умолчанию, в качестве фаервола, используется iptables. Это довольно гибкая утилита с множеством настроек и она заслуживает отдельной статьи, которая обязательно появится позже. Сейчас же мы рассмотрим UFW, это удобный пользовательский интерфейс iptables. Он имеет более дружественный интерфейс для понимания, если вы начинающий администратор linux систем, и в то же время несет в себе полный функционал для администрирования опытными пользователями.
Внимание! Рекомендации подразумевают, что вы устанавливаете firewall на чистый сервер. Если у вас сервер уже использует множество настроенных сервисов, предварительно необходимо провести их аудит и иметь четкое представление, какие разрешения для них необходимы, определиться с политиками заранее. Иначе вы рискуете сделать некоторые сервисы неработоспособными.
Первым делом установим его:
root@host:~$ sudo apt-get update root@host:~$ sudo apt install ufw
Внимание! Прежде чем перейти к настройке, разрешим доступ по ssh, чтобы не потерять возможность удаленного управления сервером:
root@host:~$ sudo ufw allow ssh
Если вы следовали рекомендациям из раздела «Безопасность SSH соединения» и для SSH изменили стандартный порт, например, на 2303, тогда команда будет иметь следующий вид:
root@host:~$ sudo ufw allow 2303/tcp
После установки фаервола, по умолчанию он выключен. Добавив правило доступа по SSH, вы можете включить брандмауэр. Включить\выключить его можно командами:
root@host:~$ sudo ufw enable root@host:~$ sudo ufw disable
Проверить состояние брандмауэра:
root@host:~$ sudo ufw status verbose
Следует так же учесть, что изначально, фаервол UFW разрешает все исходящие соединения с сервера, но блокирует входящие, пока они не будут разрешены. Политики фаервола находятся в файле /etc/default/ufw
Если что-то пошло не так, вы всегда можете всегда вернуться к первоначальному состоянию брандмауэра двумя командами:
root@host:~$ sudo ufw default deny incoming root@host:~$ sudo ufw default allow outgoing
Приступим к настройке правил для других соединений. Настройка не представляет сложности. В зависимости от нужд, используем allow если нужно открыть порт, и deny, если его нужно закрыть. Например, откроем порт 80 (http) и 443 (https)
root@host:~$ sudo ufw allow 80 root@host:~$ sudo ufw allow 443
Если наше приложение использует определенный диапазон портов, это можно сделать следующим способом:
root@host:~$ sudo ufw allow 4000:4007/tcp
UFW позволяет для удобства визуализировать службы по профилям и редактировать их. Введите команду
root@host:~$ sudo ufw app list
Мы увидим список профилей. Их количество может варьироваться, на чистом сервере мы можем увидеть не более профиля OpenSSH. Вывод будет примерно следующий:
Apache Apache Full OpenSSH Postfix HTTP HTTPS ……
Ранее мы открыли порты 80 и 443. UFW позволяет управлять доступами так же по профилям. Аналогичные команды будут выглядеть следующим образом:
root@host:~$ sudo ufw allow http root@host:~$ sudo ufw allow https
Посмотреть детальную информацию о профиле можно командой:
root@host:~$ sudo ufw app info OpenSSH Profile: OpenSSH Title: Secure shell server, an rshd replacement Description: OpenSSH is a free implementation of the Secure Shell protocol. Ports: 22/tcp
Все профили хранятся в следующей директории /etc/ufw/applications.d
Мы можем управлять профилями, редактировать их и добавлять свои. Например у нас есть приложение myapp и мы для удобства хотим создать его профиль. Для этого нужно перейти в упомянутую выше директорию и создать командой touch
root@host:~$ cd /etc/ufw/applications.d root@host:~$ sudo touch myapp root@host:~$ sudo vim myapp
Отредактируйте файл, добавив следующую информацию:
[myapp] title=my super app description=my super app for NASA. ports=80,2177,14312:14487/udp
Сохраните файл и перезапустите брандмауэр
root@host:~$ sudo ufw reload
Ниже мы рассмотрим наиболее часто используемые команды. Для разрешение используем параметр allow, для запрета deny.
Разрешить порт\протокол:
root@host:~$ sudo ufw allow 7743/tcp
Разрешить диапазон портов:
root@host:~$ sudo ufw allow 4000:4007/tcp
Разрешить с определенного ip адреса доступ по всем портам:
root@host:~$ sudo ufw allow from xxx.xx.xxx.xx
Разрешить с определенного ip адреса доступ к FTP:
root@host:~$ sudo ufw allow from xxx.xx.xxx.xx to any port 21
мы так же можем разрешить доступ для целой подсети по всем портам:
root@host:~$ sudo ufw allow from xxx.xx.xxx.xx\24
...или по определенному:
root@host:~$ sudo ufw allow from xxx.xx.xxx.xx\24 to any port 21
Допустим у нас есть два сетевых интерфейса, eth0 и eth1, перед нами стоит задача открыть порт ftp только для сетевого интерфейса eth1:
root@host:~$ sudo ufw allow in on eth1 to any port 21
Чтобы разблокировать весь трафик HTTP для eth1, введите:
root@host:~$ sudo ufw allow in on eth0 to any port 80
Откроем порт MySQL для интерфейса eth1:
root@host:~$ sudo ufw allow in on eth1 to any port 3306
Предположим, что UFW у нас настроен, но потребовалась задача внести правки. Для этого нам необходимо сначала вывести пронумерованный список правил:
root@host:~$ sudo ufw status numbered
… и удалить правило по его номеру (где N - номер правила):
root@host:~$ sudo ufw delete N
… или удалить его следующим образом:
root@host:~$ sudo ufw delete allow 21 root@host:~$ sudo ufw delete allow ftp
сбросить все правила можно следующей командой:
root@host:~$ sudo ufw reset
UFW поддерживает логирование. Чтобы включить журнал событий:
root@host:~$ sudo ufw logging on
В зависимости от задач, мы можем указать уровень детализации, например:
root@host:~$ sudo ufw logging low
Существуют следующие уровни детализации: off, low, medium, high, full. Чтобы исключить неконтролируемое увеличение логов фаервола, не забудьте настроить для него logrotate. Логи брандмауэра находятся по следующему пути: /var/log/ufw*
Полезной командой при настройке брандмауэра является команда nestat, с помощью которой вы можете отобразить все активные сетевые подключение к вашему серверу:
root@host:~$ netstat -tulpn
5. Настройка NTP сервера.
Забегая вперед, стоит заметить, что в свежих версиях ntpd, начиная с версии 4.2.7, выполнение команды monlist отключено. Однако, если вы давно не обновляли программное обеспечение, рекомендуем выполнить анализ установленного п.о. Так же в этом разделе будут даны общие рекомендации по безопасности NTP.
От точности синхронизации времени зависит корректная работа большинства приложений, однако, для его корректно работы необходимо выполнить некоторые действия по защите NTP сервера от DDoS-атаки NTP-amplification. Суть атаки заключается в следующем: Злоумышленник сканирует и находит общедоступные серверы времени NTP и начинает передачу данных по UDP протоколу . Злоумышленник отправляет запрос на NTP-сервер, но свой IP-адрес заменяет поддельным IP-адресом. Другими словами, Ваш сервер невольно становится промежуточным звеном. Следующим этапом, злоумышленник увеличивает трафик, чем перегружает сеть жертвы до критического состояния, пока она не станет недоступной.
Для установки NTP сервера в Debian достаточно ввести команду:
root@host:~$ sudo apt install ntp
Если вы используете Centos:
root@host:~$ sudo yum install ntp
Если NTP установлен, очень желательно обновить его версию до 4.2.8p10. Ntpd до версии 4.2.7 подвержены атаке. Проверить текущую версию:
root@host:~$ ntpd -version
Затем приступим к редактированию файла конфигурации сервера NTP:
root@host:~$ vim /etc/ntp.conf
Если у Вас уже установлен сервер NTP и по какой-то причине вы не можете его обновить до версии 4.2.7+, запрещаем выполнение REQ_MON_GETLIST и REQ_MON_GETLIST_1.
disable monitor
Если NTP-сервер обслуживает клиентов – разрешаем запрос времени (не изменение):
restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1
Проверяем серверы синхронизации, они могут отличаться в зависимости от вашего региона:
server 0.europe.pool.ntp.org server 1.europe.pool.ntp.org server 2.europe.pool.ntp.org server 3.europe.pool.ntp.org
Настройкой restrict мы указываем, что серверы NTP обслуживают только клиентов NTP в #подсети 192.168.1.0/24, вам необходимо указать свою подсеть, или несколько доверенных подсетей. Подсети указываются с новой строки. Допустимо указать так же определенный ip адрес.
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap nopeer
Перезапустите службу и добавьте её в автозагрузку:
root@host:~$ systemctl restart ntpd root@host:~$ systemctl enable ntpd
Если Вы не используете IPv6, отключите это в /etc/sysctl.conf добавив следующую строку:
net.ipv6.conf.all.disable_ipv6 = 1
и выполните перезагрузку:
root@host:~$ sudo sysctl -p /etc/sysctl.conf
6. Аудит безопасности Linux систем.
Процедуру обнаружения вредоносного содержимого в скриптах сайта средствами ClamAV и Linux Malware Detect мы рассматривали в статье "Проверка сайта на наличие вредоносного кода с помощью Linux Malware Detect и ClamAV"
В этой мы рассмотрим ещё один инструмент, с помощью которого можно выявить уязвимости - Lynis. Это инструмент аудита безопасности UNIX-подобных систем, таких как Linux, macOS, BSD и Solaris. Он выполняет углубленное сканирование безопасности самой системы с целью выявления проблем и предоставления советов по дальнейшей оптимизации системы. Он также будет сканировать общую системную информацию, уязвимые программные пакеты и возможные проблемы конфигурации.
Установка сложности не представляет, необходимо выполнить следующие команды:
root@host:~$ cd /opt/ root@host:~$ sudo wget https://downloads.cisofy.com/lynis/lynis-2.7.5.tar.gz root@host:~$ sudo tar xzvf lynis-2.7.5.tar.gz root@host:~$ sudo mv lynis /usr/local/ root@host:~$ sudo ln -s /usr/local/lynis/lynis /usr/local/bin/lynis root@host:~$ sudo lynis audit system
Вы увидите подробный анализ вашей операционной системы и её узкие места, на которые следует обратить внимание.
Lynis не является антивирусом в класическом понимании, потому свежие версии выходят не часто. С ними вы можете охнакомиться по ссылке https://downloads.cisofy.com/lynis/
Тем не менее, Lynis является дополнительным инструментом, который можно взять на вооружение.
7. Своевременное обновление ПО.
Обновление системы является важной процедурой. Разработка программного обеспечения не стоит на месте, и именно в новых версиях исправляются множество ошибок, а так же устраняются возможные уязвимости. Рекомендуется регулярно читать различного рода новости IT сообществ, чтобы в случае обнаружения критических уязвимостей оперативно отреагировать и обвить свое программное обеспечение.
Внимание! Перед глобальным обновлением системы рекомендуется проанализировать существующие зависимости. Необдуманное обновление всей системы, или отдельных библиотек, может привести к неработоспособности ваших служб. В частности это касается обновления библиотек и компонентов от которых зависит работа ваших сайтов, например php. Downgrade (возвращение к предыдущим версиям) может оказаться довольно трудоемким процессом.
Все без исключения обновления и установка приложений осуществляется из репозиториев. Репозиторий является хранилищем файлов и пакетов, доступных к скачиванию по сети. Существуют официальные и неофициальные репозитории. Официальные версии программного обеспечения которым можно доверять. Кроме официальных, существуют так же множество не официальных репозиториев, которые поддерживают отдельные разработчики своего программного обеспечения, но которое не вошло в официальный релиз. Устанавливать п.о. из не официальных репозиториев следует осторожно и только в случае необходимости.
Список репозиториев доступно по следующему пути:
root@host:~$ sudo vim /etc/apt/sources.list
Ниже приведен пример файла sources.list для Debian 9/Stretch.
deb http://deb.debian.org/debian/ stretch main deb-src http://deb.debian.org/debian/ stretch main deb http://deb.debian.org/debian/ stretch-updates main deb-src http://deb.debian.org/debian/ stretch-updates main deb http://security.debian.org/debian-security/ stretch/updates main deb-src http://security.debian.org/debian-security/ stretch/updates main
Для Debian10:
deb http://deb.debian.org/debian buster main deb http://deb.debian.org/debian buster-updates main deb http://security.debian.org/debian-security buster/updates main
В Debian все просто, необходимо в этот файл скопировать список репозиториев из официальных источников.
Для CentOS процедура несколько иная. Список репозиториев будет другой. Настройку CentOS следует начинать из установки дополнительных пакетов для Red Hat:
root@host:~$ sudo yum install epel-release
После чего мы сможем посмотреть список активных репозиториев командой:
root@host:~$ sudo yum repolist
Рассмотрим пример обновления системы под управлением Debian. Обновление системы или её отдельных компонентов начинается с update списка доступных пакетов. Это важная команда, которую следует выполнять перед любым обновлением:
root@host:~$ sudo apt-get update
Если Вы желаете обновить все без исключения доступные пакеты:
root@host:~$ sudo apt-get upgrade
Приведенная выше команда предоставит общую информацию, какие пакеты будут обновлены, какие удалены, общее количество пакетов. Если у Вас новый сервер, который только настраиваете, можно подтвердить эти изменения и приступить к дальнейшей настройке. Если Вы проводите обновление на уже настроенном сервере, проанализируйте полученную информацию на предмет обновления, изменения или удаление критических зависимостей, от которых зависит работоспособность сервера.
Вернемся к команде apt-get update. Перед обновлением (upgrade) следует посмотреть какие пакеты будут обновлены:
root@host:~$ sudo apt list --upgradable
Вы можете посмотреть более детальную информацию о изменениях в пакетах, которые будут обновляться:
root@host:~$ sudo aptitude changelog <имя_пакета>
Если мы хотим обновить не все пакеты, а только, например, NGINX, это можно сделать командой установки nginx
root@host:~$ sudo apt-get update root@host:~$ sudo apt-get install nginx
Для полного обновления системы следует выполнить:
root@host:~$ sudo apt dist-upgrade
При этом обновление затронет не только установленные пакеты, но и всю среду.
Заключение.
Целью статьи было ознакомить читателя с базовым обеспечением безопасности в среде Linux. Это довольная обширная тема и мы неоднократно к ней вернемся в следующих наших статьях. Выполнив рассмотренные выше рекомендации, Вы можете существенно повысить безопасность Вашего сервера и предотвратить его взлом.
Для пользователей арендующих выделенные сервера или VDS сервера в нашей компании предоставляется круглосуточная базовая техническая поддержка. В рамках этого пакета услуг, мы помогаем нашим клиентам правильно настроить программное обеспечение на сервере необходимое для его стабильной и надежной работы.
Дата: 02.01.2020 Автор: Евгений
|
|
Авторам статьи важно Ваше мнение. Будем рады его обсудить с Вами:
comments powered by Disqus