Глава 5. Безопасность сервера
Когда компьютер работает в открытой сети в качестве сервера, он становится целью для атак. Поэтому укрепление системы и блокировка служб крайне важны для системного администратора.
Прежде чем углубиться в эти вопросы, ознакомьтесь со следующими общими советами по усилению безопасности сервера:
Своевременно обновляйте службы, чтобы исправить недавно найденные уязвимости.
Используйте безопасные протоколы, везде, где это возможно.
Если это возможно, выделяйте для каждого типа сетевых служб отдельный компьютер.
Внимательно следите за подозрительной активностью на всех серверах.
5.1. Защита служб с помощью оболочек TCP и xinetd
Оболочки TCP позволяют управлять доступом к различным службам. Большинство современных сетевых служб, таких как SSH, Telnet и FTP, используют оболочки TCP, стоящие на страже между входящими запросами и службой.
Преимущества оболочек TCP увеличиваются, если используется xinetd — суперслужба, дающая дополнительные возможности управления доступом, ведением журнала, привязкой, перенаправлением и использованием ресурсов.
 | Подсказка |
|---|---|
Будет правильным использовать правила брандмауэра IPTables вместе с оболочками TCP и xinetd для двойного ограничения доступа к службам. Узнать больше о реализации брандмауэра на основе IPTables, вы сможете в главе 7 Брандмауэры. |
Дополнительные сведения по настройке оболочек TCP и xinetd можно найти в главе Оболочки TCP иxinetd в Справочном руководстве по Red Hat Enterprise Linux.
В следующих подразделах подразумевается, что вы имеете общие понятия об этом, и обсуждаются конкретные приёмы защиты.
5.1.1. Усиление безопасности с помощью оболочек TCP
Оболочки TCP способны не только ограничивать доступ к службам. В этом разделе показано, как их можно использовать для выдачи баннеров соединений, предупреждать об атаках с определённых узлов и улучшения ведения журнала. За полным списком возможностей оболочек TCP и описанием управляющего языка, обратитесь к странице man hosts_options.
5.1.1.1. Оболочки TCP и баннеры соединений
Послав клиентам, подключающимся к службе, устрашающий баннер, вы скроете информацию о системе, в которой работает сервер, и в то же время дадите возможному взломщику понять, что системой заправляет бдительный администратор. Чтобы сделать для службы баннер с помощью TCP оболочек, воспользуйтесь параметром banner.
В этом примере будет создан баннер для службы vsftpd. Для начала создайте файл баннера. Он может находиться где угодно в системе, но он должен носить имя демона. Например, файл можно назвать /etc/banners/vsftpd.
Содержимое файла будет примерно таким:
220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Act up and you will be banned. |
Вместо маркера %c будут подставлены сведения о клиенте, например, имя пользователя и компьютера или его IP-адрес, что делает соединение еще более устрашающим. Полный список маркеров, поддерживаемых оболочками TCP, вы найдёте в Справочном руководстве по Red Hat Enterprise Linux.
Чтобы этот баннер выдавался для всех входящих соединений, добавьте в файл /etc/hosts.allow следующую строку:
vsftpd : ALL : banners /etc/banners/ |
5.1.1.2. Оболочки TCP и предупреждения об атаке
Если при попытке атаки на сервер были пойманы какие-то узлы или сети, оболочки TCP, следуя указанию spawn, могут сообщать вам о последующих атаках этих узлов или сетей.
В этом примере предполагается, что при попытке нападения на сервер был пойман взломщик из сети 206.182.68.0/24. Следующая строка, помещённая в файл /etc/hosts.deny, запрещает подключение и регистрирует попытку в специальном файле:
ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert |
Вместо маркера %d будет подставлено имя службы, к которой пытался обратиться взломщик.
Чтобы разрешить подключение с регистрацией в журнале, поместите указание spawn в файл /etc/hosts.allow.
 | Замечание |
|---|---|
Так как указание spawn может выполнить любую команду оболочки, создайте специальный сценарий, сообщающий администратору или выполняющий серию команд в случае, если конкретный клиент пытается подключиться к серверу. |
5.1.1.3. Оболочки TCP и улучшенное ведение журнала
Если соединения одной службы более интересны, чем другой, уровень ведения журнала этой службы можно увеличить с помощью параметра severity.
Предположим, что человек, пытающийся подключиться к порту 23 (порт Telnet) на FTP-сервере — взломщик. Чтобы выявить его, установите флаг emerg, вместо флага по умолчанию info, и запретите соединение.
Для этого поместите в /etc/hosts.deny следующую строку:
in.telnetd : ALL : severity emerg |
При этом будет использовано стандартное средство ведения журнала authpriv, но приоритет поднимется с обычного info до emerg, и сообщения будут выводиться прямо на консоль.
5.1.2. Усиление защиты с помощью xinetd
Суперсервер xinetd — ещё одно полезное средство управления доступом к подчинённым ему службам. В этом разделе рассматривается, как с помощью xinetd можно устанавливать ловушки для служб и ограничивать ресурсы, используемые службами xinetd, для предотвращения атак типа отказ в обслуживании. За более полным списком возможностей обратитесь к страницам man, посвящённым xinetd и xinetd.conf.
5.1.1.2. Установка ловушки
Важной возможностью xinetd является его способность добавлять узлы в глобальный список no_access. Узлам из этого списка запрещены подключения к службам, управляемым xinetd, в течение заданного периода времени или до перезапуска xinetd. Для этого служит атрибут SENSOR. С помощью этой возможности можно легко заблокировать узлы, сканирующие порты сервера.
Определяя SENSOR, первым делом нужно выбрать службу, которую вы не планируете использовать. В этом примере выбрана служба Telnet.
Отредактируйте файл /etc/xinetd.d/telnet и измените строку flags следующим образом:
flags = SENSOR |
Добавьте в скобках следующую строку:
deny_time = 30 |
Она запрещает доступ на 30 минут узлу, пробующему подключиться к порту. Другими приемлемыми значениями атрибута deny_time является FOREVER (навсегда), означающее, что запрет будет действовать до перезапуска xinetd, и NEVER (никогда), допускающее подключение и регистрирующее его.
И, наконец, последняя строка будет такой:
disable = no |
Использование SENSOR — это хороший способ выявить и не допустить подключения плохих узлов, но у него есть два недостатка:
Он не спасает от скрытого сканирования.
Нападающий, знающий, что работает SENSOR, может устроить атаку типа отказ в обслуживании против конкретных узлов, подключаясь к запрещённому порту с их IP-адресами.
5.1.2.2. Управление ресурсами сервера
Ещё одной важной возможностью xinetd является его способность ограничивать ресурсы, используемые подчинёнными ему службами.
Это выполняется с помощью следующих указаний:
cps = <число_подключений> <период_ожидания> — Ограничивает число подключений к службе за секунду. Здесь допускаются только целые значения.
instances = <число_подключений> — Ограничивает общее число подключений к службе. Здесь указывается целое значение или UNLIMITED (без ограничений).
per_source = <число_подключений> — Ограничивает число подключений к службе с одного узла. Здесь указывается целое значение или UNLIMITED (без ограничений).
rlimit_as = <число[K|M]> — Ограничивает объём памяти, который может занимать служба, в килобайтах или мегабайтах. Здесь указывается целое значение или UNLIMITED (без ограничений).
rlimit_cpu = <число_секунд> — Ограничивает процессорное время, отнимаемое службой. Здесь указывается целое значение или UNLIMITED (без ограничений).
Эти указания могут предотвратить задавливание системы службой xinetd, и таким образом, отказ в обслуживании.