Опубликован: 21.11.2006 | Доступ: свободный | Студентов: 1811 / 140 | Оценка: 4.09 / 4.00 | Длительность: 38:34:00
Лекция 14:

Администрирование почтового сервера

Файл конфигурации syslogd

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

event.priority
action

Каждая строка в файле /etc/syslogd.conf представляет различные действия. В зависимости от типа и приоритета системного события могут выполняться такие действия:

  • сообщение о событии выводится на системную консоль;
  • сообщение о событии помещается в соответствующий файл отчета;
  • сообщение о событии отправляется на удаленный хост, где ведется обобщение отчетов.

Файл конфигурации представляет собой комбинации системных событий и действий, которые должны выполняться программой syslogd. В листинге 14.7 приведен пример файла /etc/syslogd.conf.

1 # Log all kernel messages to the console.
2 # Logging much else clutters up the screen.
3 kern.* /dev/console
4
5 # Log anything (except mail) of level info or higher.
6 # Don't log private authentication messages!
7 *.info;mail.none;authpriv.none /var/log/messages
8
9 # The authpriv file has restricted access.
10 authpriv.* /var/log/secure
11
12 # Log all the mail messages in one place.
13 mail.* /var/log/maillog
14
15 # Everybody gets emergency messages, plus log them on another
16 # machine.
17 *.emerg *
18 *.emerg @meshach.smallorg.org
19
20 # Save mail and news errors of level err and higher in a
21 # special file.
22 uucp,news.crit /var/loq/spooler
Листинг 14.7. Пример файла /etc/syslogd.conf

В листинге 14.7 представлен файл /etc/syslogd.conf для системы Mandrake Linux 6.0. В строках 1 и 2 вы видите, как задаются комментарии в файле конфигурации. Подобные строки не обрабатываются программой syslogd. В строке 3 заданы символы "звездочка", которые обозначают что все сообщения, касающиеся работы ядра, независимо от их приоритета, будут посылаться на системную консоль.

Строка 7 представляет собой пример задания сложной конфигурации. В одной строке может задаваться несколько событий. Пары событий и их приоритетов разделяются точкой с запятой. Так, например, первая пара — *.info. Здесь определяются все приоритеты событий, начиная с приоритета info и выше. Помните, что более высокие приоритеты указываются в конце строки конфигурации.

Вторая пара — mail.none, — вероятно, выглядит немного странно. Наверное, у вас возник вопрос, почему мы не упомянули о приоритете none. Однако с помощью этого слова в данном случае исключаются все события, касающиеся работы почты, независимо от их приоритета. То есть определенные ранее параметры не касаются событий почтовой системы на сервере. Следующая пара — authpriv.none — выполняет те же действия. Таким образом, запись в строке 7 определяет, что все события в системе, за исключением mail и authpriv, будут записываться в файл отчетов /var/log/messages с приоритетом info и выше.

В строках 10 и 13 определяются действия по ведению файлов отчетов событий типа mail и authpriv. В строке 10 указывается, что все события типа authpriv с любым приоритетом будут фиксироваться в файле /var/log/secure. В строке 13 определяется, что все события при работе с почтой с любым приоритетом будут помещаться в отдельный файл /var/log/maillog. Представленная схема ведения файлов отчетов весьма удобна при анализе системных событий. Вероятно, как администратор почтовой системы вы пожелаете собирать все сведения о работе почты в определенный каталог на сервере. Это можно осуществить с помощью приведенных ниже примеров конфигурации.

В строке 18 дается пример использования удаленного сервера syslog для хранения файлов отчетов. Все сообщения с наивысшим приоритетом будут посылаться на узел meshach.smallorg.org. Если локальный сервер выдал сообщение с наивысшим приоритетом, что означает появление неустранимой ошибки, то вы даже не сможете прочесть файл отчета на нем. Выход очевиден: посылать сообщения о критичных сбоях в работе системы на другой узел (при условии, что возникшая на сервере ошибка позволяет это сделать).

Защита от хакеров и спамеров

Одной из сложнейших задач, возлагаемых на администратора системы электронной почты, является защита целостности почтового сервера и предотвращение попыток несанкционированного доступа к нему. Очевидно, что пользователи почтового сервера должны быть ограждены от малейших внешних воздействий, которые могут привести к потере или порче информации из их почтовых ящиков. Довольно часто администратор почтовой системы обнаруживает, что источник нелегальной активности на сервере находится в файлах отчетов. В листинге 14.8 представлен фрагмент файла /var/log/maillog с почтового сервера на базе Mandrake Linux.

1 Nov 2 19:09:12 shadrach sendmail[5365]: NOQUEUE: "wiz" 
  command from [192.168.1.15] (192.168.1.15)
2 Nov 2 19:09:14 shadrach sendmail[5365]: NOQUEUE: "debug" 
  command from [192.168.1.15] (192.168.1.15)
Листинг 14.8. Фрагмент файла отчета о сеансе SMTP

В листинге 14.8 показаны две попытки несанкционированного доступа к программе sendmail через сеть. В обоих случаях хакер использовал старые "хакерские" команды "wiz" и "debug", которые уже давно запрещены для выполнения программой sendmail. Проанализировав файл отчета, вы можете определить адрес, с которого были направлены эти команды. Далее общепринятая практика предполагает информирование вашего провайдера Internet об этих попытках несанкционированного доступа к вашему почтовому серверу. С определенной долей вероятности ваш провайдер сможет отследить источник, откуда предпринимаются попытки взлома вашего сервера.

Помимо этих сообщений, в файле отчетов о работе sendmail вы можете найти и другие сообщения. В листинге 14.9 приведен пример попытки проникновения на сервер POP3.

1 Nov 2 16:24:49 shadrach ipop3d[5373]: port 110 service init from 192.168.1.15
2 Nov 2 16:24:49 shadrach ipop3d[5373]: Login failure user=rich host=[192.168.1.15]
3 Nov 2 16:24:52 shadrach ipop3d[53731: AUTHENTICATE LOGIN failure host=[192.168.1.15]
4 Nov 2 16:24:52 shadrach ipop3d[5373]:Command stream end of file 
  while reading line user"??? host=[192.168.1.15]
5 Nov 2 16:24:55 shadrach ipop3d[5374]: port 110 service init from 192.168.1.15
6 Nov 2 16:24:55 shadrach ipop3d[5374]: Login failure user=rich host=[192.168.1.15]
7 Nov 2 16:24:58 shadrach ipop3d[5374]: AUTHENTICATE LOGIN failure host=[192.168.1.15]
Листинг 14.9. Пример файла отчета о сеансе POP3

В листинге 14.9 представлен файл отчета о событиях в системе электронной почты. Здесь вы видите, как пользователь, который не знает своего пароля, пытается войти в систему. Обратите внимание, что в строках 2 и 6 программа для работы с POP3 сгенерировала предупреждающие сообщения о том, что в доступе на сервер пользователю отказано, и зафиксировала IP-адрес компьютера, с которого осуществлялись попытки подключения к серверу. Если бы это был реальный хакер, то ваш провайдер Internet смог бы отследить его IP-адрес и определить, откуда были предприняты попытки несанкционированного доступа к вашему серверу.

Резюме

Итак, мы выяснили, что администрирование почтовой системы заключается не только в установке и настройке почтовых программ. Учетные записи пользователей также должны создаваться и обслуживаться администратором почтовой системы. В ОС Linux существует несколько способов обслуживания учетных записей пользователей. Так, изменять существующие и добавлять новые учетные записи из командной строки вы можете с помощью утилиты useradd. В графической среде X Window также имеется утилита для управления учетными записями — kuser. Обе утилиты создают новые учетные записи в файле /etc/passwd и, в зависимости от используемой вами системы, в файле /etc/shadow создаются еще и пароли. Кроме того, администратор почтовой системы также должен вести наблюдение за файлами отчетов в системе и в случае нестандартного поведения со стороны сервера либо его пользователей предпринимать адекватные действия. Любые проблемы в работе программного или аппаратного комплекса сервера должны быть своевременно локализованы. Необходимо также отслеживать все попытки несанкционированного доступа к серверу. Многочисленные безуспешные попытки получения доступа к серверу или соединения с ним явный признак того, что либо пользователи вскоре позвонят вам с вопросом, либо вы являетесь свидетелем попытки взлома вашего почтового сервера.