Enhancing E-Mail Security With Procmail

Configuring the Sanitizer

 

Улучшенная e-mail безопасность с Procmail

Выбор конфигурации Sanitizer

 

Sanitizer прежде всего предназначен для обработки сообщений, поступающих непосредственно на почтовый сервер, где программное обеспечение почтового сервера выполняется на той же системе где и пользовательские почтовые ящики. Это называют «местной доставкой». В этом случае Procmail вероятно уже является заданным по умолчанию локальным агентом доставки и добавление Sanitizer очень легко.

Выполнение Sanitizer на почтовом сервере, который передает сообщения на другой сервер для окончательной доставки называется «почтовым релеем». Почта, которую передают от многих доменов в Интернете на сервер(ы) в вашей локальной сети которые поддерживают один или несколько доменов (например от общедоступных Sendmail шлюзов до корпоративных Microsoft Exchange серверов) называют «входящий релей». Когда почта возникает в вашей локальной сети и передается многим другим доменам в Интернете это называется «исходящий релей».

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

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

Работа sanitizer управляется переменными среды и файлами политик. Переменные среды должны быть установлены прежде чем сценарий sanitizer будет запущен. Обычно это делается в /etc/procmailrc глобальном файле procmail.

Все возможности Procmail все еще доступны и могут быть использованы для расширенного и улучшенного режима работы sanitizer.

Вот пример /etc/procmailrc файла:

 

PATH="/usr/bin:$PATH:/usr/local/bin"
SHELL=/bin/sh

POISONED_EXECUTABLES=/etc/procmail/poisoned
STRIPPED_EXECUTABLES=/etc/procmail/stripped
SECURITY_NOTIFY="postmaster, security-dude"
SECURITY_NOTIFY_VERBOSE="virus-checker"
SECURITY_NOTIFY_SENDER=/etc/procmail/local-email-security-policy.txt
SECRET="CHANGE THIS"
SECURITY_POISON_WINEXE=YES

# Этот файл уже должен существовать с надлежащими правами доступа (rw--w--w-):
 SECURITY_QUARANTINE=/var/spool/mail/quarantine

# Альтернативно используйте на каждого пользователя карантин:
 SECURITY_QUARANTINE=$HOME/quarantine

POISONED_SCORE=25
# Этот файл уже должен существовать с надлежащими правами доступа (rw--w--w-):
SCORE_HISTORY=/var/log/macro-scanner-scores

# Альтернативно используйте для каждого пользователя регистрацию оценок:
SCORE_HISTORY=$HOME/macro-scanner-scores

DROPPRIVS=YES
# Этот файл уже должен существовать с надлежащими правами доступа (rw--w--w-):
 LOGFILE=$HOME/procmail.log

# Альтернативно используйте для каждого пользователя файл регистрации:
 LOGFILE=$HOME/procmail.log

# В завершение установки теперь запустите sanitizer...
 INCLUDERC=/etc/procmail/html-trap.procmail

# Сбросьте некоторые веи, чтобы избежать пропуск информации к

# пользователям...
 POISONED_EXECUTABLES=
SECURITY_NOTIFY=
SECURITY_NOTIFY_VERBOSE=
SECURITY_NOTIFY_SENDER=
SECURITY_QUARANTINE=
SECRET=

 

Это самая основная конфигурация.

Конечно, если вы уже имеете некоторый /etc/procmailrc файл, вы можете включить вышеупомянутую конфигурационную информацию и

INCLUDERC=/etc/procmail/html-trap.procmail вызовет то что там уже находится.

Sanitizer опции настройки

MANGLE_EXTENSIONS список расширений имен файлов искаженных и возможно зараженных.

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

ext|ext|ext|ex[ts]|etc

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

Если вы хотите включить список подобных расширений, например DOC для файлов документов Word или DOT для шаблонов документов Word, вы можете объединить их подобно этому: do[ct] Это означает «DOC» или «DOT».

Обратите внимание, что список MANGLE_EXTENSIONS который вы вводите должен весь размещаться на одной строке.

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

1. Это препятствует получателю выполнять вложение просто двойным щелчком по нему. Запуск вложений этим способом может обойти антивирусные сканеры. Если получатель должен сохранить вложение и переименовать его, тогда антивирусное программное обеспечение будет иметь возможность просканировать их.

2. Это изменяет имя вложения так, чтобы некоторый сценарий, закодированный в сообщении ищет некоторое вложение, которое теперь не будет найдено. Это создает трудности некоторым автоматически запускаемым опасным мелочам сделать что-либо.

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

MANGLE_EXTENSIONS='html?|exe|com|cmd|bat|pif|sc[rt]|lnk|dll|ocx|do[ct]|xl[swt]|p[po]t|rtf|vb[se]?|hta|p[lm]|sh[bs]|hlp|chm|eml|ws[cfh]|ad[ep]|jse?|md[abew]|ms[ip]|reg|as[dfx]|c[ip]l|pps|wm[avszd]|vcf|nws|wsz|\{[-0-9a-f]+\}'

Как вы видите, заданный по умолчанию список MANGLE_EXTENSIONS обширен, так что заданная по умолчанию инсталляция sanitizer будет довольно параноидальна. Вероятно вы будете хотеть разрешить документы Office и .EML, .VCF и .HTML расширения если вы используете sanitizer в установке поставщика Интернет-сервиса.

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

Чтобы сделать это, вам нужно добавить кое-что подобно следующему к вашему /etc/procmailrc перед вызовом INCLUDERC=/etc/procmail/html-trap.procmail:

:0
* ^From:.*<[a-z0-9]+@mydomain.com>
* ^To:.*<[a-z0-9]+@mydomain.com>
{
     # Не корежить документы Office MANGLE_EXTENSIONS='html?|exe|com|cmd|bat|pif|sc[rt]|lnk|dll|ocx|dot|xl[wt]|p[po]t|rtf|vb[se]?|hta|p[lm]|sh[bs]|hlp|chm|eml|ws[cfh]|ad[ep]|jse?|md[abew]|ms[ip]|reg|as[dfx]|c[ip]l|pps|asx|wm[avszd]|vcf|nws|wsz|\{[-0-9a-f]+\}' }

Обратите внимание, что “doc” и “xls” не присутствуют в этом заказном списке MANGLE_EXTENSIONS.

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

В текущем выпуске sanitizer только те расширения появляются в списке на искорежение, которые считаются для удаления или заражения.

Удаление некоторых расширений из MANGLE списка означает. что вы не будете способны счищать зараженные файлы с этим расширением.

Обратите внимание: некоторые расширения «специальными» и всегда учитываются для демонтажа от заражения, независимо от того, корежатся ли они. Файлы Microsoft Office (.DOC.DOT.XLS.RTF, и т.д.) и ZIP архивы (.ZIP) будут отмечаться исключительными и зараженными даже если они не находятся в MANGLE списке. Расширение ZIP никогда не будет добавляться к заданному по умолчанию списку MANGLE.

Обратите внимание: эта модель в скором может измениться чтобы быть более гибкой и простой в настройке. Смотрите будущий документ руководств для более полной информации.

ВАЖНОЕ ПРИМЕЧАНИЕ: CLSID соответствие "\{[-0-9a-f]+\}" не должно использоваться с sanitizer до 1.130 это заставит их разрушаться. Ели вы хотите корежить/заражать CLSID-именованные файлы вы должны обновить до 1.130 или более новой.

Препроцессор «устранения» который упрощает установку MANGLE_EXTENSIONS, доступен. Пожалуйста смотрите на это, если Вы используете sanitizer в установке поставщика Internet-сервиса или в любом приложении, где Вы желаете, чтобы пользователи были способными выбрать их собственный уровень защиты. Если кто-то хочет создать для этого web-интерфейс, я уверен, множество людей были бы ему благодарны.

 

POISONED_EXECUTABLES: Название файла политики, содержащего спецификации файлов по заражению.

Эта переменная определяет название файла, содержащего список имен файла вложения, чтобы считать "отравленным". Эти имена файла могут содержать подстановочные знаки. См. обсуждение SECURITY_QUARANTINE для того, как отравленные сообщения обработаны.

Спецификация файла имен может сопровождаться комментариями. Отделите комментарии от определенных имен файлов используя пробел или TAB. Если вы желаете включить пробел в спецификацию файла имен, используйте символ "\s" вместо того, чтобы использовать фактический пробел.  Для будущей совместимости вы должны начать текст комментария с символа “#” (стандартный цитирующий символ оболочки). См. ниже для примеров.

Текущая версия sanitizer только проверяет{отмечает} отравленный список имен файла, если расширение имени файла появляется в списке MANGLE_EXTENSIONS. Имена файла, расширения{продления} которых не появляются в списке MANGLE_EXTENSIONS, не могут быть отравлены, если бы не файлы Microsoft Office, которые являются "специальными". См. обсуждение MANGLE_EXTENSIONS.

Рекомендованное содержание этого файла может быть загружено. Краткая выборка:

Поскольку вирусы или саморазмножающиеся вирусы с определенными именами файла объявлены, те имена файла можно добавить к отравленному списку файлов. Если Вы хотите установить автоматический поиск отравленного списка файлов, который я поддерживаю, это - в http://www.impsec.org/email-tools/poisoned-files (пожалуйста используйте ваше самое близкое зеркало).

Формат (использование) группового символа – стандартное проявление  синтаксиса регулярных выражений (набор правил), слегка меняемое, для того чтобы больше походить (соответствовать) обычно употребляемому имени globbing - «универсализация файловых имен»: период рассматривают как  явный (однозначный), т.е. не имеющий других толкований символов (один символ не может соответствовать другому), вопросительному знаку «?» соответствует только одно значение, а звездочка  может соответствовать определенному количеству значений. Это ведет к знакомым спецификациям имени файла подстановочного знака подобно " *. * " и "*.exe"", но также и поддерживает более сложные спецификации файла типа "happy[0-9]+.exe" и "*.[a-z][a-z][a-z]".

Perl (? ...) правильная конструкция регулярных выражений также поддерживается с 1.131.

См. рекомендованный список зараженных в качестве примера того, как это может использоваться, чтобы соответствовать всем именам файла кроме тех с некоторыми расширениями. См. также руководство по регулярным выражениям Perl (man perlex).

Имена файла в отравленном списке не зависимы от регистра: "IBMLS.EXE" соответствует "ibmls.exe".

Пример:

POISONED_EXECUTABLES="/etc/procmail/poisoned"

ОБРАТИТЕ ВНИМАНИЕ: этот образец может вскоре измениться, чтобы быть более гибким и легким для изменения.

 

STRIPPED_EXECUTABLES: Название файла политики содержащего спецификации файлов для раздевания.

Эта переменная определяет название файла содержащего список имен файла вложения, чтобы удалить сообщение. Эти имена файла могут содержать подстановочные знаки тем же самым способом как список зараженных. Спецификация имени файла может сопровождаться комментариями. Отделите комментарии от спецификаций имени файла, используя Space или TAB. Если вы желаете вкючить пробел в спецификацию имени файла, используйте символ "\s" вместо того чтобы фактически использовать пробел. Для будущей совместимости вы должны начинать текст комментария с символа "#".

Текущая версия sanitizer только проверяет раздетый список имен файла если расширение имени файла появляется в списке MANGLE_EXTENSIONS. Имена файла, расширения которых не появляются в списке MANGLE_EXTENSIONS, не могут быть удалены, если бы не файлы Microsoft Office, которые являются "специальными". См. обсуждение MANGLE_EXTENSIONS.

Демонтаж происходит прежде, чем отравление, и демонтированные вложения не отравляют  сообщение.

Удаленные вложения не могут быть восстановлены.

Имена файлов в списке на раздевание не зависят от регистра: "IBMLS.EXE" соответствует "ibmls.exe".

Пример:

 

    STRIPPED_EXECUTABLES = "/etc/procmail/stripped"

 

SECURITY_POISON_WINEXE: Проверяет вложения для магических строк Выполнимой программы Windows, на предмет обнаружения заражения.

Некоторые инструментальные средства Windows, когда имя представленного файла или MIME тип не точно отражают фактическое имя файла (например файл по имени "SOMETHING.WAV" показывает, что это звуковой файл который является фактически выполнимой программой), может просканировать файл на предмет наличия "магических срок" чтобы идентифицировать тип файла, и выполнить файл, если это – программа.

Sanitizer имеет простой сканер магических строк исполняемых программ Windows который может быть включен как другой уровень защиты. Если вложения сообщения не заражены именем файла, они могут также быть просмотрены для магических строк Исполняемой программы Windows и заражены если любая найдена. Этот сканер может быть включен SECURITY_POISON_WINEXE любым значением.

Обратите внимание, что, если Вы разрешаете выполнимые вложения для некоторых отправителей, Вы будете также хотеть сбросить SECURITY_POISON_WINEXE для тех отправителей также.

Пример:

 

    SECURITY_POISON_WINEXE=YES

 

   :0

    * ^From: trusted@partner.example.com

    {

        POISONED_EXECUTABLES =/etc/procmail/poison-list-for-trusted-senders

        SECURITY_POISON_WINEXE =

   }

 

 

DISABLE_MACRO_CHECK: Отключить сканирование файлов вложений Microsoft Office для опасных макросов.

Sanitizer содержит простейший сканер, который проверяет вложенные документы Microsoft Office (документы Word, электронные таблицы Excel, презентации PowerPoint, и т.д.) для внедренного VBA макроса, которые, кажется, делают сомнительные вещи - например, изменяя параметры настройки защиты, делая изменения системного реестра, или пишуут макросы к Стандартному шаблону Документа.

Документы будут просмотрены для макроса, даже если их расширения не появляются в списке MANGLE_EXTENSIONS. Это означает, что Вы можете удалить .DOC и .XLS от списка MANGLE_EXTENSIONS, чтобы делать ваших пользователей счастливыми, но все еще защититься сканером против макрооснованного нападения.

Если Вы не желаете, чтобы это макросканирование имело место, установите DISABLE_MACRO_CHECK в любое значение. Альтернативно Вы можете использовать версию sanitizer, который имеет макрокоманду, просматривающую удаленный код. Это может быть немного быстрее, поскольку тот код больше не должен быть откомпилирован для каждого обрабатываемого сообщения.

Если Вы действительно желаете просмотреть вложения документа, Вы будете должны установить два дополнительных инструментальных средства:

1.mimencode, который является частью пакета metamail. (или см. USE_CPAN ниже)

2.mktemp, от OpenBSD программного архива. (или см. USE_CPAN ниже)

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

На самом деле, много коммерческих вирусных сканеров фактически не удаляют вредоносные макросы; вместо этого, они карежат достаточно, чтобы отключить их и оставить на месте, sanitizer очень вероятно обнаружит достаточно многие фрагменты макросов, чтобы считать документ как все еще зараженый. Если это случается, предложите отправителю документа, чтобы документ был сохранен в формате, который не поддерживает макросов вообще, типа Rich Text (RTF), и отправит в таком виде. Альтернативно, отправитель может сжать документ, используя инструмент типа Winzip или gzip. Когда получатель распаковывает документ, вирусный сканер будет иметь возможность исследовать эго.

Предложения по тому что рассматривать как опасные макрокоманды – приветствуются, как примеры макро-инфицированных документов.

Пример:

DISABLE_MACRO_CHECK=YES

 

POISONED_SCORE: Макросканер оценивает, как рассматривать зараженные вложения.

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

Минимальный POISONED_SCORE - 5, который является очень низким. Значение по умолчанию - 25.

Пример:

POISONED_SCORE=25

 

SCORE_HISTORY: Где вести log-файл подсчета макросканера.

Если Вы хотели бы сохранить хронологию макро подсчетов для того, чтобы определить профиль, чтобы видеть, действительно ли ваш POISONED_SCORE установлен на разумное значение, устанавливает SCORE_HISTORY в имя файла. Счет каждого просмотренного документа будет сохранен в этот файл.

Этот файл должен существовать с разрешениями rw--w--w- так, чтобы все пользователи способны делать запись их множества сканера, или каждый пользователь должен иметь их собственный личный журнал. Sanitizer просматривает привилегии перед сканированием сообщений, так этот журнал должны быть перезаписываемы пользователем, получающим сообщение. Это - очень хорошая идея, чтобы проверить запись в глобальный log файл как постоянный пользователь после того, как вы создали эго как root, обеспечить что все разрешения и на его родительские каталоги правильны.

Пример:

SCORE_HISTORY="/var/spool/mail/macro-scanner-scores"

SCORE_DETAILS: Как вычисляется макросчет?

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

Пример:

SCORE_DETAILS=YES

 

SCORE_ONLY: Только сканирование для оценки, не зараженный основанный на подсчете.

Если Вы желаете сканировать и записывать подсчет, но никогда не считать документы зараженными на основе сканирования, то установите SCORE_ONLY в любое значение.

Это не рекомендуется, т.к. это может позволить макро червям и вирусам проникнуть внутрь. Вместо этого, усановите POISONED_SCORE к высокому значению (75 - 100), которое заманит в ловушку очевидно зараженные документы пока вам разрешен доступ к профилям границ документа.

Пример:

SCORE_ONLY=YES

 

SECURITY_OFFICE_EMBED_SCORE: Счет, чтобы определлить внедренные файлы и URL.

Файлы Microsoft Office (документы Word и электронные таблицы Excel) могут включать ссылки к внешним файлы и URL. Скрытые ссылки к внешним файлам могут использоваться, чтобы своровать файлы с вашего компьютера, и ссылки к URL могут использоваться как "жучок" в документ, чтобы проследить его местоположение.

Макро сканер проверяет внедренные файлы и URL и устанавливает их счет. Счет - 99 по умолчанию, которого достаточно, чтобы отравить документ в большинстве случаев. Если Вы желаете уменьшить уровень паранойи сканера, устанавливаете SECURITY_OFFICE_EMBED_SCORE в номер ниже чем 99.

Пример:

SECURITY_OFFICE_EMBED_SCORE=20

 

SECURITY_QUARANTINE: Где сохранять зараженные сообщения.

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

Изоляция сообщения предотвращает доставку сообщений с зараженными вложениями предназначенному получателю. Это - единственный случай, где sanitizer - "рецепт доставки" - во всех других случаях, это - просто фильтр.

Поскольку sanitizer понижает все привилегии перед сканированием сообщения, этот файл должен уже существовать (sanitizer не может надежно делать это на лету) и должен иметь разрешения rw--w--w-, или каждый пользователь должен иметь их собственный личный карантинный файл. Это - очень хорошая идея, чтобы проверить запись в глобальный карантинный файлу как правильный пользователь после того, как Вы создали это как root, гарантировать что все разрешения на него, и его родительские каталоги правильны.

Этот файл - стандартный файл почтового ящика Формата Беркли и может управляться, используя любую программу почты Unix, или редактироваться используя текстовый редактор, для искорежения и возвращения изолированного сообщения.

Если Вы предпочитаете видеть изолированные сообщения как "одно сообщение в файл", тогда укажите SECURITY_QUARANTINE на каталог вместо файла. Каталог должен уже существовать и должен иметь разрешения rwx-wx-wx, или каждый пользователь должен иметь их собственный личный карантинный каталог.

Если SECURITY_QUARANTINE не определен, сообщения будут доставляться их предназначенным получателям, даже если они содержат опасные вложения. Это - вероятно не хорошая идея, если Вы не поставщик Internet-сервиса.

Пример:

SECURITY_QUARANTINE=/var/spool/mail/quarantine

 

SECURITY_QUARANTINE_OPTIONAL: Если карантин сообщений сбоит, не возвращать это.

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

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

Пример:

SECURITY_QUARANTINE_OPTIONAL=YES

 

SECURITY_QUARANTINE_LOCKFILE: Использовать lock-файл не по умолчанию, когда записывается в карантин.

Если по каким-то причинам lock-файл не может быть создан (то есть правильные пользователи не имеют разрешения записи к каталогу), и Вы видите предупреждения подобно "Lock failure on /var/spool/mail/security.lock" в вашем procmail log файле, вы можете определить lockfile в глобально-записываемом размещении используя SECURITY_QUARANTINE_LOCKFILE.

Пример:

SECURITY_QUARANTINE_LOCKFILE="/var/tmp/quarantine.lock"

 

SECURITY_NOTIFY: Кого уведомлять, если обнаружена атака.

Эта переменная среды содержит список с разделителями-запятыми адресов электронной почты, которым посылают краткое уведомление, когда зараженное сообщение заманено в ловушку.

Это уведомление будет включать заголовки сообщения из захваченного сообщения.

Удостоверьтесь, что Вы используете кавычки, если Вы помещаете пробелы в список имен.

Список SECURITY_NOTIFY также уведомлен, если изоляция зараженного сообщения терпит неудачу.

Пример:

SECURITY_NOTIFY="postmaster, dilbert@example.com"

 

SECURITY_NOTIFY_VERBOSE: Кого уведомлять, если обнаружена атака.

SECURITY_NOTIFY_VERBOSE - точно так же как SECURITY_NOTIFY, за исключением того, что полное зараженное сообщение включено в уведомление вместо только заголовков.

Это может использоваться вместо карантинного файла, хотя формат не является столь дружественным.

Пример:

SECURITY_NOTIFY_VERBOSE=wally@example.com, phb@example.com

 

SECURITY_NOTIFY_SENDER: Должен ли отправитель сообщения нападения быть уведомленным?

Если SECURITY_NOTIFY_SENDER установлен на любое значение, предупреждающее сообщение будут посылать человеку, который породил отравленное сообщение. Для того,  чтобы это произошло, SECURITY_NOTIFY также должен быть установлен.

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

Так как sanitizer ожидает имя файла в SECURITY_NOTIFY_SENDER, это требует специального предостережения. Если Вы хотите уведомить отправителя, но не хотите переделать сообщение, удостоверьтесь, что любые значения которые Вы устанавливаете в SECURITY_NOTIFY_SENDER, не представляют фактический файл. "SECURITY_NOTIFY_SENDER=YES" это хорошо. "SECURITY_NOTIFY_SENDER=/etc/passwd" было бы плохим выбором.

Если Вы хотите явно подавить уведомление отправителя, устанавливаете SECURITY_NOTIFY_SENDER в пустую строку:

SECURITY_NOTIFY_SENDER = ""

С включенным Smart Reply Suppression (интеллектуальным подавлением ответа) и подходящей информацией в SECURITY_TRUSTED_MTAS должна быть безопасно включена эта опция без опасения генерации большого количества "обратного рассеяния" из-за подделанных адресов электронной почты.  Однако, УДОСТОВЕРЬТЕСЬ, что Вы выполняете версию  Sanitizer! не менее 1.140.

Пример:

SECURITY_NOTIFY_SENDER=YES

SECURITY_NOTIFY_SENDER="/etc/procmail/policy-note.txt"

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

 

SECURITY_NOTIFY_SENDER_POSTMASTER: Должен ли постмастер домена отправителя быть уведомленным?

Если SECURITY_NOTIFY_SENDER_POSTMASTER установлен на любое значение, постмастер домена отправителя будет также уведомлен. Это полезно, если сообщение исходит от компании, но вероятно бессмысленно, если сообщение - от большого поставщика Internet-сервиса типа MSN или AT&T.

Пример:

SECURITY_NOTIFY_SENDER_POSTMASTER=YES

 

 

SECURITY_NOTIFY_SENDER_ABUSE: Надо ли злоупотребление@ в домене отправителя уведомлять?

Если SECURITY_NOTIFY_SENDER_POSTMASTER и SECURITY_NOTIFY_SENDER_ABUSE установлены на любое значение, постмастер домена отправителя будет также уведомлен.

Это может быть полезно, если сообщение происходит из большого поставщика Internet-сервиса типа MSN или AT&T. Обратите внимание, что SECURITY_NOTIFY_SENDER_ABUSE зависит от устанавливаемого SECURITY_NOTIFY_SENDER_POSTMASTER.

Пример:

SECURITY_NOTIFY_SENDER_ABUSE=YES

 

SECURITY_DISABLE_SMART_REPLY: Должно ли Smart Reply Suppression (интеллектуальное подавление ответа) быть заблокировано?

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

Чтобы уменьшить отсылки уведомлений подделанному или несоответствующему адресу отправителя, адрес отправителя сравнивается Обратным DNS доменов в доверенном Received: заголовок(ки) - видит обсуждение SECURITY_TRUSTED_MTAS ниже. Если доверенный Received не оказывается поддерживаемым доменом отправителя, никакое уведомление не посылают назад отправителю отравленного сообщения.

Также, если сообщение, кажется, прибывает через список рассылки, уведомление подавляется.

Если Вы желаете уведомить отправителя независимо от того, выглядит ли адрес отправителя правильным или было ли сообщение получено через список адресатов, установите SECURITY_DISABLE_SMART_REPLY в некоторую величину. Выполнение этого не рекомендуется, поскольку саморазмножающиеся вирусы подделывают адреса отправителя, и немые ответы преследуют невинные третьи лица.

Пример:

SECURITY_DISABLE_SMART_REPLY=YES

 

SECURITY_TRUSTED_MTAS: Основание Smart Reply Suppression (интеллектуальное подавление ответа) на каком Received: заголовках? (1.140+)

Многие атакующие сообщения подделали Received: заголовки в попытке затенить фактическое начало координат нападения. Единственный Received: заголовки, которым Вы можете доверять - вставленные MTAs под вашим управлением, или под управлением того, кому Вы доверяете (типа вашего поставщика Internet-сервиса).

SECURITY_TRUSTED_MTAS перечисляет MTAs чьим Received: заголовкам Вы доверяете, чтобы быть правильным. Если Вы не устанавливаете это, то по умолчанию на компьютере sanitizer продолжается. Если MTA, который получает вашу почту от Internet - различная машина (например бастион хост или сервер почты поставщика Internet-сервиса), то добавьте что название машины к SECURITY_TRUSTED_MTAS.

Посмотрите Ваш Received: заголовки, чтобы определить имена для этой переменной. Например, если Ваш Received: заголовки были этими (выборка из сообщения нападения саморазмножающегося вируса):

 

Received: from localhost (IDENT:root@localhost [127.0.0.1])
     by gypsy.impsec.org (8.9.3/8.8.8) with ESMTP id NAA04022
     for ; Mon, 26 Jan 2004 13:21:35 -0800
Received: from localhost
     by localhost with POP3 (fetchmail-5.2.4)
     for jhardin@localhost (single-drop); Mon, 26 Jan 2004 13:21:35 -0800 (PST)
Received: from sylmic.com (rtss13.ssss.gouv.qc.ca [199.243.239.13])
     by hq.impsec.org (8.11.6/8.9.3) with ESMTP id i0QLKq827621
     for ; Mon, 26 Jan 2004 13:20:54 -0800

 

... Вы поместили бы "hq.impsec.org" в вашу SECURITY_TRUSTED_MTAS переменную. Это - система, Вы полагаете, что наиболее близка к Internet. (Примечание, как HELO имя домена и обратный DNS называют в hq.impsec.org Received: заголовок не соответствует. Это сообщение, кажется, подделка и не будет отвечаться).

Примечания формата:

    Периоды Escape в имени хоста с наклонными чертами влево: \.

    Разделение множественных имен хостов вертикальными полосами: |

    Не должно быть никаких пробельных символов.

    Список не должен начинаться или заканчиваться вертикальной полосой.

Вы не должны устанавливать эту переменную, если sanitizer выполняется на MTA, который получает электронную почту непосредственно от Internet. sanitizer по умолчанию доверяет компьютеру, который работает.

Пример:

SECURITY_TRUSTED_MTAS="hq\.impsec\.org|mail\.myisp\.com"

 

SECURITY_LOCAL_POSTMASTER: Отвергать от адреса уведомительные сообщения.

По умолчанию, уведомительные сообщения - от "постмастера". Sanitizer отставляет домен в сторону в предположении, что местный MTA добавит правильный местный домен, поскольку это обрабатывает уведомительные сообщения.

Если Вы желаете отменить адрес отправителя уведомления, например исходить из сообщений "abuse@yourdomain.com" вместо "postmaster@yourdomain.com" или обеспечивать явное имя домена, устанавливаете SECURITY_LOCAL_POSTMASTER в предпочтительный from address. Имя домена не требуется и будет обеспечено вашим MTA если опущено.

Пожалуйста не определяйте домен, за который Вы не ответственны.

Пример:

SECURITY_LOCAL_POSTMASTER="abuse"

SECURITY_LOCAL_POSTMASTER="postmaster@bighostingcompany.com"

 

SECURITY_NOTIFY_RECIPIENT: Должен предназначенный получатель сообщения нападения быть уведомленным?

Если Вы желаете уведомить получателя сообщения, что сообщение к нему было заражено и изолировано, установите SECURITY_NOTIFY_RECIPIENT в некоторое значение. Это может представить имя файла тем же самым способом как SECURITY_NOTIFY_SENDER.

SECURITY_NOTIFY_RECIPIENT не был хорошо проверен на реле очистки, так если машина очистки - релей (против поставки почты в местном масштабе), Вы не должны использовать SECURITY_NOTIFY_RECIPIENT.

Пример:

SECURITY_NOTIFY_RECIPIENT="/etc/procmail/quarantined.txt"

 

SECURITY_STRIP_MSTNEF: Вырезать MS-TNEF вложения полностью.

Microsoft Outlook и Microsoft Exchange поддерживают отправку электронной почты используя формат, названный "Outlook Rich Text". Среди других вещей, это имеет эффект связать все вложения файла, так же как другие данные, в частное вложение Формата Microsoft, обычно с названием "WINMAIL.DAT". Этот формат называют "MS-TNEF", и его не совсем понятен не- Microsoft вским почтовым программам.

MS-TNEF вложения не могут быть просмотрены или санированы и могут содержать опасное содержание, которое sanitizer не может обнаружить или обезопасить. Информация конфигурации о компьютере отправителя также внедрена в "WINMAIL.DAT" файл, который может пропустить чувствительные к защите подробности к посторонним.

Microsoft предлагает, что MS-TNEF вложения являются только подходящими для использования в пределах вашей собственной компании, и рекомендует, чтобы это не использовалось для почты Internet.

Если Вы устанавливаете SECURITY_STRIP_MSTNEF в любое значение, эти вложения будут удалены от сообщения, и это будет доставлено предназначенному получателю с примечанием, что это случилось. Сообщение не будет отравлено. Вложения файла не будут восстанавливаемы, так как они содержались в удаленном MS-TNEF вложении.

См. http://support.microsoft.com/support/kb/articles/Q241/5/38.ASP, http://support.microsoft.com/support/kb/articles/Q138/0/53.ASP и http://www.microsoft.com/TechNet/exchange/2505ch10.asp для подробной информации.

Пример:

SECURITY_STRIP_MSTNEF=YES

 

STRIPPED_WARNING: Текст, который необходимо вставить, когда вложения (кроме MS-TNEF) удалены.

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

Пример:

STRIPPED_WARNING="

SECURITY ALERT!

Attachment stripped from message and discarded.
To receive future attachments, bring donuts to your postmaster right away.
"

 

 

(Вложение удалило из сообщения и отвергнутый.

Чтобы получать будущие вложения, принесите пончики вашему постмастеру сразу же.)

 

POISONED_WARNING: Текст, чтобы включить, когда вложения отравлены.

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

Пример:

POISONED_WARNING="

SECURITY ALERT!

Somebody is attacking you!

Run in circles! Scream and shout!

"

 

 

TNEF_WARNING: Текст, чтобы включить, когда MS-TNEF вложения удалены.

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

 Пример:

TNEF_WARNING="

SECURITY ALERT!

TNEF is the Devil's Spawn.

"

 

 

SECURITY_DEFANG_SIGNED: Выхватывание подписанных сообщений.

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

Если Вы желаете принимать предупреждения "неудавшаяся проверка подписи" чтобы улучшить защиту, Вы можете сказать, чтобы sanitizer к выхваченным сообщениям подписал также.

Пример:

SECURITY_DEFANG_SIGNED=Y

 

SECURITY_TRUST_HTML: Доверительный HTML код в сообщении.

Отключить всю защиту от выполнения HTML содержимого. Скрипты не будут выхватываться. Веб – жучки не будут выхватываться. Тэги стиля не будут выхватываться.

Пример:

SECURITY_TRUST_HTML=Y

 

DEFANG_WEBBUGS: Отключить встроенные изображения и звуки.

" Веб – жучки " являются маленькими изображениями (типично только один пиксель в размере), которые используются чтобы прослеживать почтовое сообщение. Идентификация информации включена в изображение URL, и когда почтовая программа С ПОДДЕРЖКОЙ HTML пытается отображать сообщение, местоположение сообщения может быть прослежено (так как почтовый клиент будет пытаться отыскивать изображение от сервера сети, данного в web-жучке URL) и зарегистрировано.

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

То же самое может быть сделано, используя фоновые звуковые файлы, и через изображения-ссылки, внедренные в документы Microsoft Office.

Если Вы считаете это нарушением вашей конфиденциальности, Вы можете установить DEFANG_WEBBUGS в любое значение, и sanitizer будет выхватывать все <IMAGE> и <BGSOUND> тэги, чтобы предотвратить это. Вы можете еще отыскивать URL в теле сообщения и решать, действительно ли Вы желаете увидеть изображение или услышать звук.

К сожалению это не будет вырезать web-жучков из Офисных документов. В будущем sanitizer может просмотреть для присутствия завирусованных документов и добавить предупреждение.

Пример:

DEFANG_WEBBUGS=YES

 

SECURITY_TRUST_STYLE_TAGS: Отключить тэги стиля отцепления.

<STYLE> тэги дают автору хороший контроль над видом HTML содержимого, когда оно отображено. Это широко используется почтовыми программами с поддержкой HTML, но возможный вектор нападения используемый через снабжающие команды скриптов вместо параметров настройки вида.

По умолчанию sanitizer отцепляет тэги <STYLE>, но это может оставить дополнительный тэг конечного комментария HTML ("-> ") видимым в теле сообщения. Вы можете хотеть довериться тэгу <STYLE> в локально-сгенерированной почте и в то же время все еще отцеплять их в почте, полученной из Интернета.

Доверять тэгам <STYLE> в почте, полученной из Интернета – не рекомендуется.

Пример:

:0

* ^From:.*@mydomain.com>

* ^To:.*@mydomain.com>

{

SECURITY_TRUST_STYLE_TAGS=YES

}

 

SECURITY_NONOTIFY_LONGSUBJECT: Не уведомлять о чрезмерно длинных subjects.

Если Вас не тревожит, когда кто-то посылает Вам чрезмерно длинный Subject: заголовок, определите это в любую величину. Заголовок subject все еще будет усекаться, но в списке SECURITY_NOTIFY не будет говориться об этом.

Пример:

SECURITY_NONOTIFY_LONGSUBJECT=Y

 

SECRET: Короткая (20 символов или примерно) строка, выбранная наугад.

Это - короткая строка случайного текста (символы, и числа{номера} - избегают знаков препинания), который используется в нескольких местах, чтобы мешать кому - то подделывать{сколачивать} сообщение, которое обойдет некоторые части sanitizer.

Когда Вы устанавливаете sanitizer, устанавливают SECRET на какой-нибудь случайный “мусор”, и изменяют “мусор” как угодно часто.

Это неважная особенность.

Пример:

SECRET="hgsfd9734965q34o2ldgbl"

 

LOGFILE: Где сохранять sanitizer журнальные сообщения.

Снова, т.к. sanitizer снижает привилегии перед сканированием сообщений, этот файл должен быть перезаписываемым получателем сообщения. Это обычно устанавливается в "$HOME/procmail.log" (который помещает это в основной каталог получателя), но Вы можете установить централизованный журнал, в котором все пользователи регистрируют. Если вы это делаете, удостоверьтесь, что он существует с правами rw--w--w-.

Если Вы помещаете log-файл в домашний каталог пользователя, поместите DROPPRIVS=YES перед LOGFILE=строка как procmail открывает log-файл как только Вы говорите, куда идти log-файлу, и если это должно быть создано, это должно быть создано с разрешениями пользователя.

Если Вы используете глобальный журнал, это - очень хорошая идея, чтобы проверить запись в него как правильный пользователь после того, как Вы создали это как root, гарантировать что все разрешения на него, и его родительские каталоги правильны. Если журнал не перезаписываем, sanitizer будет не в состоянии просматривать сообщения.

Пример:

DROPPRIVS=YES

LOGFILE="$HOME/procmail.log"

 

DEBUG: Разрешить вывод некоторой отладочной информации от sanitizer.

Пример:

DEBUG=YES

 

DEBUG_VERBOSE: Включить подробную отладку sanitizer.

Это эквивалентно записи "VERBOSE=YES" в/etc/procmailrc. Так как понижающиеся привилегии сбрасывают подробную отладку procmail, Вы должны установить DEBUG_VERBOSE в некоторое значение чтобы сообщить sanitizer включать VERBOSE обратно после понижающихся привилегий.

Пример:

DEBUG_VERBOSE=YES

 

POISONED_WARNING: Изменить внедренное "отравленное вложение" предупреждающим текстом.

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

 

SECURITY WARNING!

The mail system has detected that the following attachment may contain hazardous program code, is a suspicious file type, or has a suspicious file name. Do not trust it. Contact your system administrator immediately.

(ПРЕДУПРЕЖДЕНИЕ ЗАЩИТЫ!

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

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

Пример:

POISONED_WARNING="
EEEK! Icky Microsoft Outlook worm detected! Turn off your computer RIGHT NOW!"

 

TNEF_WARNING: Замените внедренный текст предупреждения для удаленного MS-TNEF вложения.

Когда sanitizer раздевает, MS-TNEF вложение, вложение заменяется предупреждающим сообщением. Если Вы устанавливаете TNEF_WARNING в цитируемую многострочную строку, это заменит заданный по умолчанию текст:

SECURITY NOTICE:

The mail system has removed a Microsoft attachment for security reasons. The sender should disable sending Rich Text format in Outlook and disable sending TNEF to the Internet from their Microsoft Exchange gateway.

ПРИМЕЧАНИЕ ЗАЩИТЫ:

Почтовая система удалила вложение Microsoft из соображений безопасности. Отправитель должен отключить отправку Формата RTF в Outlook и отключить отправку TNEF в Internet из их шлюза Microsoft Exchange.

См. http://support.microsoft.com/support/kb/articles/Q241/5/38.ASP и http://www.microsoft.com/TechNet/exchange/2505ch10.asp для подробной информации.

Пример:

TNEF_WARNING="
MS-TNEF is the Devil's spawn."

 

MTA_FLAGS_CMDLN: Установите флаги командной строки MTA, режим “получения адресов из командной строки”.

Sanitizer разработан и проверен со старшей версией Sendmail как MTA. Если Вы используете более новую версию Sendmail, или полностью отличный MTA, вы возможно должны корректировать опции командной строки, применимых к программе отправки сообщений, которая используется, когда Sanitizer генерирует уведомительные сообщения.

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

Изменяя опции командной строки используемые к подчиненным сообщениям с адресом получателя, взятым из командной строки, установите MTA_FLAGS_CMDLN соответствующим вашему MTA. Чтобы определить "no options" ("нет вариантов"), используйте пустую строку " " (кавычка-пробел-кавычка), предпочтительней чем нулевая строка "" (кавычка-ничего-кавычка).

Пример:

MTA_FLAGS_CMDLN="-U"
MTA_FLAGS_CMDLN=" " (no options are needed by your mailer)

Если вы получаете ошибки подобные "sendmail: illegal option -- U", вы будете должны поместить второй (пустой) пример выше в ваш/etc/procmailrc файл перед вызовом Sanitizer.

 

MTA_FLAGS_HDRS: Установить флаги командной строки MTA в режим "получать адреса из заголовков сообщений".

Изменяя опции командной строки применяемые к представленным сообщениям с адресом получателя, взятым из заголовков настоящего представленного сообщения, устанавливает MTA_FLAGS_HDRS соответственно для вашего MTA.

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

Пример:

MTA_FLAGS_HDRS="-oi -t -f$SECURITY_LOCAL_POSTMASTER"

 

SECURITY_MSGID_LOG: Файл регистрации IDs отравленных сообщений.

Если Вы хотите сохранять в файле регистрации IDs-сообщения отравленные сообщения, определите SECURITY_MSGID_LOG, чтобы указать на глобально-перезаписываемый файл.

Это может быть полезно в случае, где вы не хотите копаться в карантине или лог-файле Procmail чтобы видеть то, что продолжилось. Например вы могли бы хотеть сделать "wc ‑l" на этом файле каждые пять минут для MRTG  чтобы копировать трафик отравленных сообщений.

Пример:

SECURITY_MSGID_LOG="/var/log/poisoned.log"

 

ZIPPED_EXECUTABLES: Название файла политик, содержащего спецификации файла заархивированных файлов которые являются причиной для карантина. (1.141 +)

Эта переменная определяет имя файла, содержащего список имен файлов, чтобы рассматривать их  "отравленным", если они появляются в пределах вложений ZIP архива. Эти имена файла могут содержать подстановочные знаки. См. обсуждение POISONED_EXECUTABLES для синтаксиса подстановочного знака. См. обсуждение SECURITY_QUARANTINE как отравленные сообщения обработаны.

ZIP архив содержащий отравленные имена файлов будет только изолирован. Вы не можете разобрать ZIP архив основанный на их содержании, но ZIP архивы теперь "специальны" тем же самым способом, которым документы Microsoft Office являются "специальными" – взятый в целом ZIP архив может быть отравлен или раздетый основываясь на имени архива (ZIP файла). Это означает, что, если Вы помещаете "*.zip" в ваш POISONED_EXECUTABLES, или STRIPPED_EXECUTABLES файлы вы не будете получать никаких вложений ZIP архива!

ZIP архивы могут быть просмотрены только на один уровень в глубину.

MANGLE_EXTENSIONS ограничивают НЕ ПРИМЕНЯТЬ к содержимому ZIP архива любое расширение, которое может быть определено в списке ZIPPED_EXECUTABLES.

Если ZIPPED_EXECUTABLES не определен, это будет значение по умолчанию к тому же самому как POISONED_EXECUTABLES (чтобы обеспечить заданную по умолчанию безопасную политику, а не заданную по умолчанию опасную).

Строго рекомендуется, чтобы Вы конфигурировали отдельный ZIPPED_EXECUTABLES файл политики, и добавили " *.html? ", "*.eml" и "*.msg" к этому. Есть саморазмножающиеся вирусы, которые полагаются на множественные уровни путаницы: заархивированное вложение, содержащее страницу HTML, которая содержит base64-закодированный .EXE файл, и первоначальное сообщение, содержит активный HTML, который автоматически открывает .ZIP файл.

Рекомендованное содержание этого файла может быть загружено.

Если Вы желаете просмотреть вложения ZIP архива, Вы будете должны установить три дополнительных инструментальных средства:

  1. mimencode, который является частью пакета metamail. (или см. USE_CPAN ниже)
  2. mktemp, от OpenBSD программного архива. (или см. USE_CPAN ниже),
  3. unzip.

Все эти инструменты поставляются с большинством дистрибутивов Linux. Для других операционных систем, вам вероятно придется скачать источники и непосредственно их скомпилировать.

Если Вы будете принимать заархивированные выполняемые программы из известных источников (например .DLL файлы от консультанта), тогда Вы должны создать список спецификации файла, который не включает "*.dll" и использовать для ZIPPED_EXECUTABLES, если сообщение - из того источника.

Пример: 

ZIPPED_EXECUTABLES=/etc/procmail/zipped_poison
 
:0
* ^From: trusted@partner.example.com
{
     ZIPPED_EXECUTABLES=/etc/procmail/trusted_zipped_poison
}

 

DISABLE_ZIP_SCAN: Отключить сканирование вложений ZIP архивов. (1.141+)

Если вы не желаете, чтобы имело место сканирование ZIP архивов, установите DISABLE_ZIP_SCAN в любое значение.

Пример:

DISABLE_ZIP_SCAN=YES

 

ZIPPED_WARNING: Измените внедренный текст предупреждения для вложений ZIP архивов отравленных по их содержимому.

Когда Sanitizer отравляет вложение ZIP архива, основываясь на содержимом файле письмо имеет вставленное в него предупреждающее сообщение. Если вы устанавливаете ZIPPED_WARNING в обрамленные кавычками строки, это заменит заданный по умолчанию текст:

SECURITY WARNING!

The mail system has detected that the preceding ZIP archive attachment contains suspicious files. Do not trust it. Contact your system administrator immediately.

The suspicious files in the archive are:

ПРЕДУПРЕЖДЕНИЕ БЕЗОПАСНОСТИ!

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

Подозрительные файлы в архиве:

Пример:

ZIPPED_WARNING="
Foiled an attempt to bypass security via a ZIP file. It contained:
"

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

 

ZIP_MAGIC_WARNING: Измените внедренный текст предупреждения для поддельного вложения ZIP архива. (1.141+)

Когда Sanitizer пытается просматривать вложение ZIP архива, то сначала проверяет правильную строку тождества ZIP архива. Если эта строка не найдена, то полагает, что ZIP архив будет поддельным и отравляет сообщение, тогда предупреждение вставлено в сообщение. Если Вы устанавливаете ZIP_MAGIC_WARNING в обрамленную кавычками многострочную строку, это заменит заданный по умолчанию текст:

SECURITY WARNING!

The mail system has detected that the preceding attachment claims to be a ZIP archive, but it does not have a valid ZIP archive signature. Do not trust it. Contact your system administrator immediately.

ПРЕДУПРЕЖДЕНИЕ БЕЗОПАСНОСТИ!

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

Пример:

ZIP_MAGIC_WARNING="
Foiled an attempt to bypass security via a bogus ZIP file."

 

BAD_BASE64_WARNING: Измените внедренный текст предупреждения для враждебного base64 кодирования ZIP архива. (1.144+)

Когда Sanitizer пытается просматривать вложенный ZIP архив то сначала декодирует base64 кодирование двоичного файла. Если base64 кодирование недопустимо когда читается построчно (то есть присутствуют строки короче 3 символов), сообщение отравлено, и предупреждение вставлено в сообщение. Вложение, закодированное законным почтовым клиентом не будет иметь таких очень коротких строк. Если Вы устанавливаете BAD_BASE64_WARNING в цитируемую многострочную строку, это заменит заданный по умолчанию текст:

SECURITY WARNING!

The mail system has detected that the preceding attachment was encoded in a manner intended to bypass security filtering. Do not trust it. Contact your system administrator immediately.

ПРЕДУПРЕЖДЕНИЕ ЗАЩИТЫ!

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

Пример:

BAD_BASE64_WARNING="
Trapped hostile BASE64 encoding on a ZIP file attachment."

 

DISABLE_JPEG_SCAN: Отключить сканирование вложений JPEG изображений.

Если вы не желаете, чтобы сканирование JPEG изображений имело место, установите DISABLE_JPEG_SCAN в любое значение.

Пример:

DISABLE_JPEG_SCAN=YES

Если вы желаете сканировать вложения JPEG изображений, вы будете должны установить три дополнительных инструментальных средства

Все эти инструменты поставляются с большинством дистрибутивов Linux. Для других операционных систем, вам необходимо будет скачать источники и компилировать их самостоятельно.

 

BAD_JPEG_WARNING: Изменение внедренного текста для JPEG вложений с возможной атакой переполнение буфера Buffer Overflow. (1.147+)

Если Вы устанавливаете BAD_JPEG_WARNING в цитируемую многострочную строку, это заменит заданный по умолчанию текст:

SECURITY WARNING! The mail system has detected that the preceding attachment appears to be a JPEG image containing a Microsoft buffer overflow attack. Do not trust it. Contact your system administrator immediately.

ПРЕДУПРЕЖДЕНИЕ ЗАЩИТЫ! Почтовая система обнаружила, что предыдущее вложение, кажется, изображение JPEG, содержащее нападение переполнения буфера Microsoft. Не доверяйте этому. Свяжитесь с вашим системным администратором немедленно.

Пример:

BAD_JPEG_WARNING="
Trapped hostile or corrupt JPEG attachment."

 

MACRO_WARNING: Измените внедренный текст предупреждения для отравленных вложений Microsoft Office (1.141 +)

Когда Sanitizer отравляет вложение Microsoft Office для высоких значений макро счета, электронная почта вставляет предупреждающее сообщение. Если Вы устанавливаете MACRO_WARNING в цитируемую многострочную строку, это заменит заданный по умолчанию текст:

SECURITY WARNING!

The mail delivery system has detected that the preceding document attachment appears to contain hazardous macro code.
Macro Scanner score:

ПРЕДУПРЕЖДЕНИЕ ЗАЩИТЫ!

Система доставки почты обнаружила, что предыдущее вложение документа, кажется, содержит опасный макро код.

Макро счет Сканера:

Пример:

MACRO_WARNING="
Evil macros in that Office attachment! It scored: "

Обратите внимание, что макро счет будет добавлен в конец к сообщению, так что Вы должны закончить ваше сообщение соответствующим текстом.

 

USE_CPAN: Используйте CPAN Perl модули, а не внешние программы для того, чтобы просмотреть вложения. (1.141 +)

Sanitizer может использовать CPAN модули MIME::Base64 и File::MkTemp для замены внешних "mimencode" и "mktemp" программ. Установите USE_CPAN в любое значение если вы желаете это сделать. (Примечание: вам все еще необходима внешняя "unzip" программа для сканирования вложений ZIP архивов; использование CPAN модулей для ZIP файлов – будущая особенность).

См. the CPAN FAQ для большей информации, особенно о том как установить CPAN Perl modules.

Пример:

USE_CPAN=YES

 

PVT_CPAN: Определите частный (несистемный) CPAN библиотечный каталог. (1.141 +)

Если Вы не имеете административного управления компьютером, sanitizer продолжает выполняться (например Вы выполняете это на почтовом сервере вашего Internet-провайдера, где Вы имеете учетную запись оболочки), Вы вероятно не будете способны установить CPAN Perl модули в системных библиотечных каталогах, если они уже не доступны.

Если Вы не можете заставить системного администратора устанавить CPAN модули для Вас, Вы можете установить их в каталог под вашим управлением и поместить название каталога в PVT_CPAN. Каталог в PVT_CPAN будет добавляться к Perl библиотечному пути поиска файлов прежде, чем CPAN модули будут связаны.

Пример:

PVT_CPAN="$HOME/my_cpan"

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

DEBUG_VERBOSE=""

or

DEBUG_VERBOSE=

Вы должны также читать Procmail man страницы, чтобы видеть, какие переменные окружения непосредственно управляют поведением Procmail. Некоторые из этих переменных окружения также могут быть распознаны Sanitizer.

Осуществление множественной политики защиты

Вышеупомянутое procmailrc файл применяет ту же самую политику защиты ко всем сообщениям, которые проходят через систему. Это может быть не то что вы хотите сделать; например, Вы можете хотеть ослабить некоторые проверки для сообщений в пределах вашего домена, типа не коверкания документов Word, которые ваши пользователи отправляют по почте друг к другу.

Путь, которым вы можете это осуществить предусматривает различные параметры настройки переменных конфигурации основанных на сообщении, которое обрабатывается. Например, если бы Вы хотели подавить коверкание документов Word в пределах вашего домена, Вы добавили бы следующее где-нибудь перед INCLUDERC=html-trap.procmail, который выполняет sanitizer:

 

:0
* ^From:.*<[a-z0-9]+@mydomain.com>
* ^To:.*<[a-z0-9]+@mydomain.com>
{
     MANGLE_EXTENSIONS='html?|exe|com|cmd|bat|pif|sc[rt]|lnk|dll|ocx|dot|xl[wt]|p[po]t|rtf|vb[se]?|hta|p[lm]|sh[bs]|hlp|chm|eml|ws[cfh]|ad[ep]|jse?|md[abew]|ms[ip]|reg|asd|cil|pps|asx|wm[szd]|vcf|nws|\{[-0-9a-f]+\}'
}

 

Пожалуйста обратите внимание что "From:" заголовок в электронном письме чрезвычайно просто подделать. Если Вы желаете осуществить менее - ограничительную политику{полис} для внутренней электронной почты, Вы должны базировать ваше "исходное" правило на вашем местном-сетевом адресе IP, появляющемся в заголовке Received:. Например, если Вы используете 10.20.30.nn для вашей местной сети, Вы могли бы сделать что-то подобное:

 

:0
* ^Received:[^(]+\([^ ]+ +\[10\.20\.30\.[0-9]+\]
* ^To:.*<[a-z0-9]+@mydomain.com>
{
    MANGLE_EXTENSIONS='html?|exe|com|cmd|bat|pif|sc[rt]|lnk|dll|ocx|dot|xl[wt]|p[po]t|rtf|vb[se]?|hta|p[lm]|sh[bs]|hlp|chm|eml|ws[cfh]|ad[ep]|jse?|md[abew]|ms[ip]|reg|asd|cil|pps|asx|wm[szd]|vcf|nws|\{[-0-9a-f]+\}'
    SECURITY_TRUST_HTML=Y
    etc...
}

 

Точный формат вашего местного: заголовка Received изменится в зависимости от того, каково программное обеспечение вашего локального MTA. Пожалуйста смотрите на заголовки реальных местных сообщений, чтобы определить то, что Вы должны искать.

Если вы хотите обеспечить средство для администратора, чтобы обойти sanitization полностью, например, облегчить возможность возвращать сообщения из карантина и поставлять их предназначенному получателю, Вы могли бы заменить просто INCLUDERC=html-trap.procmail:

 

:0
* ! ^From:.*<root@mydomain\.com>
* ! ^X-Security: bypass sanitizer 954kJF64ljf8o6r
{
    INCLUDERC=/etc/procmail/html-trap.procmail
}

 

Используя различные строки ненужных данных для вашего "обхода sanitizer" заголовка так, чтобы кто - то, кто читает эту страницу, не знал, как обойти ваш sanitizer. Если Вы хотите чтобы люди вне вашего поля эксплуатации были способны обойти sanitizer, опустите проверку заголовка From:

Применение заказных фильтров защиты

Возможно использовать карантин и средства уведомления обеспеченные sanitizer в соответствии с определенными для вашего собственного сайта политикой защиты правилами procmail. Ключи уведомлений Sanitizer и карантийные ответы от X-Content-Security заголовков, которые вставлены в сообщение. Вы можете сделать это в пределах ваших собственных правил procmail чтобы заставить sanitizer изолировать и/или уведомлять.

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

Например, один вариант текущего саморазмножающегося вируса отсылает себя как беспорядочно-названное вложение к сообщению без темы вообще. Чтобы создавать заказное правило для sanitizer, чтобы обнаружить и заманивать в ловушку это нападение, просто не отравляя все .EXE вложения, вы сделали бы это:

1. Поместите следующее в /etc/procmail/local-rules.procmail (owner root, group root, mode 644)

# Detect Hybris when sent as an anonymous message.
#
:0
* > 20000
* < 40000
* !^From:
* !^Subject:
* ^Content-Type:.*multipart/mixed;
{
        :0 B hfi
        * ^Content-Disposition:.*\.EXE
        * ^Content-Type:.*\.EXE
        * ^TVqQAAMAAAAEAAAA
        * ^SiXLG3Lv\+wdKT1hwcrOTfD7rduGAY5LvseJ7
        * ^D4TKBAAAUFVQ/1QkSAEs
        | formail -A "X-Content-Security: [$HOST] NOTIFY" \
                  -A "X-Content-Security: [$HOST] QUARANTINE" \
                  -A "X-Content-Security: [$HOST] REPORT: Trapped anonymous Hybris worm" 
}

 

2. Измените ваш /etc/procmailrc файл от:

INCLUDERC=/etc/procmail/html-trap.procmail

в: 

INCLUDERC=/etc/procmail/local-rules.procmail
INCLUDERC=/etc/procmail/html-trap.procmail

 

Если анонимный червь обнаружен, заголовки X-Content-Security вставлены в сообщение, используя formail. sanitizer тогда вызывают обычно; это обрабатывает сообщение, и даже если ничего иного неправильного с сообщением нет, оно будет изолировано из-за X-Content-Security заголовков, которые заказное правило вставило.

Примечание: Вышеупомянутый пример очень специфичен и поскольку червь Hybris может быть изменен автором для распространения, вероятно на пример нельзя положиться в фактической инсталляции.

Действия пользовательских правил, которые могут быть определены через X-Content-Security заголовки:

Ключевое слово

Действие

NOTIFY

Отправка уведомительного сообщения списку $NOTIFY и (если правильно) отправителю.

NONOTIFY

Отправка уведомительного сообщения отправителю если правильно, но не посылать уведомление списку $NOTIFY.

SPOOFED_SENDER

Запрещать уведомление отправителя потому что адрес отправителя, как известно будет подделан. Обратите внимание, что определение NONOTIFY и SPOOFED_SENDER вместе не пошлет ничего; вместо этого, не вставляйте никакой опции уведомления.

REPORT: xxxxx

Добавить текст к строке REPORT в уведомительных сообщениях. Множественные строки REPORT разрешены.

QUARANTINE

Отравленное сообщение. Сообщение может быть изолировано, если карантин сконфигурирован.

DISCARD

Отказаться от сообщения.

 

Вы можете поместить любое число заказных правил защиты сайта в /etc/procmail/local-rules.procmail - например, чтобы захватывать все анонимные .EXE вложения, добавьте: 

 
# Messages with .EXE attachments must have a subject line
#
:0
* > 20000
* !^Subject:
* ^Content-Type:.*multipart/mixed;
{
        :0 B hfi
        * ^Content-Disposition:.*\.EXE
        * ^Content-Type:.*\.EXE
        | formail -A "X-Content-Security: [$HOST] NOTIFY" \
                  -A "X-Content-Security: [$HOST] QUARANTINE" \
                  -A "X-Content-Security: [$HOST] REPORT: Trapped anonymous .EXE" 
}

 

Это намного более безопасно чем попытка искать определенную выполнимую программу, как в примере Анонимного Hybris.

Для захвата червя SirCam основываясь на фрагменте кода вы можете добавить:

 

# Trap SirCam (signature as of 08/01/2001)
#
:0
* > 130000
* ^Content-Type:.*multipart/mixed;
{
        :0 B hfi
        * ^Content-Disposition: attachment;
        * ^Content-Transfer-Encoding: base64
        * AAAAGgU0NhbTMyABCDTUlN|AAAAAaBTQ2FtMzIAEINNSU1F|ABkAAAABoFNDYW0zMgAQg01J
        | formail -A "X-Content-Security: [$HOST] NOTIFY" \
                  -A "X-Content-Security: [$HOST] QUARANTINE" \
                  -A "X-Content-Security: [$HOST] REPORT: Trapped SirCam worm - see http://www.symantec.com/avcenter/venc/data/w32.sircam.worm@mm.html"
}

 

Вот детектор для BadTrans:

 

# Trap BadTrans (signature as of 12/03/2001)
#
:0
* > 40000
* < 50000
* ^Subject: Re:
* 1^1 ^Content-Type:.*multipart/.*boundary="====_ABC1234567890DEF_===="
* 1^1 ^Content-Type:.*multipart/.*multipart/
{
        :0 B hfi
        * ^Content-Type: audio/x-wav;
        * ^Content-ID: 
        * ^Content-Transfer-Encoding: base64
        | formail -A "X-Content-Security: [$HOST] NOTIFY" \
                  -A "X-Content-Security: [$HOST] QUARANTINE" \
                  -A "X-Content-Security: [$HOST] REPORT: Trapped BadTrans worm - see http://securityresponse.symantec.com/avcenter/venc/data/w32.badtrans.b@mm.html"
}

 

Вот детектор для некоторых вариантов Klez:

 

# Trap Klez (signature as of 04/26/2002)
#
:0
* > 100000
* ^Content-Type:.*multipart/alternative;
{
        :0 B hfi
        * \<i?frame +src=(3D)?cid:.* height=(3D)?[0-9] +width=(3D)?[0-9]>
        * ^Content-Type:.*audio/
        * ^Content-ID:.*<
        * ^Content-Transfer-Encoding: base64
        * ^TVqQAAMAAAAEAAAA
        | formail -A "X-Content-Security: [$HOST] NOTIFY" \
                  -A "X-Content-Security: [$HOST] QUARANTINE" \
                  -A "X-Content-Security: [$HOST] REPORT: Trapped possible Klez worm - see http://securityresponse.symantec.com/avcenter/venc/data/w32.klez.removal.tool.html"
}

 

Если вы не желаете сохранять карантийные копии сообщений захваченных этим способом, измените действие от QUARANTINE в DISCARD. Если вы не хотите быть уведомленным, но все еще хотите, чтобы отправитель сообщения был уведомлен, измените обработку от NOTIFY в NONOTIFY. Например:

 

| formail -A "X-Content-Security: [$HOST] NONOTIFY" \
          -A "X-Content-Security: [$HOST] DISCARD" \

 

Это сохранит ваш карантин и почтовые ящики постмастера от заполнения сотнями предупреждений об известном нападении червя. (Вы должны использовать версию 1.132 или выше чтобы сделать это).

 

Если Вы не хотите изолировать, не хотите быть уведомленным, и не хотите уведомить отправителя, то просто откажитесь от сообщения, посылая его к /dev/null:

 

:0 B
* whatever signature rules here
/dev/null

 

 

Это отвергнет сообщение. Вы не будете уведомлены, копия не будет сохраняться.