Книга: Сетевые средства Linux

Выявление ненужных серверов

Выявление ненужных серверов

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

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

Для обнаружения серверов, присутствующих в системе, может быть использована система управления пакетами. Если при установке программ вы пользовались исключительно диспетчером пакетов, то в базе данных диспетчера содержится информация о каждой программе, которая была инсталлирована на компьютере. Просмотрев описание пакета, содержащееся в базе, можно определить, является ли установленная программа сервером и насколько она необходима для работы системы. В качестве примеров инструментальных средств управления пакетами можно привести инструмент GNOME RPM, который используется в системе Red Hat, YaST — в SuSE, и Storm Package Manager (часть дистрибутивного пакета Storm, используемая в системе Debian). Окно GNOME RPM, предназначенное для просмотра инсталлированных пакетов, показано на рис. Выбрав пакет, вы сможете прочитать его описание. Некоторые диспетчеры пакетов распределяют информацию, которая хранится в базе, по категориям, однако на практике, чтобы найти серверы, присутствующие на компьютере, надо просмотреть все категории. Диспетчеры пакетов не позволяют выявить серверы, для инсталляции которых были использованы tar-архивы или исходные коды. Кроме того, такой подход не дает возможности ответить на вопрос, выполняется ли сервер в системе. (Сервер, который был инсталлирован, но не запущен, создает гораздо меньшую угрозу безопасности системы, чем сервер, выполняющийся на компьютере. Реальная опасность возникнет лишь в том случае, если впоследствии будет установлена конфигурация системы, предполагающая запуск сервера.)

Рис. 22.1. Диспетчер пакетов предоставляет информацию о серверах, установленных в системе

Чтобы обнаружить серверы, присутствующие в системе, можно проверить следующие файлы.

• Конфигурационный файл суперсервера. При поиске серверов следует проверить конфигурационные файлы /etc/inetd.conf и /etc/xinetd.conf, а также файлы в каталоге /etc/xinetd.d. Таким образом, вы найдете ссылки на все серверы, запускаемые посредством суперсервера. В конфигурационном файле inetd строки, в начале которых стоит символ #, представляют собой комментарии, поэтому серверы, указанные в них, не активны. Для суперсервера xinetd запуск сервера запрещает запись disable = yes.

• Сценарии запуска SysV. Можно найти серверы, запускаемые посредством сценариев просмотрев каталоги, предназначенные для размещения таких сценариев (обычно это каталог /etc/rc.d/rc?.d или /etc/rc?.d, где символ ? означает уровень выполнения). Необходимую вам информацию предоставят имена файлов, находящихся в этих каталогах. Заметьте, что некоторые из программ, запускаемых посредством сценариев SysV, не являются серверами, поэтому, прежде чем запретить их выполнение, следует выяснить назначение этих программ.

• Локальные сценарии запуска. Во многих дистрибутивных пакетах для запуска локальных программ используются локальные сценарии. Файлы, содержащие их, обычно называются rc.local или boot.local. Локальными считаются такие программы, при инсталляции которых использовался нестандартный способ, отличающийся от подхода, принятого для данного дистрибутивного пакета. Чтобы обнаружить серверы, выполняющиеся в системе, надо просмотреть весь локальный сценарий.

Подробно вопросы запуска серверов, в том числе соглашения об именовании сценариев SysV, были рассмотрены в главе 4. Определить назначение сценариев запуска вам помогут такие инструменты, как ntsysv и tksysv. Кроме того, в некоторых системах (Caldera, Mandrake, Red Hat и TurboLinux) команда chkconfig --list, заданная в командной строке, отображает состояние сценариев SysV, а в ряде случаев и назначение записей в конфигурационном файле xinetd.

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

Для обнаружения серверов может использоваться утилита ps. Она возвращает информацию о. процессах, выполняющихся в системе. При запуске ps можно указывать разные опции, но для выявления серверов достаточно ввести в командной строке ps ax.

Объем информации, возвращаемой ps, достаточно велик, поэтому имеет смысл перенаправить вывод в файл или передать данные, сгенерированные программой ps, утилите more или less. Если вы ищете сведения о конкретном сервере, используйте утилиту grep. Например, чтобы получить информацию о сервере sendmail, надо ввести команду ps ах | grep sendmail. Следует помнить, что утилита ps предоставляет сведения как о серверах, так и о других программах. Ниже приведен фрагмент данных, сгенерированных программой ps.

$ ps ax
 PID TTY   STAT TIME COMMAND
   1 ?     S    0:15 init [3]
 502 ?     S    0:05 named -u bind
 520 ?     S    0:01 cupsd
 535 ?     SW   0:00 [nfsd]
1741 pts/4 S    0:00 /bin/bash
4168 ?     S    0:00 httpd

На самом деле в процессе выполнения программа ps генерирует десятки и даже сотни строк. В данном примере удалена почти вся информация, кроме нескольких строк, иллюстрирующих работу этой утилиты. В первой строке программа ps выводит сведения о процессе init, для идентификации которого всегда используется номер 1. Данный процесс является корнем дерева, представляющего иерархию процессов в системе. Все остальные процессы порождаются либо непосредственно init, либо его дочерними процессами. Процессы, имена которых помещаются в квадратные скобки, представляют собой процессы ядра. В данном примере процессом ядра является [nfsd]. Как видно из его имени, [nfsd] поддерживает функции сервера NFS, реализованного средствами ядра. Процессы named, cupsd и httpd представляют собой пользовательские процессы. О принадлежности их к серверам можно судить по двум признакам. Во-первых, имя каждого из них оканчивается буквой "d", а во-вторых, эти процессы не связаны с терминалами (в поле TTY отображается символ ?). В отличие от них, процесс /bin/bash не является процессом сервера, так как в поле TTY выводится значение pts/4, т.е. данный процесс связан с конкретным терминалом.

Определив процессы серверов с помощью ps, надо отыскать документацию на те серверы, назначение которых вам неизвестно. Для этого следует ввести команду man имя, указав в качестве параметра имя интересующего вас процесса. Кроме того, постарайтесь найти исполняемый файл с именем, совпадающим с именем процесса. Это позволит вас проследить, какой пакет использовался для его инсталляции. Для получения информации о пакете введите команду rpm -qf путь_к_файлу. (В системе Debian для этого используется команда dpkg -S путь_к_файлу.)

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

При использовании ps для поиска серверов возникает проблема, состоящая в том, что данная утилита не сообщает, используется ли данный сервер для поддержки сетевого взаимодействия. Получить эту информацию вам поможет программа netstat. Данная программа возвращает данные о сетевых соединениях. Подобно ps, при запуске netstat могут указываться различные опции. Для поиска информации о серверах можно использовать команду netstat -lр. Опция -l сообщает утилите netstat о том, что она должна анализировать порты, через которые серверы ожидают поступление запросов, а опция -p задает вывод имен серверов, связанных с этими портами. Как и ps, утилита netstat генерирует большой объем данных, поэтому желательно перенаправить вывод в файл или передать входные данные программе less или more.

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

Мощными инструментами, которые можно использовать для поиска серверов, выполняющихся в системе, являются внешние программы сканирования. В качестве примеров подобных программ можно привести Nessus (http://www.nessus.org), SAINT (http://www.wwdsi.com/saint/) и Nmap (http://www.insecure.org/nmap/). Программа сканирования выполняется на любой машине, связанной по сети с компьютером, подлежащим проверке. Некоторые из таких инструментов, помимо информации о серверах, выводят также данные об используемой операционной системе, а также сведения о наличии недостатков в защите серверов. Для поиска серверов в большинстве случаев достаточно ввести имя сканирующей программы и указать имя компьютера, который следует проверить. Например, соответствующая команда может иметь вид nmap gingko.threeroomco.com. В результате вы получите список портов и имен серверов, связанных с ними.

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

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

Получив список серверов, вам предстоит определить, какие из них необходимы для работы системы. Решить эту задачу не всегда просто. Если администратор не имеет большого опыта работы с Linux, он вполне может посчитать ненужным сервер, жизненно важный для функционирования системы. Выяснить, какие из серверов нужны, а какие нет, поможет материал, изложенный в предыдущих главах. Кроме того, вы можете обратиться к документации на сервер, а также попытаться найти нужные сведения в Internet.

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

Необходимо соблюдать осторожность при отключении процессов, связанных с регистрацией пользователей. Даже если компьютер не выполняет функции сервера регистрации, удаление одного из серверов, описанных в главах 13 и 14, может стать причиной серьезной проблемы, для разрешения которой придется перезагрузить компьютер с гибкого диска. Особенно осторожно следует отключать процессы регистрации, запускаемые посредством сценариев SysV.

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

Оглавление книги