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

Глава 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, и таким образом, отказ в обслуживании.