Россия, Казань, Казанский Национальный Исследовательский Технический Университет |
Администрирование почтового сервера
Файл конфигурации 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 создаются еще и пароли. Кроме того, администратор почтовой системы также должен вести наблюдение за файлами отчетов в системе и в случае нестандартного поведения со стороны сервера либо его пользователей предпринимать адекватные действия. Любые проблемы в работе программного или аппаратного комплекса сервера должны быть своевременно локализованы. Необходимо также отслеживать все попытки несанкционированного доступа к серверу. Многочисленные безуспешные попытки получения доступа к серверу или соединения с ним явный признак того, что либо пользователи вскоре позвонят вам с вопросом, либо вы являетесь свидетелем попытки взлома вашего почтового сервера.