Сетевые службы

Презентация 7-07: сетевые службы

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

Служба sshd

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

Служба sendmail или postfix

sendmail — один из самых распространённых почтовых серверов. Он реализует Internet-протоколы, связанные с отправлением почты (в первую очередь SMTP) как в рамках локальной машины, так и через Internet. Даже если узел не является почтовым сервером, служба sendmail служит для передачи писем между пользователями системы. Альтернативной широко распространённой почтовой службой является программа postfix.

Служба inetd

inetd (и его более развитая версия xinetd) — это супер-сервер, объединяющий множество сетевых служб. По сути этот сервер выполняет роль транспорта для сетевых служб: слушает на заданом порту, при входящем соединении запускает указанный для этого порта процесс и перенаправляет стандартный ввод и вывод программы в tcp-соединение. При этом правила доступа, ограничение по числу параллельных соединений, журналирование и т.п. организуются демоном inetd и настраиваются в его конфигурационных файлах.

Службы nfs и portmap

Демон сетевой файловой системы NFS (Network File System), которая поддерживается в большинстве UNIX-систем. Служба portmap, необходимая для работы NFS, позволяет использовать протокол удалённого вызова процедур (RPC).

Служба ntpd

Эта служба отвечает за запуск и останов демона, реализующего протокол синхронизации времени с удалёнными серверами точного времени в сети.

Служба samba

samba — это набор служб по организации сетевого файлового хранилища на основе протокола CIFS, используемого в сетевых файловых системах MS Windows. Широко применяется при взаимодействии UNIX-серверов и клиентских машин под Windows.

Служба cups

CUPS — сервер печати для UNIX-систем. Служба осуществляет запуск и останов соответствующего демона.

Служба bind

bind (или named) — самый распространённый сервер доменных имён для UNIX.

Мониторинг и журналирование

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

Служба системного журнала

Презентация 7-08: служба системного журнала

Служба системного журнала состоит из следующих компонентов:

Системная функция syslog

Главной чертой журналирования в UNIX является то, что в стандартном случае приложение не делает запись в файл журнала напрямую, а вызывает специальную системную функцию (syslog()), в качестве параметров которой передаёт как само сообщение для записи в журнал, так и сопровождающие сведения: программа-источник сообщения, время события, приоритет и характер сообщения. Список необходимых параметров функции syslog() и допустимых значений для них составляет API системных журналов, которое является частью стандартов POSIX. Использование этого API программой делает ее независимой от конкретной реализации демона ведения журнала в системе, что повышает уровень переносимости программы между разными UNIX-системами.

Демон syslogd

Со стороны операционной системы основным компонентом, реализующим функциональность журналирования, является демон (syslogd), который осуществляет получение сообщений от приложений, фильтрацию их и запись в файлы журналов. Правила фильтрации и адреса доставки сообщений (имена файлов журналов) описываются в конфигурационном файле syslogd, /etc/syslog.conf.

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

Конфигурационный файл /etc/syslog.conf

Синтаксис конфигурационного файла может несколько изменяться в зависимости от конкретной реализации демона журналирования, присутствующего в UNIX-системе. Однако во всех реализациях конфигурационный файл представляет собой список правил вида «условие–имя файла», где условие — это параметры сообщения (приоритет, тип, и т.п.). В случае соответствия сообщения правилу, оно будет записано в файл, указанный в этом правиле.

Каждая запись в системном журанале содержит следующие стандартные параметры:

• время события;

• имя программы, идентификатор процесса;

• тип программы или сообщения (например: AUTH, DAEMON, FTP и т.п.);

• приоритет сообщения (ALERT, ERR, WARNING, INFO и т.п.);

• текст сообщения.

Рассмотрим пример простого файла конфигурации системного журнала:

Пример 3.4. Пример файла /etc/syslog.conf

# Log all kernel messages to the console.

# Logging much else clutters up the screen.

kern.* /dev/console

# Log anything (except mail) of level info or higher.

# Don't log private authentication messages!

*.info;mail.none;authpriv.none; /var/log/messages

# The authpriv file has restricted access.

authpriv.* /var/log/secure

# Log all the mail messages in one place.

mail.* /var/log/maillog

# Log cron stuff

cron.* /var/log/cron

# Everybody gets emergency messages

*.emerg *

Данная конфгурация подразумевает вывод всех сообщений ядра в терминал пользователей, сообщения, связанные с почтой, сохранять в файле /var/log/maillog, связанные с аутентификацией, — в файле /var/log/secure, сообщения планировщика заданий — в файле /var/log/cron, тогда как все остальные сообщения отравлять в файл /var/log/messages.

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