Антивирус на шлюзе плюс блокировка вложений: часть угроз не доходит до ящика

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

Sasser, конечно, шёл не через почту - он ходил по сети сам. Но именно он подтолкнул к разговору: если машина заражается без участия пользователя через сеть, то что говорить про почту, где пользователь сам открывает вложение? Это же ещё проще. Разговор с несколькими клиентами получился продуктивным: люди после пятничных ребутов были в правильном настроении слушать.

Два уровня, не один

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

Антивирус на шлюзе проверяет вложения по базе сигнатур. Ловит известные угрозы, умеет разбирать архивы, проверяет и входящую, и исходящую почту. Минус - в первые часы новой волны база ещё не знает свежего червя. MyDoom в январе именно это и показал: несколько часов, пока вендоры не выпустили обновление, антивирус его не видел.

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

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

Список расширений под блок

Мы обкатали этот список за последние два года и пришли к такому варианту. Здесь нет ничего экзотического - только то, что регулярно приносит неприятности:

• .exe - исполняемые файлы Windows, самое очевидное
• .com - старый формат исполняемых, но живой
• .pif - ярлык программы, запускает исполняемый код
• .scr - скринсейверы, по сути тоже exe
• .bat, .cmd - скрипты командной строки
• .vbs, .vbe - VBScript, любимый инструмент макровирусов с 2000 года
• .js, .jse - JavaScript-скрипты, запускаются через Windows Script Host
• .wsf, .wsh - файлы Windows Scripting Host
• .hta - HTML-приложения, работают с полными правами
• .cpl - апплеты панели управления
• .reg - файлы реестра, могут менять систему без предупреждения

Архивы отдельная история. .zip и .rar блокировать огульно нельзя - слишком много легитимного трафика идёт в архивах. Но архивы проверяются антивирусом с распаковкой: если внутри .exe - блокируется. Архивы с паролем антивирус не вскрывает - это известное ограничение, и здесь нет хорошего ответа кроме организационного: объяснять пользователям, что зашифрованный архив от незнакомого отправителя - это не подарок.

Как это выглядит в конфиге

Работаем преимущественно с Postfix на Linux в связке с amavisd-new, который и антивирус вызывает (ClamAV или коммерческий, в зависимости от клиента), и блокировку по расширению держит. В amavisd-new блок расширений прописывается в @bad_filename_re - список регулярных выражений, по которым любое совпадение в имени вложения отправляет письмо в блок.

Выглядит примерно так:

@bad_filename_re = new_RE(
  qr'\.[^.]*\.(exe|com|pif|scr|bat|cmd|vbs|vbe|js|jse|wsf|wsh|hta|cpl|reg)\z'i,
  qr'\.exe\z'i,
  qr'\.pif\z'i,
  qr'\.scr\z'i,
  # ... и так далее
);

Двойные расширения - отдельный паттерн. Это классика: document.pdf.exe или photo.jpg.pif. Первая регулярка выше как раз ловит конструкцию «что угодно, точка, известное опасное расширение в конце».

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

Что это даёт на практике

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

Пользователи поначалу удивляются: «а почему мне не пришло вложение?» Объяснение простое: если кому-то надо прислать вам исполняемый файл - пусть положит на FTP или отправит другим способом. Рабочих причин слать .exe по почте практически нет. Те, что есть - решаются иначе.

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