Руководство FreeBSD: Глава 14. Безопасность: OpenSSL
Обновлено: 16.01.2025
| Руководство FreeBSD |
| Глава 14. Безопасность |
14.9. OpenSSL
Написал: Tom Rhodes.Одной из программ, требующих особого внимания пользователей, является набор программ OpenSSL, включенный в FreeBSD. OpenSSL предоставляет уровень шифрования поверх обычных уровней соединения; следовательно, он может быть использован многими сетевыми приложениями и сервисами.
OpenSSL может использоваться для шифрования соединений почтовых клиентов, транзакций через интернет, например для кредитных карт, и многого другого. Многие порты, такие как www/apache13-ssl и mail/sylpheed-claws собираются с OpenSSL.
Замечание: В большинстве случаев в Коллекции Портов будет сделана попытка построения порта security/openssl, если только переменная WITH_OPENSSL_BASE не установлена явно в ''yes''.
Версия OpenSSL, включаемая в FreeBSD, поддерживает сетевые протоколы безопасности Secure Sockets Layer v2/v3 (SSLv2/SSLv3), Transport Layer Security v1 (TLSv1) и может быть использована в качестве основной криптографической библиотеки.
Замечание: Хотя OpenSSL поддерживает алгоритм IDEA, по умолчанию он отключен из-за патентных ограничений Соединенных Штатов. Для его использования необходимо ознакомиться с лицензией, и, если ограничения приемлемы, установить в make.conf переменную MAKE_IDEA.
Наиболее часто OpenSSL используется для создания сертификатов, используемых программными пакетами. Эти сертификаты подтверждают, что данные компании или частного лица верны и не подделаны. Если рассматриваемый сертификат не был проверен одним из нескольких сертификационных центров (''Certificate Authorities'' - CA), обычно выводится предупреждение. Центр сертификации представляет собой компанию, такую, как VeriSign, которая подписывает сертификаты для подтверждения данных частных лиц или компаний. Эта процедура не бесплатна и не является абсолютно необходимой для использования сертификатов; однако может успокоить некоторых особо осторожных пользователей.
14.9.1. Генерирование сертификатов
Для генерирования сертификатов доступна следующая команда:
# openssl req -new -nodes -out req.pem -keyout cert.pem Generating a 1024 bit RSA private key ................++++++ .......................................++++++ writing new private key to 'cert.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:PA Locality Name (eg, city) []:Pittsburgh Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Systems Administrator Common Name (eg, YOUR name) []:localhost.example.org Email Address []:trhodes@FreeBSD.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:SOME PASSWORD An optional company name []:Another Name
Ввод после приглашения ''Common Name'' содержит имя домена. Здесь вводится имя сервера для верификации; помещение в это поле чего-либо кроме этого имени приведет к созданию бесполезного сертификата. Доступны и другие параметры, например срок действия, альтернативные алгоритмы шифрования и т.д. Полный список находится на странице справочного руководства openssl(1).
В текущем каталоге, из которого была вызвана вышеуказанная команда, должны появиться два файла. Файл req.pem с запросом на сертификацию может быть послан в центр выдачи сертификатов, который проверит введённые вами подтверждающие данные, подпишет запрос и возвратит сертификат вам. Второй созданный файл будет иметь название cert.pem и содержать приватный сертификационный ключ, который необходимо тщательно защищать; если он попадёт в руки посторонних лиц, то может быть использован для имитации лично вас (или вашего сервера).
Когда подпись CA не требуется, может быть создан самоподписанный сертификат. Сначала создайте ключ RSA:
# openssl dsaparam -rand -genkey -out myRSA.key 1024
Теперь создайте ключ CA:
# openssl gendsa -des3 -out myca.key myRSA.key
Используйте этот ключ при создании сертификата:
# openssl req -new -x509 -days 365 -key myca.key -out new.crt
В каталоге должно появиться два новых файла: подпись сертификата, myca.key и сам сертификат, new.crt. Они должны быть помещены в каталог, доступный для чтения только root, желательно внутри /etc. Права на каталог можно изменить chmod с параметрами 0700.
14.9.2. Использование сертификатов, пример
Итак, что могут сделать эти файлы? Хорошим применением может стать шифрование соединений для Sendmail MTA. Это сделает ненужным использование простой текстовой аутентификации для тех, кто отправляет почту через локальный MTA.
Замечание: Это не лучшее из возможных использований, поскольку некоторые MUA выдадут ошибку, если сертификат не установлен локально. Обратитесь к поставляемой с программой документации за информацией по установке сертификата.
Следующие строки должны быть помещены в локальный файл .mc:
dnl SSL Options define(`confCACERT_PATH',`/etc/certs')dnl define(`confCACERT',`/etc/certs/new.crt')dnl define(`confSERVER_CERT',`/etc/certs/new.crt')dnl define(`confSERVER_KEY',`/etc/certs/myca.key')dnl define(`confTLS_SRV_OPTIONS', `V')dnl
Где /etc/certs/ это каталог для локального хранения сертификата и ключей. После настройки необходимо собрать локальный файл .cf. Это легко сделать, набрав make install в каталоге /etc/mail. Затем выполните команду make restart, которая должна запустить даемон Sendmail.
Если все пройдет нормально, в файле /var/log/maillog не появятся сообщения об ошибках и запустится процесс Sendmail.
Для проведения простого теста подключитесь к почтовому серверу программой telnet(1):
# telnet example.com 25 Trying 192.0.34.166... Connected to example.com. Escape character is '^]'. 220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) ehlo example.com 250-example.com Hello example.com [192.0.34.166], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 example.com closing connection Connection closed by foreign host.
Если в выводе появилась строка ''STARTTLS'', все работает правильно.
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.
Руководство FreeBSD: Глава 14. Безопасность: OpenSSH
Обновлено: 16.01.2025
| Руководство FreeBSD |
| Глава 14. Безопасность |
14.11. OpenSSH
Предоставил Chern Lee.OpenSSH это набор сетевых инструментов, используемых для защищенного доступа к удаленным компьютерам. Он может быть использован в качестве непосредственной замены rlogin, rsh, rcp и telnet. Кроме того, через SSH могут быть безопасно туннелированы и/или перенаправлены произвольные TCP/IP соединения. OpenSSH шифрует весь трафик, эффективно предотвращая кражу данных, перехват соединения и другие сетевые атаки.
OpenSSH поддерживается проектом OpenBSD, он основан на SSH v1.2.12 со всеми последними исправлениями и обновлениями, совместим с протоколами SSH версий 1 и 2.
14.11.1. Преимущества использования OpenSSH
Обычно при использовании telnet(1) или rlogin(1) данные пересылаются по сети в незашифрованной форме. Перехватчик пакетов в любой точке сети между клиентом и сервером может похитить информацию о пользователе/пароле или данные, передаваемые через соединение. Для предотвращения этого OpenSSH предлагает различные методы шифрования.
14.11.2. Включение sshd
В FreeBSD даемон sshd должен быть разрешен в процессе инсталляции. За запуск ответственна следующая строка в файле rc.conf:
sshd_enable="YES"
При следующей загрузке системы будет запущен sshd(8), даемон для OpenSSH. Вы можете также воспользоваться скриптом /etc/rc.d/sshd системы rc(8) для запуска OpenSSH:
/etc/rc.d/sshd start
14.11.3. SSH клиент
Утилита ssh(1) работает подобно rlogin(1).
# ssh user@example.com Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'example.com' added to the list of known hosts. user@example.com's password: *******
Вход продолжится так же, как если бы сессия была инициирована с использованием rlogin или telnet. SSH использует систему опознавательных ключей для проверки подлинности сервера при подключении клиента. Пользователю предлагается yes только при первом подключении. Дальнейшие попытки входа предваряются проверкой сохраненного ключа сервера. SSH клиент сообщит вам, если сохраненный ключ будет отличаться от только что полученного. Ключи серверов сохраняются в ~/.ssh/known_hosts, или в ~/.ssh/known_hosts2 для SSH v2.
По умолчанию современные серверы OpenSSH настроены на приём только соединений SSH v2. Клиент будет использовать версию 2 там, где это возможно, а затем версию 1. Также, клиент можно заставить использовать конкретную версию при помощи опций -1 и -2 для указания соответствующей версии протокола. Версия 1 поддерживается ради совместимости со старыми серверами.
14.11.4. Безопасное копирование
Команда scp(1) работает подобно rcp(1); она копирует файл с удаленного компьютера, но делает это безопасным способом.
# scp user@example.com:/COPYRIGHT COPYRIGHT user@example.com's password: ******* COPYRIGHT 100% |*****************************| 4735 00:00 #
Поскольку в предыдущем примере ключ сервера уже был сохранен, в этом примере он проверяется при использовании scp(1).
Параметры, передаваемые scp(1), похожи на параметры cp(1), с файлом или файлами в качестве первого аргумента и приемником копирования во втором. Поскольку файлы файлы передаются по сети через SSH, один или более аргументов принимают форму user@host:<path_to_remote_file>.
14.11.5. Настройка
Системные файлы настройки для даемона и клиента OpenSSH расположены в каталоге /etc/ssh.
Файл ssh_config используется для настройки клиента, а sshd_config для даемона.
Кроме того, параметры sshd_program (по умолчанию /usr/sbin/sshd), и sshd_flags rc.conf дают дополнительные возможности настройки.
14.11.6. ssh-keygen
Вместо использования паролей, с помощью ssh-keygen(1) можно создать ключи DSA или RSA, которыми пользователи могут аутентифицироваться:
% ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): Created directory '/home/user/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_dsa. Your public key has been saved in /home/user/.ssh/id_dsa.pub. The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com
ssh-keygen(1) создаст пару публичного и приватного ключей, используемых для аутентификации. Приватный ключ сохраняется в ~/.ssh/id_dsa или ~/.ssh/id_rsa, а публичный в ~/.ssh/id_dsa.pub или ~/.ssh/id_rsa.pub (для ключей DSA и RSA соответственно). Для включения аутентификации по ключам публичный ключ должен быть помещен в файл ~/.ssh/authorized_keys на удаленном компьютере.
Это позволяет соединяться с удаленным компьютером с помощью SSH-ключей вместо паролей.
Если при генерации ключей был использован пароль, каждый раз для при использовании приватного ключа он будет запрашиваться у пользователя. Для того, чтобы избежать непрерывного набора кодовой фразы, можно использовать утилиту ssh-agent(1), как описано в разделе Разд. 14.11.7 ниже.
Внимание: Параметры и имена файлов могут различаться для разных версий OpenSSH, установленных в системе, для решения проблем обратитесь к странице справочника ssh-keygen(1).
14.11.7. Утилиты ssh-agent и ssh-add
Утилиты ssh-agent(1) и ssh-add(1) позволяют сохранять ключи SSH в памяти, чтобы не набирать кодовые фразы при каждом использовании ключа.
Утилита ssh-agent(1) обеспечивает процесс аутентификации загруженными в нее секретными ключами; для этого утилита ssh-agent(1) должна запустить внешний процесс. В самом простом случае это может быть шелл-процесс; в чуть более продвинутом -- оконный менеджер.
Для использования ssh-agent(1) совместно с шеллом, ssh-agent(1) должен быть запущен с именем этого шелла в качестве аргумента. После этого в его память при помощи утилиты ssh-add(1) могут быть добавлены необходимые ключи; при этом будут запрошены соответствующие кодовые фразы. Добавленные ключи могут затем использоваться для ssh(1) на машины, на которых установлены соответствующие публичные ключи:
% ssh-agent csh % ssh-add Enter passphrase for /home/user/.ssh/id_dsa: Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) %
Для того чтобы использовать ssh-agent(1) в X11, вызов ssh-agent(1)должен быть помещен в файл ~/.xinitrc. Это обеспечит поддержкой ssh-agent(1) все программы, запущенные в X11. Файл ~/.xinitrc может выглядеть, например, так:
exec ssh-agent startxfce4
При этом будет запущен ssh-agent(1), который, в свою очередь, вызовет запуск XFCE, при каждом старте X11. После запуска X11, выполните команду ssh-add(1) для добавления ваших SSH-ключей.
14.11.8. Туннелирование SSH
OpenSSH поддерживает возможность создания туннеля для пропуска соединения по другому протоколу через защищенную сессию.
Следующая команда указывает ssh(1) создать туннель для telnet:
% ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com %
Команда ssh используется со следующими параметрами:
-2-
Указывает ssh использовать версию 2 протокола (не используйте этот параметр, если работаете со старыми SSH серверами).
-N-
Означает использование в не-командном режиме, только для туннелирования. Если этот параметр опущен, ssh запустит обычную сессию.
-f-
Указывает ssh запускаться в фоновом режиме.
-L-
Означает локальный туннель в стиле localport:remotehost:remoteport.
user@foo.example.com-
Удаленный сервер SSH.
Туннель SSH создается путем создания прослушивающего сокета на определенном порту localhost. Затем все принятые на локальном хосту/порту соединения переправляются на через SSH на определенный удаленный хост и порт.
В этом примере, порт 5023 на localhost перенаправляется на порт 23 на localhost удаленного компьютера. Поскольку 23 это порт telnet, будет создано защищенное соединение telnet через туннель SSH.
Этот метод можно использовать для любого числа небезопасных протоколов, таких как SMTP, POP3, FTP, и так далее.
Пример 14-1. Использование SSH для создания защищенного туннеля на SMTP
% ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** % telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.example.com ESMTP
Этот метод можно использовать вместе с ssh-keygen(1) и дополнительными пользовательскими учётными записями для создания более удобного автоматического SSH туннелирования. Ключи могут быть использованы вместо паролей, и туннели могут запускаться от отдельных пользователей.
14.11.8.1. Практические примеры SSH туннелирования
14.11.8.1.1. Защищенный доступ к серверу POP3
На работе находится SSH сервер, принимающий соединения снаружи. В этой же офисной сети находится почтовый сервер, поддерживающий протокол POP3. Сеть или сетевое соединение между вашим домом и офисом могут быть или не быть полностью доверяемыми. По этой причине вам потребуется проверять почту через защищенное соединение. Решение состоит в создании SSH соединения к офисному серверу SSH и туннелирование через него к почтовому серверу.
% ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com user@ssh-server.example.com's password: ******
Когда туннель включен и работает, вы можете настроить почтовый клиент для отправки запросов POP3 на localhost, порт 2110. Соединение будет безопасно переправлено через туннель на mail.example.com.
14.11.8.1.2. Прохождение через Драконовский Брандмауэр
Некоторые сетевые администраторы устанавливают на брандмауэрах драконовские правила, фильтруя не только входящие соединения, но и исходящие. Вам может быть разрешен доступ к удаленным компьютерам только по портам 22 и 80, для SSH и просмотра сайтов.
Вам может потребоваться доступ к другому (возможно, не относящемуся к работе) сервису, такому как Ogg Vorbis для прослушивания музыки. Если этот сервер Ogg Vorbis выдает поток не с портов 22 или 80, вы не сможете получить к нему доступ.
Решение состоит в создании SSH соединения с компьютером вне брандмауэра и использование его для туннелирования сервера Ogg Vorbis.
% ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org user@unfirewalled-system.example.org's password: *******
Клиентскую программу теперь можно настроить на localhost порт 8888, который будет перенаправлен на music.example.com порт 8000, успешно обойдя брандмауэр.
14.11.9. Параметр ограничения пользователей AllowUsers
Зачастую хорошие результаты даёт ограничение того, какие именно пользователи и откуда могут регистрироваться в системе. Задание параметра AllowUsers является хорошим способом добиться этого. К примеру, для разрешения регистрации только пользователю root с машины 192.168.1.32, в файле /etc/ssh/sshd_config нужно указать нечто вроде следующего:
AllowUsers root@192.168.1.32
Для разрешения регистрации пользователя admin из любой точки, просто укажите имя пользователя:
AllowUsers admin
Несколько пользователей должны перечислять в одной строке, как здесь:
AllowUsers root@192.168.1.32 admin
Замечание: Важно, чтобы бы перечислили всех пользователей, которые должны регистрироваться на этой машине; в противном случае они будут заблокированы.
После внесения изменений в /etc/ssh/sshd_config вы должны указать sshd(8) на повторную загрузку конфигурационных файлов, выполнив следующую команду:
# /etc/rc.d/sshd reload
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.
Экспорт настроек TheBat!
Обновлено: 16.01.2025Существует довольно простой метод переустановки почтовой программы TheBat! при переустановке операционной системы, при переносе почты на другой компьютер (при сохранении места расположения самой программы и почтовых баз).
Для этого необходимо:
- Скопировать всю папку TheBat из папки "C:Program FilesThe Bat!" (по умолчанию папка именно эта)
- Сохранить ветку реестра HKEY_CURRENT_USERSOFTWARERITThe Bat!
- После того, как переустановите систему, восстановите ветку реестра и скопируйте папку The Bat! на старое место.
Для реализации пункта 2) можно поступить так: создать два файла SaveBatSettings.bat и RestoreBatSettings.bat
В файл SaveBatSettings.bat записать следующее:
regedit /e RITSave1.reg HKEY_CURRENT_USERSoftwareRIT
regedit /e RITSave2.reg HKEY_LOCAL_MASHINESoftwareRIT
Запустить этот файл на системе, с которой необходимо скопировать настройки почты. Появятся два файла: RITSave1.reg и RITSave2.reg. Скопируйте их вместе с папкой почты со старой машины.
В файл RestoreBatSettings.bat записать следующее:
regedit /s RITsave1.reg RITSave2.reg
Скопируйте из вашей копии папку TheBat!, файлы RestoreBatSettings.bat, RITsave1.reg и RITSave2.reg и запустите файл RestoreBatSettings.bat.
Вот и все!
Копирование почты с помощью sendmail
Обновлено: 16.01.2025
Нижеизложенный материал не претендует на полноту, четкость, ясность или достоверность изложения и предоставляется автором "КАК ЕСТЬ". Автор не несет никакой отвественности за любое использование данного материала. Любое использование, копирование, цитирование, полностью или частично должно включать данный текст, ссылку на данный ресурс, а так же следующию строку без изменений:
Принцип работы копирования почтовых сообщений с помощью sendmail, описанный в данной статье, состоит в описании своего майлера(mailer), называемого в дальнейшем copymail, а так же в задании набора правил, который "передает" всю проходящую почту на наш майлер. Copymail, получив почтовое сообщение, действует как обычный транспортный агент, доставляя письмо оригинальному получателю, а так же на дополнительный адрес, заданный администратором. Почтовый адрес, на который будет копироваться почта, не обязательно должен быть локальным для данной машины. Описанный майлер (copymail) представляет из себя sendmail с "оригинальным" (без изменений) конфигурационным файлом.
sendmail(1), работающий в режиме daemon (-bd) получает (A) письмо и передает (B) его sendmail(2). ( sendmail(2) — это вышеописанный майлер copymail). sendmail(2) отсылает письмо оригинальному получателю (C) и дополнительному получателю (D).
Далее описаны несколько вариантов, конфигурации sendmail, для различных требований к копированию почтовых сообщений.
При описании, автор подразумевает, что читатель обладает некоторым "специфическим" набором знаний, а именно:
- знает что такое sendmail :) .
- знает что такое m4.
- умеет из .mc файла получить .cf.
- знает где находится ${CFDIR}.
- знает куда должны помещаться конфигурационные файлы sendmail.
Вариант 1.
(C одним конфигурационным файлом sendmail)
- Следует поместить файл copymail.m4 (Вариант 1)¹ в директорию ${CFDIR}/mailer.
- В файл конфигурации sendmail (.mc) добавить² следующие строчки:
define(`COPYMAIL_MAILBOX',`user@domen') MAILER(copymail)
заменив 'user@domen' на пользователя который должен получать копии всех сообщений (он не обязательно должен быть локальным пользователем на данной машине). - Скомпилировать и установить новый конфиг.
- Перезапустить sendmail.
Вся проходящая почта будет (дополнительно) пересылаться на заданный почтовый адрес.
Недостатки:
- В логах будут сообщения вида: Oct 11 15:59:54 mx.domen.ru sendmail[9151]: g1EsNvk01649: to=user2@somewere.com.COPYMAIL ... .
- При генерации уведомлений об ошибках доставки, в сообщениях будут указываться адреса вида user@domen.COPYMAIL.
¹. В этом и последующих примерах можно помещать строки из copymail.m4 непосредственно в конфигурационный файл sendmail(.mc), не забывая о правильном порядке директив.
². MAILER следует помещать в конце конфигурационного файла, а define — до MAILER.
Вариант 2.
(C двумя конфигурационными файлами sendmail)
- Следует поместить copymail.m4 (Вариант 2) в директорию ${CFDIR}/mailer
- Скопируйте ваш конфигурационный файл sendmail (.mc) в файл под именем sendmail.copy.mc
- Добавить следующие строчки в файл sendmail.copy.mc:
define(`COPYMAIL_MAILBOX',`user@domen') define(`NOCOPY_CONFIG',`/etc/mail/sendmail.cf') MAILER(copymail)
- Скомпилировать sendmail.copy.mc и установить как sendmail.copy.cf
- Остановить sendmail и запустить, следующим образом:
/usr/sbin/sendmail -bd -C /etc/mail/sendmail.copy.cf /usr/sbin/sendmail -q30m -C /etc/mail/sendmail.cf
N.B. Такой запуск sendmail необходим для того, что бы письмо, находящееся в очереди не копировалось каждые N минут, при каждой попытке доставки. Первая копия (-bd) работает как SMTP daemon, принимая письма (и копируя их). Вторая копия (-q30) работает обработчиком (queueing) очереди, доставляя письма находящиеся в очереди (и не копируя их, так как перед тем как попасть в очередь письма уже были скопированы).
ВНИМАНИЕ! Если вы допустите ошибку при конфигурировании sendmail (например вместо конфигурационного файла "nocopy", вы укажете "copy"), sendmail уйдет в "вечный" цикл, с доставкой писем самой себе и с потреблением всех ресурсов системы.
Вариант 3.
(C возможностью избирательно копировать почту)
Желательно иметь возможность как то управлять процессом копирования почты. Например, избирательно копировать сообщения от какой либо группы пользователей или наоборот — не копировать. Для этого предназначен copymail.m4 (Вариант 3). Sendmail следует сконфигурировать как по Варианту 2, только вместо copymail.m4 (Вариант 2) возьмите copymail.m4 (Вариант 3)
Следует, так же создать файл /etc/mail/nocopy-users и поместить в него почтовые адреса (в виде user@FQDN-domen ) или IP адреса (в форме X.X.X.X). Почтовые сообщения приходящие на почтовые адреса¹, перечисленные в /etc/mail/nocopy-users или отправлямые от почтового адреса² или с IP адреса, перечисленных в /etc/mail/nocopy-users, не будут копироваться.
Для достижения обратного результата, т.е. копирования почтовых сообщений от определенных почтовых адресов или на определенные почтовые адреса, и прохождения всех остальных почтовых сообщений без копирования, следует воспользоваться copymail.m4 (Вариант 4).
Так же, следует создать файл /etc/mail/copy-users и поместить в него "копируемые" адреса (формат адресов см. выше).
| ¹. Имеется в виду rcpt to: <addr> |
| ². Имеется в виду mail from: <addr> |
Прежде чем запускать sendmail в "боевом" режиме, я советую проверить полученную конфигурацию. Для этого следует запустить sendmail в режиме тестирования адреса (ключ -bt). Рассмотрим результат преобразования адреса, который должен получиться при использовании copymail.m4 (Вариант 1):
mx# sendmail -bt -C /etc/mail/sendmail.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 3,0 user@domen.ru canonify input: user @ domen . ru Canonify2 input: user < @ domen . ru > Canonify2 returns: user < @ domen . ru . > canonify returns: user < @ domen . ru . > parse input: user < @ domen . ru . > Parse0 input: user < @ domen . ru . > Parse0 returns: user < @ domen . ru . > ParseLocal input: user < @ domen . ru . > ParseLocal returns: $# copymail $@ domen . ru . COPYMAIL $: user @ domen . ru . COPYMAIL parse returns: $# copymail $@ domen . ru . COPYMAIL $: user @ domen . ru . COPYMAIL >
В результате должен вызваться майлер copymail и адрес должен переписаться в виде user@domen.ru.COPYMAIL. Теперь следует проверить "обратное" преобразование, т.е. письмо принятое от copymail должно разрешиться в "нормальный" адрес:
> 3,0 user@domen.ru.COPYMAIL canonify input: user @ domen . ru . COPYMAIL Canonify2 input: user < @ domen . ru . COPYMAIL > Canonify2 returns: user < @ domen . ru . COPYMAIL > canonify returns: user < @ domen . ru . COPYMAIL > parse input: user < @ domen . ru . COPYMAIL > Parse0 input: user < @ domen . ru . COPYMAIL > Parse0 returns: user < @ domen . ru . COPYMAIL > ParseLocal input: user < @ domen . ru . COPYMAIL > ParseLocal returns: user < @ domen . ru . > Parse1 input: user < @ domen . ru . > MailerToTriple input: < > user < @ domen . ru . > MailerToTriple returns: user < @ domen . ru . > Parse1 returns: $# esmtp $@ domen . ru . $: user < @ domen . ru . > parse returns: $# esmtp $@ domen . ru . $: user < @ domen . ru . > >
В результате адрес должен разрешиться в один из майлеров, кроме copymail. К примеру адрес может разрешиться в локальный майлер ($# local $: user) или в майлер esmtp ($# esmtp $@ domen . ru . $: user < @ domen . ru . >).
Теперь рассмотрим результат преобразования адреса при использовании copymail.m4 (Вариант 2 (3,4)):
mx# sendmail -bt -C /etc/mail/sendmail.copy.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 3,0 user@domen.ru canonify input: user @ domen . ru Canonify2 input: user < @ domen . ru > Canonify2 returns: user < @ domen . ru . > canonify returns: user < @ domen . ru . > parse input: user < @ domen . ru . > Parse0 input: user < @ domen . ru . > Parse0 returns: user < @ domen . ru . > ParseLocal input: user < @ domen . ru . > ParseLocal returns: $# copymail $@ localhost $: user < @ domen . ru . > parse returns: $# copymail $@ localhost $: user < @ domen . ru . > >
В результате должен вызваться майлер copymail: $# copymail $@ localhost $: user < @ domen . ru . >.
Если в результате тестирования адресов у вас не получается то, что вы ожидаете, например используется copymail.m4 (Вариант 3), пользователь user@domen.ru включен в /etc/mail/nocopy-users, а в результате почта для этого пользователя все равно копируется, то попробуйте воспользоваться следующими рекомендациями:
- Не забывайте перезапускать sendmail после установки нового конфигурационного файла.
- Не забывайте перезапускать sendmail после изменения списка адресов в файлах /etc/mail/nocopy-users или /etc/mail/copy-users.
- Не забывайте что правая и левая части в правилах подстановки (R) отделяются табуляцией.
- Проверьте что вы правильно указали sendmail файл /etc/mail/nocopy-users и sendmail загрузил список в класс NOCOPY. (Конструкция $={NOCOPY} позволяет просмотреть содержимое класса).
mx# sendmail -bt -C /etc/mail/sendmail.copy.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $={NOCOPY} > user@domen.ru > - Поробуйте воспользоваться отладочным режимом (-d) sendmail, что бы получить больше информации о процессе преобразования адресов:
mx# sendmail -bt -d21.12 -C /etc/mail/sendmail.copy.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 3,0 user@domen.ru ... -----callsubr ParseLocal (98) ParseLocal input: user < @ domen . ru . > -----trying rule: $* < @ $+ . > $* -----rule matches: $: $1 < @ $2 . > $3 $| $1 @ $2 rewritten as: user < @ domen . ru . > $| user @ domen . ru -----trying rule: $* < @ $+ . > $* $| $={NOCOPY} -----rule matches: $@ $1 < @ $2 . > $3 rewritten as: user < @ domen . ru . > ParseLocal returns: user < @ domen . ru . > rewritten as: user < @ domen . ru . > ... parse returns: $# local $: user >
Privacy violation.
(Морально-этические стороны вопроса)
Копирование почты является нарушением морально-этических (а возможно даже и юридических) прав, если только пользователь не был предупрежден об этом до начала процесса копирования почты (а ещё лучше до того как получил почтовый ящик)... Предлагаемый ниже вариант copymail.m4 позволяет вставить в каждое копируемое письмо некоторый заголовок (например назовем его X-Privacy-violation), в котором будет честно сказано что данное письмо было скопировано, а так же будет указано кому и зачем оно было скопировано. По такому же принципу можно изменить/дополнить один из стандарных заголовков, например To: или Subject:.
... Received: (from user@localhost) by mx.domen.ru ESMTP id g1KEPD001282 for user2@domen.ru; Wed, 20 Feb 2002 17:25:13 +0300 (MSK) (envelope-from user) Date: Wed, 20 Feb 2002 17:25:13 +0300 (MSK) From: User
Другие варианты copymail.m4 следует дополнить по аналогии с приведенным примером.
PUSHDIVERT(-1)
ifdef(`COPYMAIL_MAILBOX',,
`define(`COPYMAIL_MAILBOX', `postmaster')')dnl
POPDIVERT
#########################################
### COPYMAIL Mailer specification ###
#########################################
VERSIONID(`$Id: cpsendmail.html,v 1.2 2002/06/14 18:39:10 freeman Exp $')dnl
LOCAL_CONFIG
D{COPYMAIL}COPYMAIL
C{CP}${COPYMAIL}
LOCAL_RULE_0
# Send all mail to copymail mailer
R$* < @ $+ . $~{CP} . > $#copymail $@ $2 . $3 . ${COPYMAIL} $: $1 @ $2 . $3 . ${COPYMAIL}
# if mail has been processed by copymail mailer, process it usual way...
R$* < @ $* . ${COPYMAIL} > $1 < @ $2 . >
# Send message to original recipient + additional mailbox: COPYMAIL_MAILBOX
Mcopymail, P=/usr/sbin/sendmail, F=fmSDFMu, S=0, R=0,
A=sendmail -N never COPYMAIL_MAILBOX.${COPYMAIL} $u
PUSHDIVERT(-1)
ifdef(`COPYMAIL_MAILBOX',,
`define(`COPYMAIL_MAILBOX', `postmaster')')dnl
ifdef(`NOCOPY_CONFIG',,
`errprint(`*** You must define NOCOPY_CONFIG for copymail mailer!!! ***')')dnl
POPDIVERT
#########################################
### COPYMAIL Mailer specification ###
#########################################
VERSIONID(`$Id: cpsendmail.html,v 1.2 2002/06/14 18:39:10 freeman Exp $')dnl
LOCAL_RULE_0
# Send all mail to copymail mailer
R$* < @ $+ . > $* $#copymail $@ localhost $: $1 < @ $2 . > $3
# Send message to original recipient + additional mailbox: COPYMAIL_MAILBOX
Mcopymail, P=/usr/sbin/sendmail, F=fmSDFMu, S=0, R=0,
A=sendmail -N never -C NOCOPY_CONFIG COPYMAIL_MAILBOX $u
PUSHDIVERT(-1)
ifdef(`COPYMAIL_MAILBOX',,
`define(`COPYMAIL_MAILBOX', `postmaster')')dnl
ifdef(`NOCOPY_USERS',,
`define(`NOCOPY_USERS', `-o /etc/mail/nocopy-users')')dnl
ifdef(`NOCOPY_CONFIG',,
`errprint(`*** You must define NOCOPY_CONFIG for copymail mailer!!! ***')')dnl
POPDIVERT
#########################################
### COPYMAIL Mailer specification ###
#########################################
VERSIONID(`$Id: cpsendmail.html,v 1.2 2002/06/14 18:39:10 freeman Exp $')dnl
LOCAL_CONFIG
F{NOCOPY}NOCOPY_USERS
LOCAL_RULE_0
# Send all mail (except $={NOCOPY}) to copymail mailer
R$* < @ $+ . > $* $: $1 < @ $2 . > $3 $| $1 @ $2
R$* < @ $+ . > $* $| $={NOCOPY} $@ $1 <@ $2 . > $3
R$* < @ $+ . > $* $| $* $: $1 <@ $2 . > $3 $| $&{client_addr}
R$* < @ $+ . > $* $| $={NOCOPY} $@ $1 <@ $2 . > $3
R$* < @ $+ . > $* $| $* $: $1 <@ $2 . > $3 $| $&f
R$* < @ $+ . > $* $| <$*> $: $1 <@ $2 . > $3 $| $4
R$* < @ $+ . > $* $| $={NOCOPY} $@ $1 <@ $2 . > $3
R$* < @ $+ . > $* $| $* $#copymail $@ localhost $: $1 < @ $2 . > $3
# Send message to original recipient + additional mailbox: COPYMAIL_MAILBOX
Mcopymail, P=/usr/sbin/sendmail, F=fmSDFMu, S=0, R=0,
A=sendmail -N never -C NOCOPY_CONFIG COPYMAIL_MAILBOX $u
PUSHDIVERT(-1)
ifdef(`COPYMAIL_MAILBOX',,
`define(`COPYMAIL_MAILBOX', `postmaster')')dnl
ifdef(`COPY_USERS',,
`define(`COPY_USERS', `-o /etc/mail/copy-users')')dnl
ifdef(`NOCOPY_CONFIG',,
`errprint(`*** You must define NOCOPY_CONFIG for copymail mailer!!! ***')')dnl
POPDIVERT
#########################################
### COPYMAIL Mailer specification ###
#########################################
VERSIONID(`$Id: cpsendmail.html,v 1.2 2002/06/14 18:39:10 freeman Exp $')dnl
LOCAL_CONFIG
F{COPY}COPY_USERS
LOCAL_RULE_0
# Send mail $={COPY} to copymail mailer
R$* < @ $+ . > $* $: $1 < @ $2 . > $3 $| $1 @ $2
R$* < @ $+ . > $* $| $={COPY} $#copymail $@ localhost $: $1 < @ $2 . > $3
R$* < @ $+ . > $* $| $* $: $1 <@ $2 . > $3 $| $&{client_addr}
R$* < @ $+ . > $* $| $={COPY} $#copymail $@ localhost $: $1 < @ $2 . > $3
R$* < @ $+ . > $* $| $* $: $1 <@ $2 . > $3 $| $&f
R$* < @ $+ . > $* $| <$*> $: $1 <@ $2 . > $3 $| $4
R$* < @ $+ . > $* $| $={COPY} $#copymail $@ localhost $: $1 < @ $2 . > $3
R$* < @ $+ . > $* $| $* $: $1 <@ $2 . > $3
# Send message to original recipient + additional mailbox: COPYMAIL_MAILBOX
Mcopymail, P=/usr/sbin/sendmail, F=fmSDFMu, S=0, R=0,
A=sendmail -N never -C NOCOPY_CONFIG COPYMAIL_MAILBOX $u
PUSHDIVERT(-1)
ifdef(`COPYMAIL_MAILBOX',,
`define(`COPYMAIL_MAILBOX', `postmaster')')dnl
ifdef(`NOCOPY_CONFIG',,
`errprint(`*** You must define NOCOPY_CONFIG for copymail mailer!!! ***')')dnl
POPDIVERT
#########################################
### COPYMAIL Mailer specification ###
#########################################
VERSIONID(`$Id: cpsendmail.html,v 1.2 2002/06/14 18:39:10 freeman Exp $')dnl
LOCAL_CONFIG
H?{COPIED}?X-Privacy-violation: The copy of this message was sent to <COPYMAIL_MAILBOX> due to business requirements
Kiscopied macro
LOCAL_RULE_0
# Send all mail to copymail mailer
R$* < @ $+ . > $* $#copymail $@ localhost $: $1 < @ $2 . > $3 $(iscopied {COPIED} $@ YES $)
# Send message to original recipient + additional mailbox: COPYMAIL_MAILBOX
Mcopymail, P=/usr/sbin/sendmail, F=fmSDFMu, S=0, R=0,
A=sendmail -N never -C NOCOPY_CONFIG COPYMAIL_MAILBOX $u
Расположение ${CFDIR} в некоторых OS:
| Solaris | /usr/lib/mail |
| Linux | /usr/lib/sendmail-cf |
| FreeBSD | /usr/share/sendmail/cf |
Список литературы:
SENDMAIL: Копирование исходящей почты со всех компьютеров локальной сети, за исключением явно указанных компьютеров, копирование исходящей почты которых не должно производиться.
Обновлено: 16.01.2025Задача: необходимо копировать всю исходящую почту со всех компьютеров локальной сети, за исключением явно указанных компьютеров, копирование исходящей почты которых не должно производиться (например, это компьютер директора).
Имеем: FreeBSD 6.0, sendmail 8.13.6
Решение:
Проверить версию sendmail можно так:
в командной строке вводим (как root):
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> $v
8.13.6
>
Версию FreeBSD проверить можно так (как root): # uname –a
Не думаю, что необходимы именно такие (или не ниже) версии, но на всякий случай.
Итак, собственно решение.
Первое.
Создаем файл
в который пишем:
PUSHDIVERT(-1)
ifdef(`COPYMAIL_MAILBOX',,
`define(`COPYMAIL_MAILBOX', `postmaster')')dnl
ifdef(`NOCOPY_USERS',,
`define(`NOCOPY_USERS', `-o /etc/mail/nocopy-users')')dnl
ifdef(`NOCOPY_CONFIG',,
`errprint(`*** You must define NOCOPY_CONFIG for copymail mailer!!! ***')')dnl
POPDIVERT
#########################################
### COPYMAIL Mailer specification ###
#########################################
VERSIONID(`$Id: cpsendmail.html,v 1.2 2002/06/14 18:39:10 freeman Exp $')dnl
LOCAL_CONFIG
F{NOCOPY}NOCOPY_USERS
LOCAL_RULE_0
# Send all mail (except $={NOCOPY}) to copymail mailer
R$* < @ $+ . > $* $: $1 < @ $2 . > $3 $| $1 @ $2
R$* < @ $+ . > $* $| $={NOCOPY} $@ $1 <@ $2 . > $3
R$* < @ $+ . > $* $| $* $: $1 <@ $2 . > $3 $| $&{client_addr}
R$* < @ $+ . > $* $| $={NOCOPY} $@ $1 <@ $2 . > $3
R$* < @ $+ . > $* $| $* $: $1 <@ $2 . > $3 $| $&f
R$* < @ $+ . > $* $| <$*> $: $1 <@ $2 . > $3 $| $4
R$* < @ $+ . > $* $| $={NOCOPY} $@ $1 <@ $2 . > $3
R$* < @ $+ . > $* $| $* $#copymail $@ localhost $: $1 < @ $2 . > $3
# Send message to original recipient + additional mailbox: COPYMAIL_MAILBOX
Mcopymail, P=/usr/sbin/sendmail, F=fmSDFMu, S=0, R=0,
A=sendmail -N never -C NOCOPY_CONFIG COPYMAIL_MAILBOX $u
2. Редактируем sendmail.copy.mc
Скопируйте ваш sendmail.mc (конфигурационный файл) как sendmail.copy.mc
В конец нового файла sendmail.copy.mc добавте следующие строки:
define(`COPYMAIL_MAILBOX',`user@domen') define(`NOCOPY_CONFIG',`/etc/mail/sendmail.cf') MAILER(copymail)
В итоге мой файл sendmail.copy.mc (точнее, его конец) стал вот такого вида:
define(`COPYMAIL_MAILBOX',`user@localhost') define(`NOCOPY_CONFIG',`/etc/mail/sendmail.cf') MAILER(local) MAILER(copymail) MAILER(smtp)
где user@localhost – адрес локального пользователя, на который будут приходить копии отправленных писем.
3. Компилируем cf
Необходимо скомпилировать этот самый sendmail.copy.mc в sendmail.copy.cf
Для этого делаем следующее:
(это если у вас FreeBSD. Подробнее о компиляции .cf файлов для sendmail смотри здесь: http://www.sendmail.org/m4/intro.html)
Теперь у вас появился файл sendmail.copy.cf по адресу:
4. Кому не копируем почту
Создаем собственно файл, в котором будут указаны те пользователи, почту которых копировать не надо. Будьте внимательны!
# touch /etc/mail/nocopy-users
Следует поместить почтовые адреса (в виде user@FQDN-domen ) или IP адреса (в форме X.X.X.X) в этот файл. Почтовые сообщения приходящие на почтовые адреса¹, перечисленные в /etc/mail/nocopy-users или отправлямые от почтового адреса² или с IP адреса, перечисленных в /etc/mail/nocopy-users, не будут копироваться.
5. Проверяем
Собственно, все готово для тестирования того, что мы сделали.
# killall sendmail # /usr/sbin/sendmail -bd -C /etc/mail/sendmail.copy.cf # /usr/sbin/sendmail -q30m -C /etc/mail/sendmail.cf
Такой запуск sendmail необходим для того, что бы письмо, находящееся в очереди не копировалось каждые N минут, при каждой попытке доставки. Первая копия (-bd) работает как SMTP daemon, принимая письма (и копируя их). Вторая копия (-q30) работает обработчиком (queueing) очереди, доставляя письма находящиеся в очереди (и не копируя их, так как перед тем как попасть в очередь письма уже были скопированы).
Можете проверять систему. С клиентской машины отправляете письмо (естественно, рассылка писем до наших экспериментов должна быть настроена), и проверяете, получил ли локальный пользователь user письмо. Проверить можно, например, так:
Удачи!
Данный вопрос также рассмотрен в статье по адресу: http://www.vnc.org.ua/copymail/cpsendmail.html
Вышеизложенный материал не претендует на полноту, четкость, ясность или достоверность изложения и предоставляется автором "КАК ЕСТЬ". Автор не несет никакой отвественности за любое использование данного материала. Любое использование, копирование, цитирование, полностью или частично должно включать данный текст, ссылку на данный ресурс, а так же следующию строку без изменений: 2001-2002, O. Koreshkov
Настройка Sendmail
Обновлено: 16.01.2025Конфигурационный файл sendmail
Пожалуй самым сложным, с точки зрения настройки и сопровождения, из всех программных компонентов операционных систем семейства UNIX является программа sendmail. Те, кто видел хотя бы раз его конфигурационный файл, в этом нисколько не сомневаются. Такая сложность возникла не на пустом месте - она порождение условий существования в самом беспорядочном мире - мире электронной почты. Прямое редактирование конфигурационного файла программы sendmail, обычно носящего имя "sendmail.cf" (во FreeBSD этот файл располагается в каталоге "/etc/mail"), в особенности редактирование так называемых правил хранимых в нем, - задача посильная далеко немногим. Однако, необходимость подобного прямого хирургического вмешательства - явление крайне редкое. В большинстве случаев можно (и нужно) прибегнуть к помощи макропроцессора "m4(1)".Также см. построение файла sendmail.cf.
Сам по себе макропроцессор m4 не является узкоспециальной утилитой и может применяться во многих сферах, где необходима макрообработка текстовых данных. В случае с sendmail, для последнего создана богатая библиотека макросов формата m4, являющаяся штатным компонентом исходного кода самого sendmail, соответственно, поставляемая вместе с исходным кодом и позволяющая автоматизировать и упростить настройку sendmail в подавляющем большинстве случаев. Чем мы, собственно, сейчас и займемся. Подробное описание настройки sendmail при помощи m4 приведено в файле "SENDMAIL_ROOT/cf/README" (здесь SENDMAIL_ROOT - корень дерева исходного кода senmail, во FreeBSD это каталог "/usr/share/sendmail"), мы же ограничимся описанием нашего конкретного случая.
Имя файл исходного кода m4 обычно имеет суффикс ".mc", примеры готовых подобных конфигурационных файлов можно найти в каталоге "SENDMAIL_ROOT/cf/cf". Нам предстоит написать нечто подобное, свое. На синтаксисе m4 мы останавливаться не будем в силу его простоты, за комментариями же можно обратиться к странице руководства m4(1). В качестве отправной точки для файла можно воспользоваться уже готовой заготовкой для конкретной ОС из выше приведенного каталога. Для FreeBSD стандартным исходником m4 конфигурации для sendmail является файл "/etc/mail/freebsd.mc". Однако, наш конфигурационный файл достаточно сильно отличается от того, что имеется в наличии:
01: VERSIONID(`@(#)ironbox.mc,v 0.0.0 (vap@vap.org.ru) 2002/11/30') 02: OSTYPE(freebsd4) 03: DOMAIN(generic) 04: 05: FEATURE(local_lmtp) 06: FEATURE(nocanonify) 07: FEATURE(accept_unresolvable_domains) 08: FEATURE(accept_unqualified_senders) 09: FEATURE(virtusertable) 10: FEATURE(genericstable) 11: FEATURE(masquerade_envelope) 12: FEATURE(always_add_domain) 13: 14: VIRTUSER_DOMAIN_FILE(`/etc/mail/virtusertable.domains') 15: 16: define(`SMART_HOST', `mail.infopac.ru') 17: define(`confBIND_OPTS', `-DNSRCH -DEFNAMES') 18: define(`confSERVICE_SWITCH_FILE', `/etc/mail/service.switch') 19: define(`confSMTP_MAILER', `smtp8') 20: define(`confTO_IDENT', `0') 21: define(`confTO_QUEUEWARN', `16h') 22: define(`confTO_QUEUERETURN', `8d') 23: define(`confCON_EXPENSIVE', `True') 24: define(`SMTP_MAILER_FLAGS', `e') 25: 26: MAILER(local) 27: MAILER(smtp)
N.B. В первую очередь стоит пояснить, что префиксы в каждой строке состоящие из номера, двоеточия и пробела - всего лишь нумерация строк предназначенная для удобства дальнейшего пояснения. Эта нумерация не является составной частью реального конфигурационного файла.
Рассмотрим приведенный конфигурационный файл построчно.
Строка 01. Содержит определение версии файла, что позволяет упростить возможное дальнейшее сопровождение. Строка не является обязательной, но ее наличие не будет лишним. Этот макрос всего лишь дополняет результирующий файл строкой с информацией о версии. Формат самой строки произволен и может содержать, к примеру, информацию о версии в формате SCCS, RCS, CVS или каком-либо ином.
Пара пояснений. Хост, на котором я работаю, носит имя "ironbox", мое имя пользователя в системе, разумеется, - "vap". Остальное понятно без комментариев.
N.B. Обратите внимание, что в макросе строка открывается обратной кавычкой [`], а закрывается прямой [']. Таков синтаксис и за этим нужно следить внимательно, поскольку сообщения об ошибке при трансляции не будет.
Строка 02. Обязательный макрос объявления типа операционной системы. Выражение стоящее в скобках определяет имя, без суффикса ".m4", подключаемого файла из каталога "SENDMAIL_ROOT/cf/ostype/". Расположенные там файлы содержат определения системно-зависимых вещей, таких как пути доступа к каталогам, файлам и программам; аргументов командных строк программ почтовиков и прочих подобных вещей. Неуказание типа операционной системы приведет к ошибке во время трансляции.
Строка 03. Определение типа почтового домена. Подключает набор макросов задающих параметры специфичные для данного почтового домена. Подключаемые файлы расположены в каталоге "SENDMAIL_ROOT/cf/domain/". Для большинства реализаций вполне подходит "generic".
На этом общая схема конфигурации заканчивается, настает очередь определения особенностей - FEATURE. Стоит отметить, что каждый компонент конфигурации должен иметь свое место в конфигурационном файле, поскольку порядок их следования важен. Полная структура и порядок следования описаны в "SENDMAIL_ROOT/cf/README".
Строка 05. Объявляем, что в нашей системе имеется локальный агент доставки поддерживающий протокол LMTP (local mail transfer protocol - локальный протокол доставки почты, описанный в RFC2033). Для FreeBSD это "mail.local(8)". Имеет ли ваша система локальный почтовик с поддержкой LMPT описано в сопроводительной документации вашей ОС. Вообще говоря, наличие LMTP почтовика не критично, но полезно. Поэтому, если убрать этот параметр, то ничего страшного не произойдет.
Строка 06. Не выполнять канонификацию адресов. Операция канонификации требует выполнения запросов к серверу DNS, что в нашем случае не желательно и мы от этого будем избавляться всеми возможными средствами.
Строки 07 и 08. Указываем sendmail принимать почтовые отправления с неопределенным доменным именем в адресе отправителя или с частично сформированным самим адресом отправителя в команде "MAIL FROM:". Это нужно по простой причине - из-за трудностей доступа к серверу DNS мы все равно не сможем выполнить проверку адресов.
Строка 09. Использование таблицы виртуальных пользователей при доставке почты. По сути - это механизм синонимизации почтовых адресов назначения работающий не только в пространстве имен пользователей как, например, файл "/etc/mail/aliases" (см. "aliases(5)"), но и в пространстве доменов. Для чего эта функциональность нужна будет объяснено ниже. Кроме того, стоит отметить, что для работоспособности этого механизма необходимы еще некоторые, описанные ниже вещи.
Строка 10. Полный функциональный аналог "virtusertable" с той лишь разницей, что этот механизм отрабатывает не в момент доставки почты, а в момент передачи локального почтового сообщения на отправку. Фактически выполняется замена неквалифицированного адреса отправителя в исходящем сообщении, например, адреса не содержащего доменного имени, или иным образом особо описанного адреса на другой адрес содержащий иное имя пользователя и/или доменную часть адреса. Замена выполняется только для адреса отправителя в заголовке сообщения. Опять же, более подробно необходимость этого будет описана чуть позже.
Строка 11. Эта директива является дополнением к строке 10. Она указывает, что подмену адреса нужно выполнять не только в заголовке, но и в теле сообщения. Тем самым адрес отправителя будет заменяться везде.
Строка 12. Функциональное дополнение к строкам 9, 10 и 11 предписывающее всегда подставлять в адрес доменную часть даже если происходит локальная доставка. Это гарантирует, что механизм подстановки основанный на доменах будет срабатывать во всех случаях.
На этом описание используемых нами особенностей закончено, время определения их дополнительных параметров и прочих конфигурационных переменных.
Строка 14. Определение расположения файла содержащего перечень доменов для которых может отрабатываться механизм виртуализации пользователей, включенный в строке 9. Если этот файл будет отсутствовать или будет пуст, то виртуализация будет работать только на уровне имен локальных пользователей, то есть будет полностью аналогична "aliases(5)". Формат файла будет описан ниже.
Строка 16. Объявляет доменное имя "продвинутого" хоста, который собственно и будет заниматься пересылкой нашей исходящей почты. Здесь "mail.infopac.ru" должно быть заменено вами на имя почтовой системы используемого вами провайдера.
Строка 17. Небольшое дополнение для строки 6 позволяющее отключить выполнение подобных операций модулем разрешения адресов, то есть избежать обращений к DNS серверу.
Строка 18. Еще один "гвоздь в крышку гроба" DNS. Фактически здесь мы только определяем расположение и использование файла коммутатора сервисов. Посредством этого механизма мы запретим обращения к DNS сервису, что будет описано позже.
Строка 19. Мы живем в стране, где для кодирования символов используются все 8 бит байта, об этом и говорим MTA, чтобы передавал все как есть в 8-битовом кодировании, а не занимался ненужным преобразованием в 7-битный формат посредством MIME64 кодирования тела сообщения.
Строка 20. Устанавливаем тайм-аут на исполнение операции "IDENT" в 0 секунд. Это сервис практически нигде не используется, а его обработка приводит к бесполезным дополнительным задержкам при передаче почты.
Строки 21 и 22. Режим работы с очередью почтовых сообщений. Учитывая то, что отправка из очереди будет выполнена только на очередном сеансе связи, который будет может через час, а может завтра, устанавливаем тайм-аут предупреждения (строка 21) о невозможности доставки на достаточно длинный срок, здесь - 16 часов. Ну и, соответственно, возврат сообщения при невозможности его отправки (строка 22) по истечении 8 дней.
Строки 23 и 24. Запрещаем доставлять почту немедленно для так называемых дорогостоящих (expensive) агентов доставки (строка 23). Фактически это приводит к тому, что почта, которая должна доставляться агентом объявленным как дорогостоящий, будет просто устанавливаться в очередь, и там покорно ждать своего часа. Теперь, в строке 24, объявляем SMTP агента доставки как дорогостоящего. Таким образом добиваемся того, что вся локальная почта будет доставляться немедленно, а внешняя будет устанавливаться в очередь.
Строки 26 и 27. Последняя описываемая группа - группа используемых почтовиков. Это минимально необходимый и обязательный в нашем случае набор. Здесь "local" - почтовик локальной доставки, "smtp" - доставка посредством протокола SMTP через TCP/IP соединение.
На этом конфигурационный макро-файл завершен. Трансляция его в формат конфигурационного файла sendmail выполняется командой вида:
m4 -D_CF_DIR_=${CFDIR}/ ${CFDIR}/m4/cf.m4 config.mc > config.cf
Здесь ${CFDIR} - корневой каталог конфигурационной библиотеки sendmail - "SENDMAIL_ROOT/cf/", во FreeBSD это - "/usr/src/contrib/sendmail/cf". Определение каталога для "-D_CF_DIR_" должно обязательно заканчиваться "/". Вместо "config.mc" и "config.cf" должны быть реальные имена ваших файлов. Для FreeBSD определение "-D_CF_DIR_" может быть опущено, поэтому в моем случае команда имела вид:
m4 /usr/src/contrib/sendmail/cf/m4/cf.m4 ironbox.mc > ironbox.cf
Внешние файлы и сервисы
Получение конфигурационного файла sendmail - полдела. Теперь перейдем к конфигурации внешних для sendmail, но логически с ним связанных компонентов.
/etc/hosts
Для начала в файле "/etc/hosts" необходимо прописать IP адрес соответствующий доменному имени хоста объявленному в директиве строки 15 исходного файла конфигурации. В моем случае строка выглядит так:
217.77.96.6 mail.infopac.ru
Ваши значения, если только вы не используете услуги компании "Инфопак", должны, разумеется, отличаться.
Сама локальная система разрешения имен должна быть настроена на первичное использование "/etc/hosts", а именно в файле "/etc/host.conf" предложение "hosts" должно предшествовать предложению "bind". Подробнее смотри hosts(5) и host.conf(5). Сказанное касается и всех других имен хостов относительно которых требуется разрешение соответствующих им IP адресов. Это необходимо для избежания лишних запросов к внешнему DNS серверу, а следовательно позволит избежать ненужных установок коммутируемого соединения.
/etc/mail/genericstable
Этот текстовый файл содержит таблицу подстановок адреса отправителя для механизма включенного в строке 10 исходного конфигурационного файла. В нашем случае файл должен содержать, если конечно вы единственный пользователь в системе, единственное вхождение вида:
имя_пользователя адрес_электронной_почты
Трюк состоит в следующем. Если вы будете отправлять почту через локальный MTA из своего пользовательского бюджета, то во всей исходящей корреспонденции фактический ваш адрес пользователя в системе будет заменен на указанный здесь адрес, который будет подставлен в поле "From". Если в системе несколько пользователей, то, разумеется, для каждого должно существовать свое вхождение в файле. У меня содержимое этого файла выглядит так:
vap vap@vap.org.ru
Это гарантирует, что вся моя исходящая корреспонденция будет иметь на выходе адрес отправителя "vap@vap.org.ru".
Из данного текстового исходного файла должна быть сформирована хэш-база командой:
makemap hash /etc/mail/genericstable.db < /etc/mail/genericstable
/etc/mail/service.switch
Теперь создадим файл коммутатора сервисов. В нашем случае, в соответствии с заданным в директиве строки 18 значением, это будет файл "/etc/mail/service.switch". Этот текстовый файл должен содержать единственную строку:
hosts files
Строка предписывает sendmail использовать только информацию из файла "/etc/hosts" при разрешении имен во время доставки почты. Более подробно использование коммутатора сервисов описано в "Sendmail Installation and Operation Guide", разделе "2.5. The Service Switch".
/etc/mail/virtusertable
Механизм таблицы виртуальных пользователей используется для достижения функциональности перехвата почтовых сообщений адресованных в ваши почтовые ящики, расположенные на других серверах, для непосредственной их локальной доставки. Поясню на конкретном примере. В моем случае данный файл имеет вид:
vap@vap.org.ru vap vap@infopac.ru vap
Как видно, каждая строка состоит из дистанционного адреса и имени локального пользователя. Наличие этих двух строк приводит к тому, что любое письмо отправленное с локальной системы на какой-либо из приведенных здесь адресов, будет доставлено локально непосредственно в мой почтовый ящик, что позволяет не заниматься бесполезной пересылкой корреспонденции.
Из данного текстового исходного файла должна быть сформирована хэш-база командой подобной команде для файла "/etc/mail/genericstable".
Вообще говоря, функциональные возможности виртуальных таблиц для файлов "/etc/mail/genericstable" и "/etc/mail/virtusertable" значительно выше приведенных здесь. Механика их работы полностью описана в документе "SENDMAIL_ROOT/cf/README".
/etc/mail/virtusertable.domains
Механизм подстановки адресов, описанный для "/etc/mail/virtusertable", будет работать только в том случае, если сам исходный домен, для которого выполняется подстановка, объявлен как виртуальный. В нашем случае это делается посредством построчного перечисления всех этих доменов в данном текстовом файле. В моем случае он имеет вид:
vap.org.ru infopac.ru
Хэш базы для файла генерировать не нужно.
Прочее
Создаем, если он еще не создан, файл с именами локального хоста. Нам он без надобности, но sendmail его хочет. При необходимости файл можно будет потом приметить по назначению. Для создания, от пользователя "root" выполняем:
ironbox:~# touch /etc/mail/local-host-names
Поскольку мы не будем выступать SMTP сервером, то и периодически обрабатывать почтовую очередь не имеет смысла. Поэтому нужно изменить способ запуска sendmail на загрузке системы. Для этого в файле "/etc/rc.conf" пишем:
sendmail_enable="YES" sendmail_flags="-bd"
То есть демон будет присутствовать, но не будет обрабатывать свою очередь. Подробнее смотри sendmail(8). Завершаем работу запущенного демона командой выполняемой от пользователя "root":
ironbox:~# killall sendmail
И запускаем демона в новом режиме:
ironbox:~# /usr/sbin/sendmail -bd
/etc/mail/Makefile
Во FreeBSD, с версии, если не ошибаюсь, 4.3, в каталоге "/etc/mail" есть полезная вещица - файл "Makefile", который позволяет одним приемом получить конфигурационный файл для sendmail одновременно с генерацией всех необходимых хэш-баз. Для этого достаточно придерживаться соглашений о именовании исходных и сопутствующих файлов, держать их все в указанном каталоге, а так же сделать символическую ссылку с именем "sendmail.cf" указывающую на ".cf" файл вашей конфигурации. Например, если исходник конфигурации называется "myhost.mc", то ссылка должна быть на файл "myhost.cf". В случае если у вас все так, как здесь написано, то исполнение в каталоге "/etc/mail" команды:
make all
сделает все для вас. Подробнее об этом написано в комментариях самого "/etc/mail/Makefile".
Тестирование
Как говорится - настал момент истины. Если вы все сделали так, как здесь написано, то можно приступить к тестированию. Для начала проверим, что sendmail ведет себя так, как мы того ожидаем. Для этого запускам его в тестовом режиме:
ironbox:~# sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 3,0 vap canonify input: vap Canonify2 input: vap Canonify2 returns: vap canonify returns: vap parse input: vap Parse0 input: vap Parse0 returns: vap ParseLocal input: vap ParseLocal returns: vap Parse1 input: vap Parse1 returns: $# local $: vap parse returns: $# local $: vap > 3,0 vap@vap.org.ru canonify input: vap @ vap . org . ru Canonify2 input: vap < @ vap . org . ru > Canonify2 returns: vap < @ vap . org . ru . > canonify returns: vap < @ vap . org . ru . > parse input: vap < @ vap . org . ru . > Parse0 input: vap < @ vap . org . ru . > Parse0 returns: vap < @ vap . org . ru . > ParseLocal input: vap < @ vap . org . ru . > ParseLocal returns: vap < @ vap . org . ru . > Parse1 input: vap < @ vap . org . ru . > Recurse input: vap canonify input: vap Canonify2 input: vap Canonify2 returns: vap canonify returns: vap parse input: vap Parse0 input: vap Parse0 returns: vap ParseLocal input: vap ParseLocal returns: vap Parse1 input: vap Parse1 returns: $# local $: vap parse returns: $# local $: vap Recurse returns: $# local $: vap Parse1 returns: $# local $: vap parse returns: $# local $: vap > 3,0 vap@infopac.ru canonify input: vap @ infopac . ru Canonify2 input: vap < @ infopac . ru > Canonify2 returns: vap < @ infopac . ru . > canonify returns: vap < @ infopac . ru . > parse input: vap < @ infopac . ru . > Parse0 input: vap < @ infopac . ru . > Parse0 returns: vap < @ infopac . ru . > ParseLocal input: vap < @ infopac . ru . > ParseLocal returns: vap < @ infopac . ru . > Parse1 input: vap < @ infopac . ru . > Recurse input: vap canonify input: vap Canonify2 input: vap Canonify2 returns: vap canonify returns: vap parse input: vap Parse0 input: vap Parse0 returns: vap ParseLocal input: vap ParseLocal returns: vap Parse1 input: vap Parse1 returns: $# local $: vap parse returns: $# local $: vap Recurse returns: $# local $: vap Parse1 returns: $# local $: vap parse returns: $# local $: vap > 3,0 somebody@somewere.net canonify input: somebody @ somewere . net Canonify2 input: somebody < @ somewere . net > Canonify2 returns: somebody < @ somewere . net . > canonify returns: somebody < @ somewere . net . > parse input: somebody < @ somewere . net . > Parse0 input: somebody < @ somewere . net . > Parse0 returns: somebody < @ somewere . net . > ParseLocal input: somebody < @ somewere . net . > ParseLocal returns: somebody < @ somewere . net . > Parse1 input: somebody < @ somewere . net . > MailerToTriple input: < mail . infopac . ru > somebody < @ somewere . net . > MailerToTriple returns: $# relay $@ mail . infopac . ru $: somebody < @ somewere . net . > Parse1 returns: $# relay $@ mail . infopac . ru $: somebody < @ somewere . net . > parse returns: $# relay $@ mail . infopac . ru $: somebody < @ somewere . net . > > ^D
Жирным выделен клавиатурный ввод. Из примера хорошо видно, что свои адреса будут доставляться локально, а чужие будут отдаваться не пересылку. В вашем случае, естественно, нужно вводить и ваши же адреса.
Не забывайте, что sendmail у нас работает в режиме "установки в очередь", а это значит, что любое принятое на доставку письмо будет именно устанавливаться в очередь на обработку, но не доставляться. Для того чтобы sendmail обработал свою очередь и выполнил доставку его нужно запустить с ключом "-q":
ironbox:~# sendmail -q
Это приведет к тому, что будет обработана накопившаяся очередь, а сообщения в ней доставлены.
Литература
- FreeBSD: /usr/src/contrib/sendmail/README
- FreeBSD: /usr/src/contrib/sendmail/doc/op/op.me
- FreeBSD: /usr/src/contrib/sendmail/cf/README
- http://www.sendmail.org/faq/
Источник: http://vap.org.ru/mail@dialup/03.shtml
Установка Sendmail в качестве транзитного почтового релея
Обновлено: 16.01.2025Настраиваем sendmail (8.12.6/7) в качестве транзитного почтового релея.
Установка sendmail
Сначала устанавливаем из портов sendmail c поддержкой cyrus sasl (система аутентификации).
Настройка sendmail
Будем считать, что мы настраиваем все те же два виртуальных почтовых домена: perldoc.ru и perlfaq.ru. Для настройки sendmail в каечстве транзитного почтового сервера необходимо кроме файлов aliases и access создать (изи изменить) еще три файла:
- freebsd.mc
- relay-domains
- mailertable
relay-domains
В этом файле содержатся имена всех доменов, для которых наш сервер является транзитным. Файл расположен в каталоге /etc/mail и представляет собой список вида
domain1.com domain2.com ... ...
В этот файл мы добавляем строки
perldoc.ru perlfaq.ru
mailertable
В файле mailertable мы указываем sendmail, куда перенаправлять почту, пришедшую на адреса в доменах perldoc.ru и perlfaq.ru. Поскольку наш сервер - транзитный, мы должны прописать
perldoc.ru smtp:mail.perldoc.ru perlfaq.ru smtp:mail.perlfaq.ru
Вся почта, пришедшая на любые адреса доменов perldoc.ru и perlfaq.ru будет направляться на почтовые сервера mail.perldoc.ru и mail.perlfaq.ru соответственно.
freebsd.mc
Теперь нам осталось только изменить конфигурацию файла freebsd.mc, чтобы sendmail научился работать с виртуальными почтовыми доменами. Здесь надо понимать, что в том случае, когда существует файл, у которого имя совпадает с названием машины (например, для машины с именем genius файл будет genius.mc), он используется вместо файла freebsd.mc.i
Вот примерный вид конфигурационного файла:
1 divert(0) 2 VERSIONID(`$FreeBSD: src/etc/sendmail/freebsd.mc,v 1.10.2.16 16:39:14 gshapiro Exp $') 3 OSTYPE(freebsd4) 4 DOMAIN(generic) 5 6 FEATURE(access_db, `hash -o -T/etc/mail/access') 7 FEATURE(blacklist_recipients) 8 FEATURE(local_lmtp) 9 FEATURE(mailertable, `hash -o /etc/mail/mailertable') 10 dnl FEATURE(virtusertable, `hash -o /etc/mail/virtusertable') 11 define(`confCR_FILE', `/etc/mail/relay-domains')dnl 12 dnl Uncomment to allow relaying based on your MX records. 13 dnl NOTE: This can allow sites to use your server as a backup MX without 14 dnl your permission. 15 dnl FEATURE(relay_based_on_MX) 16 17 dnl DNS based black hole lists 18 dnl -------------------------------- 19 dnl DNS based black hole lists come and go on a regular basis 20 dnl so this file will not serve as a database of the available servers. 21 dnl For that, visit http://dmoz.org/Computers/Internet/Abuse/Spam/Blacklists/ 22 23 dnl Uncomment to activate Realtime Blackhole List 24 dnl information available at http://www.mail-abuse.com/ 25 dnl NOTE: This is a subscription service as of July 31, 2001 26 FEATURE(dnsbl) 27 dnl Alternatively, you can provide your own server and rejection message: 28 FEATURE(dnsbl, `blackholes.mail-abuse.org', `"550 Mail from " $&{client_addr} " rejected, see http://mail-abuse.org/cgi-bin/lookup?" $&{client_addr}') 29 30 dnl Dialup users should uncomment and define this appropriately 31 dnl define(`SMART_HOST', `your.isp.mail.server') 32 33 dnl Uncomment the first line to change the location of the default 34 dnl /etc/mail/local-host-names and comment out the second line. 35 dnl define(`confCW_FILE', `-o /etc/mail/sendmail.cw') 36 dnl define(`confCW_FILE', `-o /etc/mail/local-host-names') 37 38 dnl Uncomment both of the following lines to listen on IPv6 as well as IPv4 39 dnl DAEMON_OPTIONS(`Name=IPv4, Family=inet') 40 dnl DAEMON_OPTIONS(`Name=IPv6, Family=inet6') 41 42 TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN LOGIN')dnl 43 dnl define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN LOGIN')dnl 44 enl define(`confDEF_AUTH_INFO', `/etc/mail/auth/auth-info')dnl 45 FEATURE(`no_default_msa')dnl turn off default entry for MSA 46 DAEMON_OPTIONS(`Port=25, Name=MSA, M=E')dnl 47 48 define(`confMAX_RCPTS_PER_MESSAGE', `10') 49 define(`confMAX_MESSAGE_SIZE', `1048576') 50 51 define(`confBIND_OPTS', `WorkAroundBrokenAAAA') 52 define(`confMAX_MIME_HEADER_LENGTH', `256/128') 53 define(`confNO_RCPT_ACTION', `add-to-undisclosed') 54 define(`confPRIVACY_FLAGS', `authwarnings,noexpn,novrfy') 55 MAILER(local) 56 MAILER(smtp)
В строке 10 мы указываем имя файла трансляции виртуальных пользователей в настоящих и направление пересылки почты, а в 11-й - имена доменов, для которых мы пересылаем почту.
Запуск и тестирование
Собрав и установив файлы конфигурации sendmail, протестируем результат нашей работы:
telnet relay1.perldoc.ru 25 Escape character is '^]'. 220 relay1.perldoc.ru ESMTP Sendmail 8.12.7/8.12.7; Sun, 18 Jan 2004 08:08:52 +0300 (MSK) helo stellar 250 relay1.perldoc.ru Hello stellar [XXX.XXX.XXX.XXX], pleased to meet you mail from:stellar@perldoc.ru> 250 2.1.0... Sender ok rcpt to: 250 2.1.5 ... Recipient ok data 354 Enter mail, end with "." on a line by itself from: to: test passed . 250 2.0.0 i0I58qiZ007078 Message accepted for delivery quit 221 2.0.0 relay1.perldoc.ru closing connection Connection closed by foreign host.
При этом в лог-файле должна быть примерно такие записи:
Jan 18 08:09:40 fw sm-mta[7078]: i0I58qiZ007078: from=
Установка и настройка sendmail
Обновлено: 16.01.2025Настраиваем sendmail (8.12.6/7/8) для виртуального почтового хостинга.
Установка sendmail
Сначала устанавливаем итз портов sendmail c поддержкой cyrus sasl (система аутентификации).
cd /usr/ports/mail/sendmail-sasl make install
После установки sendmail мы должны изменить файл /etc/make.conf. Добавляем в него строчку
SENDMAIL_CF_DIR= /usr/local/share/sendmail/cf
Если до этого стоял более старый sendmail, устанавливаем файл submit.cf
make submit.cf
Для запуска sendmail будем использовать следующий сценарий (переименуем его в удобоваримый формат):
mv /usr/local/etc/rc.d/sendmail.sh.sample /usr/local/etc/rc.d/030.sendmail.sh
Для нормального запуска обновленной версии мы должны указать путь к ней (файл /etc/mail/mailer.conf). Это можно сделать либо при помощи команды
make mailer.conf
либо вручную, изменив файл mailer.conf:
sendmail /usr/local/sbin/sendmail send-mail /usr/local/sbin/sendmail mailq /usr/local/sbin/sendmail newaliases /usr/local/sbin/sendmail hoststat /usr/local/sbin/sendmail purgestat /usr/local/sbin/sendmail
На этом установка sendmail окончена. Осталоь столько запустить его командой
/usr/local/etc/rc.d/030.sendmail.sh start sendmail sm-msp-queue
Сообщения sendmail sm-msp-queue говорят о том, что все прошло нормально.
Настройка sendmail
Будем считать, что мы настраиваем два виртуальных почтовых домена: perldoc.ru и perlfaq.ru. Для настройки sendmail c поддержкой виртуального постового хостинга нам потребуется создать (или изменить) следующие файлы:
- freebsd.mc
- aliases
- access
- local-host-names
- virtusertable
aliases
Этот файл описывает пользовательские псевдонимы, используемые sendmail. Файл расположен в каталоге /etc/mail и представляет собой список вида
имя addr_1, addr_2, addr_3...
Более подробно структура файла aliases описана в aliases (5). В этот файл мы добавляем строку
root: admin@perldoc.ru
Вся локальная почта, адресованная пользователю root, теперь будет приходить на адрес admin@perldoc.ru.
access
В этом файле мы указываем, для каких IP адресов sendmail должен принимать и пересылать почту. Поскольку для эих целей мы будем использовать аутентификацию cyrus sasl, мы разрешим только отсылку с локального хоста
localhost.localdomain RELAY localhost RELAY
local-host-names
В этом файле мы храним названия доменов, для которых наш сервер должен обрабатывать почту. Поскольку мы хотим использовать наш сервер для двух виртуальных почтовых доменов perldoc.ru и perlfaq.ru, пропишем их в файл:
perldoc.ru perlfaq.ru
virtusertable
В файле virtusertable мы указываем sendmail, куда направлять почту, пришедшую на адреса в доменах perldoc.ru и perlfaq.ru.
stellar@perldoc.ru stellar-perldoc.ru admin@perldoc.ru admin-perldoc.ru @perldoc.ru error:nouser No such user here stellar@perlfaq.ru stellar-perlfaq.ru @perlfaq.ru error:nouser No such user here
Вся почта, пришедшая на адрес stellar@perldoc.ru будет направляться в почтовый ящик пользователя stellar-perldoc.ru, а почта, пришедшая на admin@perldoc.ru, соответственно будет отсылаться пользователю admin-perldoc.ru. Тоже самое будет и для домена perlfaq.ru. Если на наш домен будет прислана почта с несуществующем пользователем, сработает строчка
@perldoc.ru error:nouser No such user here
и sendmail откажется принимать такое сообщение.
freebsd.mc
Теперь нам осталось только изменить конфигурацию файла freebsd.mc, чтобы sendmail научился работать с виртуальными почтовыми доменами. Здесь надо понимать, что в том случае, когда существует файл, у которого имя совпадает с названием машины (например, для машины с именем genius файл будет genius.mc), он используется вместо файла freebsd.mc
Вот примерный вид конфигурационного файла:
1 divert(0) 2 VERSIONID(`$FreeBSD: src/etc/sendmail/freebsd.mc,v 1.10.2.16 2002/05/22 16:39:14 gshapiro Exp $') 3 OSTYPE(freebsd4) 4 DOMAIN(generic) 5 6 FEATURE(access_db, `hash -o -T/etc/mail/access') 7 FEATURE(blacklist_recipients) 8 FEATURE(local_lmtp) 9 dnl FEATURE(mailertable, `hash -o /etc/mail/mailertable') 10 FEATURE(virtusertable, `hash -o /etc/mail/virtusertable') 11 12 dnl Uncomment to allow relaying based on your MX records. 13 dnl NOTE: This can allow sites to use your server as a backup MX without 14 dnl your permission. 15 dnl FEATURE(relay_based_on_MX) 16 17 dnl DNS based black hole lists 18 dnl -------------------------------- 19 dnl DNS based black hole lists come and go on a regular basis 20 dnl so this file will not serve as a database of the available servers. 21 dnl For that, visit http://dmoz.org/Computers/Internet/Abuse/Spam/Blacklists/ 22 23 dnl Uncomment to activate Realtime Blackhole List 24 dnl information available at http://www.mail-abuse.com/ 25 dnl NOTE: This is a subscription service as of July 31, 2001 26 FEATURE(dnsbl) 27 dnl Alternatively, you can provide your own server and rejection message: 28 FEATURE(dnsbl, `blackholes.mail-abuse.org', `"550 Mail from " $&{client_addr} " rejected, see http://mail-abuse.org/cgi-bin/lookup?" $&{client_addr}') 29 30 dnl Dialup users should uncomment and define this appropriately 31 dnl define(`SMART_HOST', `your.isp.mail.server') 32 33 dnl Uncomment the first line to change the location of the default 34 dnl /etc/mail/local-host-names and comment out the second line. 35 dnl define(`confCW_FILE', `-o /etc/mail/sendmail.cw') 36 define(`confCW_FILE', `-o /etc/mail/local-host-names') 37 38 dnl Uncomment both of the following lines to listen on IPv6 as well as IPv4 39 dnl DAEMON_OPTIONS(`Name=IPv4, Family=inet') 40 dnl DAEMON_OPTIONS(`Name=IPv6, Family=inet6') 41 42 TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN LOGIN')dnl 43 define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN LOGIN')dnl 44 define(`confDEF_AUTH_INFO', `/etc/mail/auth/auth-info')dnl 45 FEATURE(`no_default_msa')dnl turn off default entry for MSA 46 DAEMON_OPTIONS(`Port=25, Name=MSA, M=E')dnl 47 48 define(`confMAX_RCPTS_PER_MESSAGE', `10') 49 define(`confMAX_MESSAGE_SIZE', `1048576') 50 51 define(`confBIND_OPTS', `WorkAroundBrokenAAAA') 52 define(`confMAX_MIME_HEADER_LENGTH', `256/128') 53 define(`confNO_RCPT_ACTION', `add-to-undisclosed') 54 define(`confPRIVACY_FLAGS', `authwarnings,noexpn,novrfy') 55 MAILER(local) 56 MAILER(smtp)
В строке 6 мы задаем файл с пользовательскими псевдонимами; в десятой строке - имя файла трансляции виртуальных пользователей в настоящих, а в 36-й строке - названия доменов, для которых наш сервер должен обрабатывать почту.
Также ограничим максимальный размер письма одним мегабайтом (строка 49) и запретим рассылать письмо одновременно более, чем 10 получателям (строка 48). Если есть необходимость отправки всей почты на промежуточный SMTP сервер (например, на SMTP сервер провайдера), следует раскомментировать строку 31 и вместо "your.isp.mail.server" указать IP адрес или имя SMTP сервера провайдера.
Запуск и тестирование
Теперь, когда почти все сделано, нам надо пересобрать заново файл конфигурации sendmail и обновить базы данных. Делается это следующим набором команд:
cd /etc/mail rm *.db rm freebsd.cf make all make install
Результатом будет нечто вроде этого:
/usr/bin/m4 -D_CF_DIR_=/usr/local/share/sendmail/cf/ /usr/local/share/sendmail/cf/m4/cf.m4 genius.mc > genius.cf /usr/sbin/makemap hash virtusertable.db < virtusertable chmod 0640 virtusertable.db /usr/sbin/makemap hash access.db < access chmod 0640 access.db /usr/sbin/sendmail -bi /etc/mail/aliases: 26 aliases, longest 18 bytes, 276 bytes total chmod 0640 /etc/mail/aliases.db install -m 444 freebsd.cf /etc/mail/sendmail.cf install -m 444 freebsd.submit.cf /etc/mail/submit.cf
Теперь перезапускаем sendmail
/usr/local/etc/rc.d/030.sendmail.sh stop /usr/local/etc/rc.d/030.sendmail.sh start
и тестируем:
telnet localhost 25
Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 localhost.my.domain ESMTP Sendmail 8.12.6/8.12.6; Mon, 30 Dec 2002 13:31:56 +0300 (MSK) EHLO localhost 250-localhost.my.domain Hello localhost [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN 250-DELIVERBY 250 HELP QUIT 221 2.0.0 localhost.my.domain closing connection
Наличие строчки "250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN" говорит нам о том, что sendmail может аутентифицировать пользователя. Добавляем пользователя:
saslpasswd2 admin-perldoc.ru Password: Again (for verification):
Вводим пароль пользователя и проверяем:
sasldblistusers2 admin-perldoc.ru@genius: userPassword
Собственно говоря, на этом настройка sendmail закончена. Теперь настраиваем The Bat! для того, чтобы можно было отправлять почту с аутентификацией:
Заходим в Ящик -> Свойства почтового ящика -> Транспорт -> Аутентификация
Выделяем чекбокс "Аутентификация SMTP (RFC-2554)".
Переключаем кнопку "Использовать параметры, указанные ниже."
Вводим имя пользователя и пароль, которые создали при помощи saslpasswd2.
Пользователь: admin-perldoc.ru@genius.
Пароль: *********
(!) Обратите внимание на то, что имя пользователя указано вместе с именем машины.
Выделяем чекбокс "Требовать безопасную (MD5) аутентификацию".
В том случае, если используется MS Outlook или другой почтовый клиент, в котором нет безопасной аутентификации (DIGEST-MD5, CRAM-MD5), необходимо использовать аутентификацию по методам PLAIN или LOGIN. При этом в качестве имени пользователя надо использовать имя пользователя БЕЗ добавленного имени машины. В нашем случае имя пользователя будет выглядеть так: admin-perldoc.ru.
После отправки письма в лог-файле /var/log/maillog должны быть примерно такие записи:
Dec 30 13:54:41 genius sm-mta[77570]: AUTH=server, relay=xxx.yyy.zzz.kkk [xxx.yyy.zzz.kkk], authid=admin-perldoc.ru@genius, mech=CRAM-MD5, bits=0
Поддерживается http://stellar.df.ru
SNMP протокол - принципы, безопасность, применение
Обновлено: 16.01.2025Вступление
Данная статья посвящена протоколу SNMP (Simple Network Management Protocol) - одному из протоколов модели OSI, который практически не был затронут в документации просторов RU-нета. Автор попытался заполнить этот вакуум, предоставив читателю почву для размышлений и самосовершенствования, касательно этого, возможно нового для Вас, вопроса. Этот документ не претендует на звание "документации для разработчика", а просто отражает желание автора, насколько это возможно, осветить аспекты работы с данным протоколом, показать его слабые места, уязвимости в системе "security", цели преследованные создателями и объяснить его предназначение.
Предназначение
Протокол SNMP был разработан с целью проверки функционирования сетевых маршрутизаторов и мостов. Впоследствии сфера действия протокола охватила и другие сетевые устройства, такие как хабы, шлюзы, терминальные сервера, LAN Manager сервера , машины под управлением Windows NT и т.д. Кроме того, протокол допускает возможность внесения изменений в функционирование указанных устройств.
Теория
Основными взаимодействующими лицами протокола являются агенты и системы управления. Если рассматривать эти два понятия на языке "клиент-сервер", то роль сервера выполняют агенты, то есть те самые устройства, для опроса состояния которых и был разработан рассматриваемый нами протокол. Соответственно, роль клиентов отводится системам управления - сетевым приложениям, необходимым для сбора информации о функционировании агентов. Помимо этих двух субъектов в модели протокола можно выделить также еще два: управляющую информацию и сам протокол обмена данными.
"Для чего вообще нужно производить опрос оборудования?" - спросите Вы. Постараюсь пролить свет на этот вопрос. Иногда в процессе функционирования сети возникает необходимость определить определенные параметры некоторого устройства, такие как , например, размер MTU, количество принятых пакетов, открытые порты, установленную на машине операционную систему и ее версию, узнать включена ли опция форвардинга на машине и многое другое. Для осуществления этого как нельзя лучше подходят SNMP клиенты.
Помимо сказанного выше рассматриваемый протокол обладает еще одной весьма важной особенностью, а именно возможностью модифицировать данные на агентах. Безусловно, было бы глупостью разрешить модификацию абсолютно любого параметра, но ,не смотря на это, и количество тех параметров, для которых допускается операция записи просто пугает. С первого взгляда это полностью опровергает всю теорию сетевой безопасности, но, если углубиться в вопрос, то становится ясно, что не все так запущено, как кажется с первого взгляда. "Волков бояться - в лес не ходить". Ведь при небольших усилиях администратора сети можно свести риск успешного завершения атаки к минимуму. Но этот аспект мы обсудим позже.
Остановимся на том, какую же все-таки информацию может почерпнуть система управления из недр SNMP. Вся информация об объектах системы-агента подержится в так называемой MIB (management information base ) - базе управляющей информации, другими словами MIB представляет собой совокупность объектов, доступных для операций записи-чтения для каждого конкретного клиента, в зависимости от структуры и предназначения самого клиента. Ведь не имеет смысла спрашивать у терминального сервера количество отброшенных пакетов, так как эти данные не имеют никакого отношения к его работе, так как и информация об администраторе для маршрутизатора. Потому управляющая система должна точно представлять себе, что и у кого запрашивать. На данный момент существует четыре базы MIB :
-
Internet MIB - база данных объектов для обеспечения диагностики ошибок и конфигураций. Включает в себя 171 объект (в том числе и объекты MIB I).
-
LAN manager MIB - база из 90 объектов - пароли, сессии, пользователи, общие ресурсы.
-
WINS MIB - база объектов, необходимых для функционирования WINS сервера (WINSMIB.DLL).
-
DHCP MIB - база объектов, необходимых для функционирования DHCP сервера (DHCPMIB.DLL), служащего для динамического выделения IP адресов в сети.
Все имена MIB имеют иерархическую структуру. Существует десять корневых алиасов:
-
System - данная группа MIB II содержит в себе семь объектов, каждый из которых служит для хранения информации о системе (версия ОС, время работы и т.д.).
-
Interfaces - содержит 23 объекта, необходимых для ведения статистики сетевых интерфейсов агентов (количество интерфейсов, размер MTU, скорость передачи , физические адреса и т.д.) .
-
AT (3 объекта) - отвечают за трансляцию адресов. Более не используется. Была включена в MIB I. Примером использования объектов AT может послужить простая ARP таблица (более подробно об ARP протоколе можно почитать в статье "Нестандартное использование протокола ARP", которую можно найти на сайте www.uinc.ru в разделе "Articles" ) соответствия физических (MAC) адресов сетевых карт IP адресам машин. В SNMP v2 эта информация была перенесена в MIB для соответствующих протоколов.
-
IP (42 объекта) - данные о проходящих IP пакетах (количество запросов, ответов, отброшенных пакетов).
-
ICMP (26 объектов) - информация о контрольных сообщениях (входящие/исходящие сообщения, ошибки и т.д.).
-
TCP (19) - все, что касается одноименного транспортного протокола (алгоритмы, константы, соединения, открытые порты и т.п.).
-
UDP (6) - аналогично, только для UDP протокола (входящие/исходящие датаграммы, порты, ошибки).
-
EGP (20) - данные о трафике Exterior Gateway Protocol (используется маршрутизаторами, объекты хранят информацию о принятых/отосланных/отброшенных кардах).
-
Transmission - зарезервирована для специфических MIB.
-
SNMP (29) - статистика по SNMP - входящие/исходящие пакеты, ограничения пакетов по размеру, ошибки, данные об обработанных запросах и многое другое.
Каждый из них представим в виде дерева, растущего вниз, (система до боли напоминает организацию DNS). Например, к адресу администратора мы можем обратиться посредством такого пути: system.sysContact.0 , ко времени работы системы system.sysUpTime.0 , к описанию системы (версия, ядро и другая информация об ОС) : system.sysDescr.0 . С другой стороны те же данные могут задаваться и в точечной нотации. Так system.sysUpTime.0 соответствует значение 1.3.0, так как system имеет индекс "1" в группах MIB II, а sysUpTime - 3 в иерархии группы system. Ноль в конце пути говорит о скалярном типе хранимых данных. Ссылку на полный список (256 объектов MIB II) Вы можете найти в конце статьи в разделе "Приложение". В процессе работы символьные имена объектов не используются, то есть если менеджер запрашивает у агента содержимое параметра system.sysDescr.0, то в строке запроса ссылка на объект будет преобразована в "1.1.0", а не будет передана "как есть". Далее мы рассмотрим BULK-запрос и тогда станет ясно, почему это столь важно . На этом мы завершим обзор структуры MIB II и перейдем непосредственно к описанию взаимодействия менеджеров (систем управления) и агентов. В SNMP клиент взаимодействует с сервером по принципу запрос-ответ. Сам по себе агент способен инициировать только оно действие, называемое ловушкой прерыванием (в некоторой литературе "trap" - ловушка). Помимо этого, все действия агентов сводятся к ответам на запросы, посылаемые менеджерами. Менеджеры же имеют гораздо больший "простор для творчества", они в состоянии осуществлять четыре вида запросов:
-
GetRequest - запрос у агента информации об одной переменной.
-
GetNextRequest - дает агенту указание выдать данные о следующей (в иерархии) переменной.
-
GetBulkRequest - запрос за получение массива данных. При получении такового, агент проверяет типы данных в запросе на соответствие данным из своей таблицы и цикле заполняет структуру значениями параметров: for(repeatCount = 1; repeatCount < max_repetitions; repeatCount++) Теперь представьте себе запрос менеджера на получение списка из сотни значений переменных , посланный в символьном виде, и сравните размер такового с размером аналогичного запроса в точечной нотации. Думаю, Вы понимаете, к чему привела бы ситуация, если бы символьные имена не преобразовывались вышеуказанным образом.
-
SetRequest - указание установить определенное значение переменой.
Кроме этого менеждеры могут обмениваться друг с другом информацией о своей локальной MIB. Такой тип запросов носит название InformRequest.
Приведу значения числовых констант для всех видов запросов:
#define SNMP_MSG_GET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x0)
#define SNMP_MSG_GETNEXT (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x1)
#define SNMP_MSG_RESPONSE (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x2)
#define SNMP_MSG_SET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x3)
/* PDU для SNMPv1 */
#define SNMP_MSG_TRAP (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x4)
/* PDU для SNMPv2 */
#define SNMP_MSG_GETBULK (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x5)
#define SNMP_MSG_INFORM (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x6)
#define SNMP_MSG_TRAP2 (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x7)
Вот тут то мы сталкиваемся с еще одной интересной деталью, как видите для ловушке есть 2 числовые константы. На самом деле существует 2 основные версии протокола SNMP (v1 & v2) и самое важное то, что они не являются совместимыми (на самом деле версий значительно больше -SNMP v2{p | c | u} etc, только все эти модификации довольно незначительны, так как , например, введение поддержки md5 и т.п.). SNMP - протокол контроля и диагностики, в связи с чем , он рассчитан на ситуации, когда нарушается целостность маршрутов, кроме того в такой ситуации требуется как можно менее требовательный с аппаратуре транспортный протокол , потому выбор был сделан в сторону UDP. Но это не значит, что никакой другой протокол не может переносить пакеты SNMP. Таковым может быть IPX протокол (например, в сетях NetWare) , также в виде транспорта могут выступать карды Ethernet, ячейки ATM. Отличительной особенностью рассматриваемого протокола есть то, что передача данных осуществляется без установки соединения.
Допустим менеджер послал несколько пакетов разным агентам, как же системе управления в дальнейшем определить какой из приходящих пакетов касается 1ого и 2ого агента? Для этого каждому пакету приписывается определенный ID - числовое значение. Когда агент получает запрос от менеджера, он генерирует ответ и вставляет в пакет значение ID , полученное им из запроса (не модифицирую его). Одним из ключевых понятий в SNMP является понятие group (группа). Процедура авторизации менеджера представляет собой простую проверку на принадлежность его к определенной группе, из списка, находящегося у агента. Если агент не находит группы менеджера в своем списке, их дальнейшее взаимодействие невозможно. До этого мы несколько раз сталкивались с первой и второй версией SNMP. Обратим внимание на отличие между ними. Первым делом заметим, что в SNMP v2 включена поддержка шифрования трафика, для чего, в зависимости от реализации, используются алгоритмы DES, MD5 . Это ведет к тому что при передаче данных наиболее важные данные недоступны для извлечения сниффингом, в том числе и информация о группах сети. Все это привело в увеличению самого трафика и усложнению структуры пакета. Сам по себе, на данный момент, v2 практически нигде не используется. Машины под управлением Windows NT используют SNMP v1. Таким образом мы медленно переходим к, пожалуй, самой интересной части статьи, а именно к проблемам Security. Об этом давайте и поговорим ...
Практика и безопасность
В наше время вопросы сетевой безопасности приобретают особое значение, особенно когда речь идет о протоколах передачи данных, тем более в корпоративных сетях. Даже после поверхностного знакомства с SNMP v1/v2 становится понятно, что разработчики протокола думали об этом в последнюю очередь или же их жестко поджимали сроки сдачи проекта %-). Создается впечатление что протокол рассчитан на работу в среде так называемых "доверенных хостов". Представим себе некую виртуальную личность. Человека, точнее некий IP адрес, обладатель которого имеет намерение получить выгоду , либо же просто насолить администратору путем нарушения работы некой сети. Станем на место этой особы. Рассмотрение этого вопроса сведем к двум пунктам:
-
a) мы находимся вне "враждебной сети". Каким же образом мы можем совершить свое черное дело? В первую очередь предполагаем что мы знаем адрес шлюза сети. Согласно RFC, соединение системы управления с агентом происходит по 161-ому порту (UDP). Вспомним о том что для удачной работы необходимо знание группы. Тут злоумышленнику на помощь приходит то, что зачастую администраторы оставляют значения (имена) групп, выставленные по умолчанию, а по умолчанию для SNMP существует две группы - "private" и "public". В случае если администратор не предусмотрел подобного развития событий, недоброжелатель может доставить ему массу неприятностей. Как известно, SNMP протокол является частью FingerPrintering. При желании , благодаря группе system MIB II, есть возможность узнать довольно большой объем информации о системе. Чего хотя бы стоит read-only параметр sysDescr. Ведь зная точно версию программного обеспечения, есть шанс , используя средства для соответствующей ОС получить полный контроль над системой. Я не зря упомянул атрибут read-only этого параметра. Ведь не порывшись в исходниках snmpd (в случае UNIX подобной ОС ), этот параметр изменить нельзя, то есть агент добросовестно выдаст злоумышленнику все необходимые для него данные. А ведь не надо забывать о том, что реализации агентов под Windows поставляются без исходных кодов, а знание операционной системы - 50% успеха атаки. Кроме того, вспомним про то, что множество параметров имеют атрибут rw (read-write), и среди таких параметров - форвардинг ! Представьте себе последствия установки его в режим "notForwarding(2)". К примеру в Linux реализации ПО для SNMP под название ucd-snmp есть возможность удаленного запуска скриптов на сервера, путем посылки соответствующего запроса. Думаю, всем понятно к чему могут привести "недоработки администратора".
-
б) злоумышленник находится на локальной машине. В таком случае вероятность увольнения админа резко возрастает. Ведь нахождение в одном сегменте сети дает возможность простым сниффингом отловить названия групп, а с ними и множество системной информации. Этого случая также касается все сказанное в пункте (а).
Перейдем к "практическим занятиям". Что же может на понадобиться. В первую очередь программное обеспечение. Его можно достать на http://net-snmp.sourceforge.net . Примеры я буду приводить для ОС Линукс, но синтаксис команд аналогичен Windows ПО.
Установка пакета стандартна:
gunzip udc-snmp-3.5.3.tar.gz
tar -xvf udc-snmp-3.5.3.tar
cd udc-snmp-3.5.3
./configure
make
make install
Запуск демона (агента)
snmpd
После инсталяции Вам доступны программы:
snmpget
snmpset
snmpgetnext
snmpwalk
snmpbulkwalk
snmpcheck
snmptest
snmpdelta
snmpnetstat snmpstatus
snmptable
snmptrap
snmptranstat
и демон
snmptrapd
Посмотрим, как выглядят описанные выше операции на практике.
Запрос GetRequest реализует одноименная программа snmpget
Для получения необходимой информации выполним следующую команду:
root@darkstar:~# snmpget 10.0.0.2 public system.sysDescr.0
На что сервер добросовестно сообщит нам:
system.sysDescr.0 = Hardware: x86 Family 6 Model 5 Stepping 0 AT/AT COMPATIBLE - Software: Windows NT Version 4.0 (Build Number: 1381 Uniprocessor Free )
(не правда ли - довольно содержательно), либо же
system.sysDescr.0 = Linux darkstar 2.4.5 #1 SMP Fri Aug 17 09:42:17 EEST 2001 i586
Прямо-таки - руководство по проникновению.
Допустим, мы хотим что-либо изменить в настройках агента. Проделаем следующую операцию:
root@darkstar:~# snmpset 10.0.0.2 public system.sysContact.0 s test@test.com
и получим ответ:
system.sysContact.0 = test@test.com
Список объектов MIB II с атрибутами можно найти пойдя по ссылке, указанной в "Приложении".
Думаю, настало время рассмотреть SNMP на пакетном уровне. Этот пакет был отловлен сниффером NetXRay на сетевом интерфейсе агента:
Как видим - практика не далека от теории. Наблюдаем Request ID и параметры запроса. На полном скриншоте можно увидеть стек протоколов - от кадров Ethernet, через UDP доходим до самого Simple Network Management Protocol:
А этот пакет был получен с интерфейса менеджера:
Как видите, название группы абсолютно никак не шифруется (о чем в свою очередь говорит Protocol version number : 1). Хочется отметить, что согласно спецификации протокола, пакеты SNMP не имеют четко определенной длины. Существует ограничение сверху равное длине UDP сообщения, равное 65507 байт, в свою очередь сам пртокол накладывает другое максимальное значение - лишь 484 байта. В свою очередь не имеет установленного значения и длина заголовка пакета (headerLength).
Ну вот мы в общих чертах и ознакомились с протоколом SNMP. Что еще можно добавить к сказанному выше ... Можно лишь дать пару советов сетевым администраторам, дабы уменьшить риск возникновения пролем с безопасностью сети... В первую очередь должное внимание следует уделить настройке файрволинга. Во-вторых - изменить установленные по умоланию имена групп. Разумным было бы жестко зафиксировать адреса машин (менеджеров), с которых разрешается опрос агентов. На этом, считаю, статью можно и закончить. Хочется верить, что она показалась Вам интересной.
Приложение
Список из 256 объектов MIB II: http://www.titanicum.kiev.ua/snmp/snmp_objects.htm
Объекты MIB II c атрибутами: http://www.titanicum.kiev.ua/snmp/mib2.htm
Софт под Линукс: http://www.titanicum.kiev.ua/snmp/ucd-snmp-3.5.3.tar.gz
Windows NT: удалённое вторжение
Обновлено: 16.01.2025Введение
Этот документ - попытка группы Rhino9 документировать технику и методы, используемые в нападении на основанные на WindowsNT сети. Цель данного документа состоит в том, чтобы научить администраторов и профессионалов защиты способам проникновения в NT-сети. Этот документ пытается следовать шагам классического текста "Как улучшить защиту вашего сайта вторжением в него" , который написали Dan Farmer и Wietse Venema.
Конечно, этот текст не будет содержать все известные методы вторжения в NT. Мы попытались собрать текст, который Администраторы могли бы использовать для изучения основных методов проникновения, чтобы проверить уязвимость их собственных сетей. Администратор должен иметь хорошие знания относительно того, как проникновения происходят и должен быть способен использовать эти знания чтобы далее защитить свою сеть.
Этот файл не предназначен для людей, которые плохо знакомы с защитой или технологиями организации сетей. Авторы предполагают, что люди, читающие этот документ, имеют некоторое понимание протоколов, технологий и архитектуры сервера и сети.
Использование
Текст написан в процедурной манере. Мы очень подробно всё описали, чтобы подойти как можно ближе к реальному вторжению. Большинство методов, обсуждаемых в этом тексте, довольно просто выполнить, как только наступит понимание того, как, что и почему делается.
Документ разделен на 3 части: NetBIOS, WebServer, и Разное, каждая из которых описывает различные методы сбора информации и методов проникновения.
Часть 1 - "NETBIOS"
Начальный шаг, который делает хакер, это сканирование портов целевой машины или сети. Удивительно, как техника атаки может стать основанной на открытых портах целевой машины. Вы должны понять, что это норма для NT-машины, - иметь различные открытые порты с Unix-машиной. Как правило хакер может по результатам сканирования портов сказать, является ли компьютер NT- или Unix-машиной с довольно точными результатами. Очевидно имеются некоторые исключения из данного правила, но вообще это может быть сделано.
При нападении на NT-сеть, NetBIOS имеет тенденцию брать главный удар на себя. По этой причине, NetBIOS будет первой серьезной темой для обсуждения.
Сбор информации с NetBIOS может быть довольно простой вещью, хотя и занимает некоторое время. NetBIOS вообще имеет тенденцию быть очень медленным, поэтому и требует много времени.
Если при сканировании портов выясняется, что на целевой машине порт 139 открыт, следует естественный процесс. Первый шаг - выполнение команды NBTSTAT.
Команда NBTSTAT может использоваться, чтобы сделать запрос сетевых машин относительно NetBIOS информации. Это может также быть полезно для чистки NetBIOS кэша и предзагрузки файла LMHOSTS. Эта команда может быть чрезвычайно полезна при выполнении ревизий защиты. Результаты её выполнения могут иной раз показать больше, чем вы могли бы подумать.
Использование: nbtstat [-a компьютер] [-A IP-адрес] [-c] [-n] [-R] [-r] [-S] [-s] [интервал]
Ключи:
-a вывести таблицу имён удаленного компьютера по имени.
-A вывести таблицу имён удаленного компьютера по IP-адресу.
-c вывести удаленный кэш имён, включая адреса IP.
-n вывести локальные имена NetBIOS.
-r вывести имена, найденные передачей и через WINS.
-R произвести чистку и перезагрузить удаленный кэш таблицы имён.
-S вывести таблицу сеансов с целевым адресом IP.
-s вывести преобразования таблицы сеансов.
Заголовки столбца, произведенные NBTSTAT имеют следующие значения:
Input
Число полученных байт.
Output
Число отосланных байт.
In/Out
Подключение от локального компьютера или от другой системы к
локальному компьютеру.
Life
Остающееся время до того, как ваш компьютер очистит кэш таблицы имён.
Local Name
Локальное NetBIOS имя, данное подключению.
Remote Host
Имя или адрес IP удаленного главного компьютера.
Type
Имя может иметь один из двух типов: уникальный или группа.
Последний байт из 16-символьного имени NetBIOS часто означает кое-что потому что то же самое имя может присутствовать в нескольких экземплярах на том же самом компьютере. Это показывает последний байт имени, преобразованный в hex-формат.
State
Ваши NetBIOS подключения будут находиться в одном из следующих "состояний":
|
|
|
|
|
входящее подключение находится в процессе |
|
|
подключение находится в конечной точке и ваш компьютер связал его с адресом IP. |
|
|
это хорошее состояние! Оно означает, что вы связаны с удаленным ресурсом |
|
|
ваш сеанс пробует решить преобразование имени в IP-адрес ресурса адресата |
|
|
сеанс связи закончен |
|
|
ваш компьютер запросил разъединение, и ожидает ответа от удаленного компьютера |
|
|
удаленный компьютер был открыт в текущем сеансе, но в настоящее время он не принимает подключения |
|
|
входящий сеанс пробует соединиться |
|
|
удаленный компьютер доступен |
|
|
ваш сеанс создает подключение TCP |
|
|
если ваше подключение потерпело неудачу на первой попытке, это состояние показывает попытку повторного соединения |
Имеется образец фактического ответа команды NBTSTAT:
C:>nbtstat -A x.x.x.x
NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------
DATARAT <00> UNIQUE Registered
R9LABS <00> GROUP Registered
DATARAT <20> UNIQUE Registered
DATARAT <03> UNIQUE Registered
GHOST <03> UNIQUE Registered
DATARAT <01> UNIQUE Registered
MAC Address = 00-00-00-00-00-00
Используя таблицу ниже, что вы можете сказать о компьютере ?
Name Number Type Usage
=========================================================================
<computername> 00 U Workstation Service
<computername> 01 U Messenger Service
<\_MSBROWSE_> 01 G Master Browser
<computername> 03 U Messenger Service
<computername> 06 U RAS Server Service
<computername> 1F U NetDDE Service
<computername> 20 U File Server Service
<computername> 21 U RAS Client Service
<computername> 22 U Exchange Interchange
<computername> 23 U Exchange Store
<computername> 24 U Exchange Directory
<computername> 30 U Modem Sharing Server Service
<computername> 31 U Modem Sharing Client Service
<computername> 43 U SMS Client Remote Control
<computername> 44 U SMS Admin Remote Control Tool
<computername> 45 U SMS Client Remote Chat
<computername> 46 U SMS Client Remote Transfer
<computername> 4C U DEC Pathworks TCPIP Service
<computername> 52 U DEC Pathworks TCPIP Service
<computername> 87 U Exchange MTA
<computername> 6A U Exchange IMC
<computername> BE U Network Monitor Agent
<computername> BF U Network Monitor Apps
<username> 03 U Messenger Service
<domain> 00 G Domain Name
<domain> 1B U Domain Master Browser
<domain> 1C G Domain Controllers
<domain> 1D U Master Browser
<domain> 1E G Browser Service Elections
<INet~Services> 1C G Internet Information Server
<IS~Computer_name> 00 U Internet Information Server
<computername> [2B] U Lotus Notes Server
IRISMULTICAST [2F] G Lotus Notes
IRISNAMESERVER [33] G Lotus Notes
Forte_$ND800ZA [20] U DCA Irmalan Gateway Service
Unique (U): имя может иметь только один адрес IP, назначенный для него. Может показаться, что на сетевом устройстве присутствуют многократные случаи одного и того же имени, но суффикс будет уникален, делая имя также полностью уникальным.
Group (G): нормальная группа; одиночное имя может существовать со многими адресами IP.
Multihomed (M): имя уникально, но из-за множественных сетевых интерфейсов на одном и том же компьютере, эта конфигурация необходима чтобы разрешить регистрацию. Максимальное число адресов - 25.
Internet Groupt (I): это специальная конфигурация имени группы, используемая для управления WinNT именами домена.
Domain Name (D): Новый в NT 4.0.
Хакер может использовать таблицу выше и результат от nbtstat против ваших машин, чтобы начать собирать информацию относительно их. По этой информации хакер может сказать, какие услуги выполняются на целевой машине и иногда, какие пакеты программ были установлены. Традиционно, каждый сервисный или главный пакет программ идет со своими ошибками, так что этот тип информации полезен для хакера.
Следующим логическим шагом был бы подбор возможных имён пользователей удаленной машины. Сетевой вход в систему состоит из двух частей - имени пользователя и пароля. Как только хакер имеет правильный список имен пользователей, он имеет половину из нескольких правильных входов в систему. Теперь, используя команду nbtstat, хакер может получить входное имя любого, кто подключён локально к данной машине. В результатах команды nbtstat, строки с идентификатором <03> - имена пользователей или имена компьютеров. Подбор имён пользователей может также быть выполнен через нулевой сеанс IPC и инструментальные средства SID (для получения дополнительной информации относительно инструментальных средств SID читать приложение B).
IPC$ (меж-процессовая связь) - стандартный скрытый ресурс на NT машине, которая главным образом используется для связи сервер-сервер. NT машины были разработаны для соединений друг с другом и получения различных типов необходимой информации через этот ресурс. Как и со многими особенностями проекта в любой операционной системе, хакеры научились использовать эту особенность в их собственных целях. Соединяясь с этим ресурсом хакер получает, для всех технических целей, допустимое подключение к вашему серверу. Соединяясь с этим ресурсом как нулевое соединение, хакер способен установить подключение без необходимой аутентификации.
Чтобы соединиться с ресурсом IPC$ как нулевое соединение, хакер выполняет следующую команду:
c:>net use \[ip address of target machine]ipc$ "" /user:""
Если подключение успешно, хакер может делать множество других вещей, кроме как подбор имён пользователей, но давайте сначала поговорим именно об этом. Как упомянуто ранее, эта методика требует нулевого сеанса IPC и инструментальных средств SID, которые написал Evgenii Rudnyi. Инструментальные средства SID состоят из двух различных частей, User2sid и Sid2user. User2sid будет брать имя аккаунта или группы и давать Вам соответствующий SID. Sid2user будет брать SID и давать Вам имя соответствующего пользователя или группы. Как автономный инструмент, это - процесс ручной и очень требует время. Userlist.pl - perl скрипт, написанный Mnemonix, который автоматизирует этот процесс размола SID, он решительно сокращает время, трубующееся хакеру на подбор информации.
На данном этапе хакер знает какие услуги выполняются на удаленной машине, какие главные пакеты программ были установлены (в некоторых пределах), и имеет список правильных имён пользователей и групп для данной машины. Хотя это может походить на тонну информации для постороннего, чтобы иметь её относительно вашей сети, нулевой сеанс IPC открыл другие способы сбора информации. Группа Rhino9 разработала полную политику защиты для удаленной машины. Такие вещи, как блокировка аккаунта, минимальная длина пароля, возраст пароля, уникальность пароля для каждого пользователя и группы, которой он принадлежит, и индивидуальные ограничения домена для данного пользователя - все через нулевой сеанс IPC. Некоторые из доступных инструментальных средств для сбора большего количества информации через нулевой сеанс IPC, будут обсуждены ниже.
При помощи нулевого сеанса IPC хакер может также получить список сетевых ресурсов, которые не могут иначе быть доступны. По очевидным причинам, хакер хотел бы знать то, какие сетевые ресурсы Вы имеете доступными на ваших машинах. Для сбора такой информации используется стандартная сетевая команда следующим образом:
c:>net view \[IP-адрес целевой машины]
В зависимости от политики защиты целевой машины, этот список может или не может быть отклонен. Пример ниже (ip-адрес не был указан по очевидным причинам):
C:>net view \0.0.0.0
System error 5 has occurred.
В доступе отказано.
C:>net use \0.0.0.0ipc$ "" /user:""
The command completed successfully.
C:>net view \0.0.0.0
Shared resources at \0.0.0.0
Share name Type Used as Comment
-------------------------------------------------------------------------------
Accelerator Disk Agent Accelerator share for Seagate backup
Inetpub Disk
mirc Disk
NETLOGON Disk Logon server share
www_pages Disk
Команда выполнилась успешно.
Как Вы можете видеть, список ресурсов на этом сервере не был доступен, пока не был установлен нулевой сеанс IPC. Теперь вы начинаете понимать, насколько может быть опасно это подключение IPC, но методы IPC, известные нам, фактически самые основные. Возможности, предоставленные ресурсом IPC, только начинают исследоваться.
Выпуск WindowsNT 4.0 Resource Kit предоставил новый набор инструментальных средств, доступных и администратору, и хакеру. Ниже - описание некоторых из Resource Kit Utilities, которые группа Rhino9 использовала вместе с нулевым сеансом IPC$ для сбора информации. Читая эти описания инструментов и информацию, которую они выдают, имейте в виду, что нулевой сеанс, который используется, НЕ обеспечивает удалённую сеть любой реальной аутентификацией.
UsrStat: эта утилита командной строки показывает имя пользователя, полное имя, и дату и время последнего входа в систему для каждого пользователя в данном домене. Ниже - фактический результат работы данного инструмента, используемого через нулевой сеанс IPC против удалённой сети:
C:NTRESKIT>usrstat domain4
Users at \STUDENT4
Administrator - - logon: Tue Nov 17 08:15:25 1998
Guest - - logon: Mon Nov 16 12:54:04 1998
IUSR_STUDENT4 - Internet Guest Account - logon: Mon Nov 16 15:19:26 1998
IWAM_STUDENT4 - Web Application Manager account - logon: Never
laurel - - logon: Never
megan - - logon: Never
Чтобы полностью понять, что происходит при сборе данных, давайте обсудим это. Прежде, чем фактическое нападение имело место, отображение было помещено в файл lmhosts, который отобразил Student4 машину, и это - состояние деятельности домена, используя #PRE/#DOM теги (объяснены более подробно ниже.). Вход был тогда предзагружен в NetBIOS кэш, и нулевой сеанс IPC был установлен. Как Вы можете видеть, команда запущена против имени домена. Инструмент тогда сделает запрос Первичного Контроллера Домена для данного домена.
Global: эта утилита командной строки отображает членов глобальных групп на удаленных серверах или доменах. Как сказано выше, эта утилита используется вместе с отображением Lmhosts/IPC. Ниже - фактический сбор данных данного инструмента. Например, "пользователи домена" - стандартная, заданная по умолчанию группа, присутствующая в WindowsNT домене. Для этого примера, мы использовали инструмент, чтобы сделать запрос Domain1 для листинга всех пользователей в группе "пользователи домена".
C:>global "Domain Users" domain1
Bob
SPUPPY$
BILLY BOB$
Bill
IUSR_BILLY BOB
IWAM_BILLY BOB
IUSR_SPUPPY
IWAM_SPUPPY
Local: этот инструмент делает то же, что и Global, но он делает запрос машины на членов локальной группы вместо глобальной. Ниже - пример работы данного инструмента:
C:>local "administrators" domain1
Bob
Domain Admins
Bill
NetDom: инструмент, который сделает запрос сервера о его роли в домене, а также на PDC машины. Этот инструмент также работает с отображением Lmhosts/IPC. Ниже - стандартный вывод данного инструмента:
Querying domain information on computer \SPUPPY ...
The computer \SPUPPY is a domain controller of DOMAIN4.
Searching PDC for domain DOMAIN4 ...
Found PDC \SPUPPY
The computer \SPUPPY is the PDC of DOMAIN4.
NetWatch: инструмент, выдающий список ресурсов на удаленной машине. Опять же, этот инструмент работает с отображением Lmhosts/IPC. Плохая вещь относительно этого инструмента состоит в том, что группа Rhino9 имеет обыкновение использовать его для поиска списка скрытых ресурсов на удаленной машине.
Пустое подключение IPC может позволить хакеру получить доступ к вашему системному реестру. Как только нулевой сеанс IPC был установлен, хакер запустит его локальную утилиту regedit и сделает попытку опции Connect Network Registry. Если это произойдёт успешно, хакер получит доступ для чтения на некоторые ключи и потенциально - на чтением/запись. Но даже доступ для чтения к системному реестру нежелателен с точки зрения защиты.
Другая методика относительно неизвестна и часто не приносит никаких результатов. Мы охватываем её потому что она всё же может давать результаты, и может быть эффективной методикой вторжения. Эта методика включает нулевой сеанс IPC и входы в LMHOSTS файл. LMHOSTS файл - (обычно) локальный файл, живущий на Windows-машинах, для отображения имён NetBIOS в адреса IP. Используемый главным образом в не-WINS средах, или на клиентах, неспособных использовать WINS, файл LMHOSTS может использоваться хакерами многими различными способами. Различные использования для файла LMHOSTS будут обсуждены позже в этом тексте, пока мы обсудим, как LMHOSTS файл используется в этой методике.
Это превосходная методика для обсуждения, потому что она показывает использование одного из предыдущих методов вместе с ней для выполнения цели. Начиная со сканирования портов, и обнаруживая, что порт 139 является открытым, хакер запускает команду nbtstat. Потом хакер подбирает имя NetBIOS удаленной машины по результатам nbtstat. Давайте посмотрим на такой же пример результатов работы nbtstat, как и выше:
C:>nbtstat -A x.x.x.x
NetBIOS Remote Machine Name Table
Name Type Status
-----------------------------------------------------------------
DATARAT <00> UNIQUE Registered
R9LABS <00> GROUP Registered
DATARAT <20> UNIQUE Registered
DATARAT <03> UNIQUE Registered
GHOST <03> UNIQUE Registered
DATARAT <01> UNIQUE Registered
MAC Address = 00-00-00-00-00-00
Исследуя результаты команды nbtstat, мы ищем идентификатор <03>. Если кто-то локально находится в машине, Вы будете видеть два <03> идентификатора. Обычно первый <03> - имя netbios машины, а второй <03> - имя локального пользователя. На данном этапе хакер поместил бы имя netbios и отображение адреса ip машины в его локальный LMHOSTS файл, закончив его тегами #DOM и #PRE. Тег #PRE обозначает, что вход должен быть предзагружен в netbios кэш. Тег #DOM обозначает деятельность домена. Теперь хакер запускает команду nbtstat -R чтобы произвести предзагрузку входа в его кэш.
Затем хакер устанавливает нулевой сеанс IPC. Как только нулевой сеанс IPC будет установлен, хакер запустит его локальную копию Менеджера Пользователя для доменов и использует функцию Select Domain в Менеджере Пользователя. Домен удаленной машины появится (или может быть напечатан вручную) потому что он был предзагружен в кэш. Если защита удаленной машины слаба, Менеджер Пользователя отобразит список всех пользователей на удаленной машине. Если это делается по медленной связи (то есть 28.8-модем) это не будет обычно работать. На более быстрых сетевых подключениях, однако, это имеет тенденцию давать результаты.
Теперь, когда хакер собрал некоторую информацию относительно вашей машины, следующим шагом будет попытка проникновения. Первый метод проникновения, который будет обсуждён, будет нападение на ресурс открытого файла. Хакер соединит предварительно обсужденную команду net view с командой net use для выполнения данной атаки.
Взяв net view выше, давайте обсудим атаку.
C:>net view \0.0.0.0
Shared resources at \0.0.0.0
Share name Type Used as Comment
-------------------------------------------------------------------------------
Accelerator Disk Agent Accelerator share for Seagate backup
Inetpub Disk
mirc Disk
NETLOGON Disk Logon server share
www_pages Disk
The command completed successfully.
Как только хакер имеет список удаленных ресурсов, он попытается подсоединиться к удаленному ресурсу. Пример команды для атаки был бы:
c:>net use x: \0.0.0.0inetpub
Это нападение будет работать только если ресурс не защищён паролем, или разделён между каждой группой (ПРИМЕЧАНИЕ: "каждой" означает именно "каждой". То есть, если кто-то соединяется нулевым сеансом, он теперь - часть каждой группы.). Если эти параметры имеют место, хакер способен подключить сетевой диск к вашей машине и начать проникновение. Имейте в виду, что хакер не ограничен только лишь соединением с дисковыми ресурсами. Хакер, знающий NT, знает, что NT имеет скрытые административные ресурсы. По умолчанию, NT создает ресурс IPC$ и один скрытый ресурс для каждого диска на машине (то есть машина, которая имеет диски C, D, и E имеет соответствующие скрытые ресурсы C$, D$, и E$). Имеется также скрытый ADMIN$ ресурс, который указывает непосредственно на инсталляционный путь NT (то есть, если Вы установили NT на C:winnt, то ADMIN$ указывает точно на эту часть диска). Одна вещь, которую группа Rhino9 заметила относительно большинства NT сообщества защиты, состоит в том, что они, кажется, забыли о концепции проникновения через одну внутреннюю NT машину в другую внутреннюю NT машину. Группа Rhino9, в течение наших профессиональных ревизий, выполнила эту задачу много раз. Если хакер умён и имеет доступ к одной из ваших машин, он может написать саморазмножающийся вирус и пустить его в остальную часть вашей сети. По этой причине, эти нападения могут представлять серьезную угрозу.
(Обратите внимание, с группой Rhino9 однажды входили в контакт, чтобы выполнить удаленную ревизию проникновения для одного самого большого ISP во Флориде. Мы получили доступ к ресурсу на одной из персональных машин техника, и оттуда получили доступ к полной сети. Это может быть сделано.)
Сначала, может быть, не видно опасности от кого-то, кто имеет доступ к вашему жесткому диску. Но доступ к жесткому диску открывает новые направления для сбора информации и установки трояна/вируса. Хакер обычно ищет кое-что, что могло бы содержать пароль или важные данные, что он мог бы использовать, чтобы продолжть рыть путь в вашу сеть. Некоторые из файлов, которые хакер будет искать и использовать, перечислены ниже, каждый с кратким описанием, чем это является, и как это можно использовать.
Eudora.ini: этот файл используется для хранения информации о конфигурации программного обеспечения для e-mail Eudora. Легко доступный инструмент, называемый eudpass.com, извлечет имя пользователя и информацию пароля, также как всю информацию, необходимую хакеру для подслушивания почты пользователей. Теперь хакер может сконфигурировать его собственное программное обеспечение для электронной почты, чтобы читать почту адресатов. Помните, что люди - существа привычки. Шансы, что пароль пользователя электронной почты является тем же самым паролем, который он использует для входа в сеть на работе, относительно высоки.
Tree.dat: это файл, который используется популярным программным обеспечением CuteFTP для хранения комбинации пользователей ftp site/username/password. Используя программу по имени FireFTP, хакер может легко взломать tree.dat файл. Как уже говорилось выше, хакер может продолжить сбор информации относительно Вас и начать атаку.
PWL: эти файлы проживают на Win95-машинах. Они используются, чтобы хранить определенные пароли для Windows95 конечного пользователя. Инструмент, называемый glide.exe взломает (с меньшей, чем хотелось бы эффективностью) PWL файлы. Имеется также документация о том, как вручную взломать кодирование этих PWL файлов, используя калькулятор. Продолжая сценарий, хакер продолжит собирать информацию относительно пользователя и формулировать нападение.
PWD: PWD файлы существуют на машинах, выполняющих FrontPage или Персональный Webserver. Эти файлы включают имя пользователя открытым текстом и зашифрованный пароль, соответствующий аутентификации, необходимой, чтобы управлять website. Схема кодирования, используемая для этих паролей - стандартная DES-схема. Для взламывания DES существует много утилит, например John the ripper.
WS_FTP.ini: этот ini файл существует на машинах, использующих ws_ftp. Хотя автоматизированное эксустройство подачи пароля для этого файла только недавно было представлено в сообщество защиты, используемый механизм кодирования не очень силен. Пароль преобразован в шестнадцатиричный формат. Если цифра - в позиции N, то N добавлен к цифре. Полностью измените процесс, и Вы взломали эту схему кодирования. (Это, как известно, иногда работает для взламывания PMail.ini - Pegasus Mail и Prefs.js - Netscape.)
IDC files: IDC файлы обычно используются для связности конца к базам данных от webserver. Потому как этот тип подключения вообще требует идентификации, некоторые IDC файлы содержат комбинации имени пользователя/пароля, часто открытым текстом.
Waruser.dat: это один из файлов конфигурации для WarFTP, популярного Win32 FTP сервера. Этот специфический dat файл может содержать административный пароль непосредственно для FTP сервера.
$winnt$.inf: В течение автоматической инсталляции WindowsNT, процесс установки требует информационных файлов. Как остаток этого автоматического инсталляционного процесса, файл, называемый $winnt$.inf, может существовать в каталоге %systemroot%system32. Этот файл может содержать имя пользователя и комбинацию пароля аккаунта, которая использовалась в течение инсталляции.
Sam _: хотя давно известно, что база данных SAM может представлять проблему, если она попала в неправильные руки, много людей забывают об этом. Много потенциальных хакеров спросили себя, как они могли бы скопировать базу данных SAM, если они могли бы установить диск поперек сети. Хорошо, обычно это не возможно, потому что NT сервер, с которым Вы связаны, выполняется, и в то время как он выполняется, он блокирует SAM. Однако, если администратор создал резервный диск, копия SAM должна быть расположена в каталоге %systemroot% epair. Этот файл будет назван Sam _. Эта копия по умолчанию доступна для чтения каждому. Используя копию утилиты samdump, Вы можете извлечь комбинации имени пользователя/пароля из скопированного SAM.
ExchVerify.log: файл ExchVerify.log создан Cheyenne/Innoculan/ArcServe. Обычно создаваемый инсталляцией программного обеспечения Cheyenne/Innoculan/ArcServe, этот файл проживает в корне диска - где программная инсталляция имела место. Этот файл может содержать чрезвычайно важную информацию, как показано ниже:
<EXCH-VERIFY>: ExchAuthenticate() called with
NTServerName:[SAMPLESERVER]
NTDomainName[SAMPLESERVER] adminMailbox:[administrator]
adminLoginName:[administrator]
password:[PASSWORD]
Само собой разумеется, файл содержит информацию, которую хакер может легко использовать, чтобы поставить под угрозу целостность вашей сети.
Profile.tfm: файл Profile.tfm, который создан программным обеспечением AcornMail, клиентом POP3. При написании этого документа, AcornMail начал получать много внимания от сообщества интернета. После осмотра программного обеспечения, мы нашли, что это - эффективный POP3 клиент, но инсталляция не NTFS дружественная. После инсталляции программного обеспечения, мы начали проверять файлы, созданные AcornMail. Мы нашли, что файл Profile.tfm содержит комбинацию имени пользователя/пароля. Сначала, мы решили, что программное обеспечение было вполне ok, потому что оно действительно хранило пароль в зашифрованном состоянии. Но потом мы поняли, что разрешения на файле profile.tfm были установлены в полный доступ для каждого. Это создаёт проблемы, потому что любой может получить копию файла и включить этот файл в свою собственную инсталляцию AcornMail. Тогда хакер войдет в систему с сохраненной информацией. Ниже - сбор данных только при помощи Network Monitor.
00000000 00 01 70 4C 67 80 98 ED A1 00 01 01 08 00 45 00 ..pLg.........E.
00000010 00 4A EA A7 40 00 3D 06 14 88 CF 62 C0 53 D1 36 .J..@.=....b.S.6
00000020 DD 91 00 6E 04 44 F6 1E 84 D6 00 32 51 EB 50 18 ...n.D.....2Q.P.
00000030 22 38 64 9E 00 00 2B 4F 4B 20 50 61 73 73 77 6F "8d...+OK.Passwo
00000040 72 64 20 72 65 71 75 69 72 65 64 20 66 6F 72 20 rd.required.for.
00000050 68 6B 69 72 6B 2E 0D 0A jjohn...
00000000 98 ED A1 00 01 01 00 01 70 4C 67 80 08 00 45 00 ........pLg...E.
00000010 00 36 A4 02 40 00 80 06 18 41 D1 36 DD 91 CF 62 .6..@....A.6...b
00000020 C0 53 04 44 00 6E 00 32 51 EB F6 1E 84 F8 50 18 .S.D.n.2Q.....P.
00000030 21 AC 99 90 00 00 50 41 53 53 20 67 68 6F 73 74 !.....PASS.xerox
00000040 37 33 0D 0A 63..
Как Вы можете видеть, имя пользователя/пароль действительно пропускаютчистым текстом. Это не ошибка AcornMail.
Теперь, когда мы обсудили файлы, которые хакер может желать приобрести, если он получает доступ к вашему жесткому диску, давайте обсудим Троянскую установку. Если и есть одна вещь, которая может получить для хакера тонну информации, то это - троянская установка. Нападение на ресурс открытого файла вообще делает троянскую установку чрезвычайно лёгкой. Один из самых легких и наиболее информативных троянов - утилита PWDUMP, обернутая в пакетном файле. Если всё подготовлено правильно, пакетный файл выполнится свернутым, выполнит утилиту PWDUMP, удалит её после того, как она выполнила ее задачу, и наконец сотрёт себя.
Правила: адресат должен быть NT машиной, и конечный пользователь, выполняющий трояна должен быть администратором, так что хакер помещает пакетный файл в папку запуска Администраторов и ждет. Следующий раз, когда Администратор войдет в машину, пакетный файл выполняется и собирает комбинации имени пользователя/пароля. Тогда хакер соединяется снова с машиной через совместное использование файла и забирает результаты.
Другое хорошее нападение, которое хакер может попробовать, - это размещение пакета keylogger в папке запуска. Это может обычно делаться любым пользователем, не только администратором. Он соберет все нажатия клавиш пользователя, кроме начальных реквизитов входа в систему (из-за архитектуры NT, которая останавливает все процессы режима пользователя в течение входа в систему). Потом хакер соединяется снова с целевой машиной в более позднее время и забирает зарегистрированные нажатия клавиш.
Как предотвратить подобные нападения ? Не использовать элементы, доступные каждой группе, разрабатывать сильные схемы пароля в вашей среде. Если хакер натолкнется на сервер, который запрашивает его относительно аутентификации на каждом повороте, возможно что хакер отстанет. Хотя большинство хакеров продолжит атаку с применением грубой силы.
Несомненно наиболее обычный инструмент для грубой силы NetBIOS-нападения - это NAT. NAT позволит пользователю автоматизировать сетевые команды подключения, использующие список возможных имен пользователя и паролей. NAT будет пытаться соединяться с удаленной машиной, используя каждое имя пользователя и каждый пароль в обеспеченных списках. Это может быть длинный процесс, но часто хакер будет использовать сокращенный список обычных паролей и иногда это выходит. Хакер создаст свой список из имен пользователя, используя информацию, собранную методами, обсужденными выше. Список пользователей, который хакер будет использовать, будет также создан из подбираемой информации.
Хакер может задать конкретный IP-адрес для атаки или он может задать полный диапазон адресов IP. NAT будет старательно работать, чтобы выполнить задачу, все время выдавая сформированные сообщения.
Ниже - фактический файл результатов реального нападения NAT. Хотя разрешение на это нападение было дано, адрес IP был изменен, чтобы защитить адресата.
[*]--- Reading usernames from userlist.txt
[*]--- Reading passwords from passlist.txt
[*]--- Checking host: 0.0.0.0
[*]--- Obtaining list of remote NetBIOS names
[*]--- Attempting to connect with name: *
[*]--- Unable to connect
[*]--- Attempting to connect with name: *SMBSERVER
[*]--- CONNECTED with name: *SMBSERVER
[*]--- Attempting to connect with protocol: MICROSOFT NETWORKS 1.03
[*]--- Server time is Tue Oct 14 11:33:46 1997
[*]--- Timezone is UTC-4.0
[*]--- Remote server wants us to encrypt, telling it not to
[*]--- Attempting to connect with name: *SMBSERVER
[*]--- CONNECTED with name: *SMBSERVER
[*]--- Attempting to establish session
[*]--- Was not able to establish session with no password
[*]--- Attempting to connect with Username: `ADMINISTRATOR' Password: `ADMINISTRATOR'
[*]--- Attempting to connect with Username: `ADMINISTRATOR' Password: `GUEST'
[*]--- Attempting to connect with Username: `ADMINISTRATOR' Password: `ROOT'
[*]--- Attempting to connect with Username: `ADMINISTRATOR' Password: `ADMIN'
[*]--- Attempting to connect with Username: `ADMINISTRATOR' Password: `PASSWORD'
[*]--- CONNECTED: Username: `ADMINISTRATOR' Password: `PASSWORD'
[*]--- Obtained server information:
Server=[AENEMA] User=[] Workgroup=[STATICA] Domain=[]
[*]--- Obtained listing of shares:
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk: Remote Admin
C$ Disk: Default share
D$ Disk: Default share
E$ Disk: Default share
HPLaser4 Printer: HP LaserJet 4Si
IPC$ IPC: Remote IPC
NETLOGON Disk: Logon server share
print$ Disk: Printer Drivers
Почтовый сервер
Mikrotik
VPN
3proxy
Шифрование
Squid
Резервное копирование
Защита почты
Виртуальные машины
Настройка сервера
java
kvm
Групповые политики
SELinux
OpenVPN
IPFW
WDS
Lightsquid
Samba
firewalld
systemd
Mobile
libvirt
Remote desktop
WiFi
Iptables
NAT
Postfix
Dovecot
Удаление данных
Софт
Безопасность
Winbox
User agent
Хостинг
Передача данных
Онлайн сервисы
Privacy
LetsEncrypt
VPN сервер
Настройка прокси
RRDTool
sendmail
Rsync
Linux
SSH
Система
Windows
Синхронизация
Облако
fail2ban
FreeBSD
Последние комментарии
Популярно:
Разделы статей:
только с письменного разрешения владельца сайта bozza.ru
Подскажите. подключение с ПК все работает все ок. Делал по вашей мурзилке.
Но при подключе...