Detection mailing viruses in corporate network

Чтобы перенастроить Postfix, отредактируйте в файле /etc/postfix/master.cf все строки, начинающиеся с smtp inet, заменив smtp на номер порта, например, на 325. Желательно, чтобы новый номер...

Заставьте Postfix перечитать настройки (service postfix reload) и проверьте, что они вступили в силу: netstat -ntl и netcat localhost 325.

При этом возникает проблема внешних соединений. Дело в том, что по протоколу SMTP почта на наш сервер поступает не только от клиентов, но и от других серверов из внешней сети, причём возможности заставить эти серверы пользоваться нестандартным портом не существует. Данная проблема решается простым перенаправлением IP-порта. С этой целью могут быть использованы разные программы, в том числе и стандартный супердемон xinetd. В каталоге /etc/xinetd.d на SMTP-сервере должен быть размещён файл smtp-forward с содержимым, составленным по следующему образцу:

После этого: service xinetd reload. Проверка: netstat -ntl и netcat 1.2.3.4 25, где 1.2.3.4 - внешний IP-адрес сервера.

Не менее просто делается редиректор с помощью пакетного фильтра iptables, работающего с Linux kernel 2.4+:

Любопытная особенность данного редиректора состоит в том, что пакеты подвергаются перенаправлению на основании одного только номера порта, вне зависимости от указанного в них IP-адреса цели. Это позволяет задавать в настройках клиента в качестве адреса SMTP-сервера абсолютно любое внешнее имя, например, www.gov.no. Однако по причинам, изложенным в следующем разделе, рекомендуется указывать здесь имя самого компьютера-редиректора/smtp-ловушки.

Если персонал организации имеет почтовые ящики на ограниченном множестве внешних серверов, можно обойтись простым редиректором для каждого из них. Для этого на Линукс-маршрутизаторе, имеющем выход во внешнюю сеть, потребуется создать в каталоге /etc/xinetd.d множество файлов следующего вида:

Примечание: не используйте в именах файлов точку - такие файлы xinetd игнорирует!

Для этого раздела в силу его малой актуальности решение не составлялось. По всей видимости, данная задача может быть решена только с использованием прокси-сервера SOCKS и клиентской утилиты SocksCapture. Поскольку на текущий момент у меня нет опыта их использования, в качестве отправной точки для собственных изысканий всем заинтересованным читателям предлагается статья Андрея Черезова в «КомпьюТерре», из которой и почерпнуты все мои нынешние познания о SOCKS.

Принимать запросы на отправку почты через 25-й порт из локальной сети под видом SMTP-сервера будет xinetd:

Чтобы у инициатора соединения не возникало сомнений, что ему отвечает именно SMTP-сервер, xinetd будет немедленно посылать приглашение, взятое из файла /var/local/smtptrap.banner, как это всегда делает отвечающая сторона в SMTP. Приглашение может содержать сравнительно произвольный текст:

Например, соединитесь netcat'ом с настоящим сервером SMTP и возьмите за образец приглашение, которое он выведет.

К сожалению, утилиту, отвечающую за составление и отправку оповещений, придётся запускать независимо. Дело в том, что создаваемое ею оповещение должно содержать IP-адрес, с которого было установлено соединение с ловушкой, а этот адрес xinetd умеет сообщать одним-единственным образом -- записывая его в log-файл или в syslog. В частности, в ALTLinux'е syslog настроен таким образом, что требуемые нам сообщения от xinetd попадают в файл /var/log/auth/secure.

Хотя приведённый ниже сценарий создавался скорее в демонстрационных целях, нежели для практического применения, в нём есть почти всё, что требуется полноценной программе такого рода:

Вместе с тем, не реализованы следующие моменты:

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

#!/bin/bash
#
#  /usr/bin/trap-watch
#
#  Purpose: watches system logs for network connections
#           at specific xinetd-driven port,
#           then notifies sysadmin about this event by email.
#
#  Requires: screen, perl, sudo, grep, mail, id
#
#  May be executed by root or any sudoer in interactive mode ($0 watch)
#  or background mode ($0 start/stop/status/restart/condrestart/attach)
#
#  Written by Evseev/EBCEEB at Apr 2004   http://ilya-evseev.narod.ru
#  Distributed under terms of GNU GPL     http://www.gnu.org/license
#

MYNAME=`basename $0`
SERVICE=smtp
TITLE=${SERVICE}trap.watch
WATCH_FILE=/var/log/auth/secure
WATCH_USER=nobody
ADMIN_EMAIL=root
SUDO=/usr/bin/sudo

function report_error() {
    echo "Error: $*!" 1>&2
    return 1
}

function usage() {
    [ $# = 0 ] || report_error $*
    echo "Usage: $MYNAME watch|start|stop|status|restart|condrestart|attach|help"
}

function watch()
{
    local SUDO_TAIL SUDO_PERL PERL_TMP=${TMPDIR:-/tmp}
    case `id -u` in
	0 ) # We are root.
	    # So execute perl/mail under nobody account for security reason
	    SUDO_PERL="$SUDO -H -u $WATCH_USER" 
	    PERL_TMP=/tmp
	    # nobody cannot write to it's own homedir..
	    #eval PERL_TMP=~$WATCH_USER
	    ;;
	[0-9]* )
	    # We are ordinal user.
	    # So execute tail under root account (only root can read logs)
	    SUDO_TAIL="$SUDO" ;;
	* ) report_error "cannot detect your UID"; return 1 ;;
    esac

    $SUDO_TAIL tail -n0 -f $WATCH_FILE | \
    TMPDIR=$PERL_TMP $SUDO_PERL perl -n \
      -e "\$service=$SERVICE; \$email=$ADMIN_EMAIL;" \
      -e 'if (/^(\w+ \d+ [\w:]+) \w+ xinetd\[[0-9]*\]: START: $service from=([0-9.]*)$/ ) {
	    $when = "$1";
	    $addr = "$2";
            $subj = "$service trap from $addr";
	    $body = "$when -- $subj";
            print "$body\n";
            system "echo $body | mail -s \"$subj\" $email";
	  }'
}

function check_status() {
    screen -list | grep -q $TITLE && return 0 || return 1
}

function status() {
    check_status && echo "$TITLE loaded." && return 0
    echo "$TITLE not loaded."
    return 1
}

function start() {
    if check_status; then
	report_error "$TITLE is already loaded";
	return 1;
    fi
    screen -S $TITLE -d -m $0 watch
    echo "$TITLE started."
}

function stop() {
    if screen -r $TITLE -X quit;
	then echo "$TITLE stopped."
	else report_error "cannot stop $TITLE, maybe not started?"
    fi
}

function main()
{
    case "$1" in
	-s | start)   start ;;
	-d | stop)    stop ;;
	-q | status)  status ;;
	-r | restart) stop; start ;;
	-c | condrestart ) check_status && restart ;;
	-a | attach)  screen -r $TITLE ;;
        -i | watch)   watch ;;
	-h | --help | help | -H ) usage ;;
	* ) usage "unrecognized command line: $*" ;;
    esac
}

main "$@"

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

Пакетный фильтр может решать эту задачу одним из трёх способов:

Перед вводом дополнительных правил пакетный фильтр должен быть минимально настроен, например:

Список адресов, по которым должна производиться рассылка, может быть составлен вирусом из самых разных источников:

Поэтому имеет смысл поместить в локальную адресную книгу фальшивую контактную запись. Фальшивая запись должна:

Благодаря этим свойствам:

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

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

Во-первых, для работы с почтовой системой Microsoft предоставляет множество перекрывающихся API: MAPI, Simple MAPI, Exchange Client API и т.д. В соответствии с традициями Microsoft все они неряшливо спланированы, громоздко реализованы и намеренно невнятно документированы в той части, которая касается общего понимания. Таким образом, основная часть времени уходит на то, чтобы убедиться, что очередной API нужной функциональности не содержит.

Поиски приводят нас к WAB, Windows Address Book или адресной книге Windows. Хотя в большинстве случаев она вызывается из Outlook Express, WAB является самостоятельным приложением и имеет собственный программный интерфейс. Его применение Microsoft демонстрирует утилитой WabTool, которая доступна в виде исходных текстов. К сожалению, WabTool является GUI-приложением, то есть не может использоваться в не-интерактивном, пакетном режиме, и годится только в качестве заготовки. Принципиальное нежелание в очередной раз разгребать сочинённый Microsoft мусор помешало автору статьи написать на её базе требуемую утилиту.

Настройки для сервера Posfix должны быть дополнены следующим образом:

Сценарий posttrap - обработчик заражённых писем - может выглядеть так: