Мейл-бомбінг є одним з найбільш старих різновидів кібер-атак. За своєю суттю вона нагадує звичайну DoS-атаку, тільки замість хвилі запитів з різних IP-адрес, на сервер відправляється вал електронних листів, які у величезних кількостях приходять на одну з поштових адрес, за рахунок чого навантаження на нього значно зростає. Така атака може призвести до неможливості використання поштової скриньки, а іноді навіть може призвести до відмови всього сервера. Багаторічна історія такого виду кібератак призвела до низки позитивних та негативних для системних адміністраторів наслідків. До позитивних факторів можна віднести хорошу вивченість мейл-бомбінгу та наявність простих способів захиститися від такої атаки. До негативних факторів можна віднести велику кількість загальнодоступних програмних рішень для проведення таких видів атак і можливість для зловмисника надійно захиститися від виявлення.
Важливою особливістю цієї кібератаки є те, що її практично неможливо використовувати для отримання прибутку. Ну направив зловмисник на одну з поштових скриньок вал електронних листів, ну не дав людині нормально використовувати електронну пошту, ну зламав зловмисник чиюсь корпоративну пошту і почав масово розсилати по всьому GAL тисячі листів, через що сервер або кинувся, або почав гальмувати так що користуватися ним стало неможливо, і що далі? Конвертувати подібний кіберзлочин у живі гроші майже неможливо, тому просто мейл-бомбінг на даний час є досить рідкісним явищем, і системні адміністратори під час проектування інфраструктури можуть просто не згадати про необхідність захисту від такої кібератаки.
Тим не менш, незважаючи на те, що сам по собі мейл-бомбінг є досить безглуздим з комерційної точки зору заняттям, він часто є складовою інших, складніших і багатоступеневих кібератак. Наприклад, при зламі пошти та використанні її для викрадення акаунту в якомусь публічному сервісі, зловмисники часто «бомблять» поштову скриньку жертви листами, які не мають сенсу, щоб лист з підтвердженням загубився в їхньому потоці і залишився непоміченим. Також мейл-бомбінг може використовуватися як економічний тиск на підприємство. Так, активне бомбардування публічної поштової скриньки підприємства, на яку надходять заявки від клієнтів, може серйозно утруднити роботу з ними і, як наслідок, може призвести до простою обладнання, невиконаних замовлень, а також втрати репутації та втраченої вигоди.
Саме тому системному адміністратору не варто забувати про можливість проведення мейл-бомбінгу і завжди вживати необхідних заходів для захисту від цієї загрози. Якщо зважити на те, що це можна зробити ще на етапі побудови поштової інфраструктури, а також те, що це забирає у системного адміністратора зовсім небагато часу та праці, об'єктивних причин для того, щоб не забезпечити свою інфраструктуру захистом від мейл-бомбінгу, просто не залишається . Давайте подивимося на те, як реалізований захист від даної кібератаки в Zimbra Collaboration Suite Open-Source Edition.
В основі Zimbra лежить Postfix - один з найнадійніших і функціональних Mail Transfer Agent з відкритим вихідним кодом на даний момент. І однією з головних переваг його відкритості є те, що він підтримує найрізноманітніші сторонні рішення для розширення функціональності. Зокрема, Postfix повноцінно підтримує cbpolicyd - просунуту утиліту для забезпечення кібербезпеки поштового сервера. Крім захисту від спаму та створення білих, чорних та сірих списків, cbpolicyd дозволяє адміністратору Zimbra налаштувати перевірку SPF-підпису, а також встановити обмеження на прийом та надсилання електронних листів або даних. Вони можуть забезпечити надійний захист від спаму і фішингових листів, так і захистити сервер від мейл-бомбінгу.
Перше, що потрібно від системного адміністратора - це активація модуля cbpolicyd, який встановлено в Zimbra Collaboration Suite OSE на MTA-сервері інфраструктури. Робиться це за допомогою команди zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Після цього необхідно буде активувати веб-інтерфейс, щоб мати можливість комфортно керувати cbpolicyd. Для цього необхідно дозволити з'єднання на веб-порті номер 7780, створити символьне посилання за допомогою команди ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, а потім відредагувати файл із налаштуваннями за допомогою команди nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, де необхідно прописати наступні рядки:
$DB_DSN=«sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb»;
$DB_USER="root";
$DB_TABLE_PREFIX=»»;
Після цього залишиться лише перезапустити сервіси Zimbra та Zimbra Apache за допомогою команд zmcontrol restart та zmapachectl restart. Після цього вам відкриється доступ до веб-інтерфейсу за адресою :7780/webui/index.php. Головним нюансом є те, що вхід до цього веб-інтерфейсу поки що ніяк не захищений і для того, щоб виключити попадання в нього сторонніх осіб, можна після кожного входу до веб-інтерфейсу просто закривати підключення на порті 7780.
Захиститися від потоку листів, що виходить із внутрішньої мережі, дозволяють квоти на відправку електронних листів, які можна встановити завдяки cbpolicyd. Такі квоти дозволяють встановити обмеження на максимальну кількість листів, які можуть бути надіслані з однієї поштової скриньки в одну одиницю часу. Наприклад, якщо менеджери вашого підприємства в середньому відправляють по 60-80 електронних листів на годину, можна з урахуванням невеликого запасу встановити їм квоту в 100 електронних листів на годину. Для того, щоб вичерпати таку квоту, менеджерам доведеться надсилати по одному листу раз на 36 секунд. З одного боку, цього достатньо для того, щоб повноцінно працювати, а з іншого боку, з такою квотою зловмисники, які отримали доступ до пошти одного з ваших менеджерів, не влаштують мейл-бомбінг або масову спам-атаку на підприємстві.
Для того, щоб встановити подібну квоту, необхідно у веб-інтерфейсі створити нову політику обмеження надсилання листів і вказати, щоб вона діяла як на листи, надіслані всередині домену, так і на листи, що діють на зовнішні адреси. Робиться це так:
Після цього можна буде детальніше вказати обмеження, пов'язані з відправкою листів, зокрема задати часовий інтервал, після якого обмеження будуть оновлюватися, а також повідомлення, яке отримуватиме користувач, який перевищив свій ліміт. Після цього можна встановити саме обмеження на відправку листів. Його можна задати як у вигляді кількості вихідних листів, так і у вигляді кількості байтів інформації, що передається. При цьому з листами, які надсилаються понад зазначений ліміт, надходити по-різному. Так, наприклад, можна їх просто відразу видаляти, а можна зберігати, щоб вони вирушили відразу після оновлення ліміту на відправку повідомлень. Друга опція може скористатися під час виявлення оптимального значення межі на відправку електронних листів співробітниками.
Крім обмежень на надсилання листів, cbpolicyd дозволяє налаштувати ліміт на отримання листів. Таке обмеження, на перший погляд, є відмінним рішенням для захисту від мейл-бомбінгу, проте за фактом встановлення такого ліміту, нехай навіть великого, загрожує тим, що в певних умовах до вас може не дійти важливий лист. Саме тому включати будь-які обмеження для вхідної пошти не рекомендується. Однак якщо ви все ж таки вирішили ризикнути, підходити до налаштування ліміту вхідних повідомлень потрібно підходити з особливою увагою. Наприклад, можна обмежити кількість вхідних листів від довірених контрагентів, щоб у випадку, якщо їхній поштовий сервер був скомпрометований, з нього не проводилася спам-атака на ваше підприємство.
Для того, щоб захиститися від валу вхідних повідомлень при мейл-бомбінгу, системному адміністратору слід зробити щось розумніше, ніж просте обмеження вхідної пошти. Таким рішенням може стати використання сірих списків. Принцип їх дії полягає в тому, що при першій спробі доставити повідомлення від ненадійного відправника з'єднання з сервером різко переривається, через що доставка листа закінчується невдачею. Однак, якщо в певний період ненадійний сервер знову робить спробу надіслати той же лист, сервер не обриває з'єднання і його доставка проходить успішно.
Сенс усіх цих дій у тому, що програми для автоматичного масового розсилання електронних листів зазвичай не перевіряють успішність доставки відправленого повідомлення і не роблять спроби відправити його вдруге, тоді як людина напевно впевниться, був відправлений його лист за адресою, чи ні.
Увімкнути сірі списки можна також у веб-інтерфейсі cbpolicyd. Для того, щоб все працювало, необхідно створити політику, в яку потрапляли б усі вхідні листи, адресовані користувачам на нашому сервері, а потім на основі цієї політики створити правило Greylisting, де можна налаштувати інтервал, під час якого cbpolicyd чекатиме повторної відповіді від незнайомої відправника. Зазвичай він становить 4-5 хвилин. При цьому сірі списки можна налаштувати так, щоб усі успішні та неуспішні спроби доставити листи від різних відправників враховувалися і на підставі їхньої кількості приймалося рішення про автоматичне додавання відправника до білого або чорного списків.
Звертаємо вашу увагу на те, що до використання сірих списків варто бути схожими з максимальною відповідальністю. Найкраще буде, якщо використання цієї технології йтиме рука об руку з постійним веденням білих і чорних списків, щоб виключити можливість втрати дійсно важливих для підприємства листів.
Крім того, захиститися від мейл-бомбінгу може допомогти додавання перевірок SPF, DMARC та DKIM. Найчастіше листи, які надходять у процесі мейл-бомбінгу, такі перевірки не проходять. Про те, як це зробити, розповідалося .
Таким чином, захиститися від такої загрози як мейл-бомбінг досить просто, і зробити це можна ще на етапі будівництва інфраструктури Zimbra для вашого підприємства. Однак важливо постійно стежити за тим, щоб ризики від використання такого захисту ніколи не перевищували переваги, які ви отримуєте.
Джерело: habr.com