Соціальна інженерія - це термін, який стає все більш актуальним у сучасному цифровому суспільстві. Цей СЕО-текст зосереджений на тому, що таке соціальна інженерія, які основні методи її використання, та як можна захиститися від цієї загрози.
747 
Ефективне керування електронною поштою є важливим аспектом продуктивності та організації робочого процесу. Інструменти керування електронною поштою допомагають вам ефективно керувати вхідними та вихідними повідомленнями, організовувати ваші поштові скриньки та забезпечувати ефективну комунікацію. За допомогою цих інструментів ви зможете швидко переглядати, сортувати та відповідати на повідомлення, встановлювати фільтри для автоматичного сортування вхідних повідомлень, планувати та нагадувати собі про завдання, а також швидко знаходити потрібні повідомлення за допомогою функції пошуку.
Ви також зможете налаштувати різні поштові скриньки для відокремлення робочої та особистої пошти, що допоможе вам зберігати порядок і легше знаходити необхідні повідомлення. Інструменти керування електронною поштою покращують вашу продуктивність, допомагають уникати загублення важливої інформації, забезпечують ефективну організацію та сприяють кращій комунікації з колегами та клієнтами. Незалежно від обсягу вашої електронної пошти, інструменти керування електронною поштою допоможуть вам бути більш організованими та продуктивними у вашій щоденній роботі. Досі ми проводили атаки фішингу і вчили користувачів їх помічати. Ми також поговорили про те, як реагувати, коли люди стають жертвами соціальної інженерії, незважаючи на наше навчання. У цьому розділі розглядається реалізація технічних засобів управління електронною поштою, які поможуть забезпечити інформаційну безпеку організації та зняти частину цього тягаря з користувача. Крім того, ми обговоримо поштові програми та служби, здатні фільтрувати електронну пошту та керувати нею. Але перш ніж перейти до них, погляньмо на чинні стандарти, пов’язані з технічною стороною управління електронною поштою.
Електронна пошта розвивалася разом із технологіями її захисту. У міру розвитку цих технологій розвивалися і схеми атак, перетворюючись, як і все інше в області інформаційної безпеки, в безперервну битву щита і меча. З часом експерти з безпеки запропонували, обговорили і затвердили багато стандартів. Коли справа доходить до безпеки електронної пошти, варто згадати три основні стандарти: Ключі домену ідентифікована пошта, DKIM), структура політики відправників (SPF) і автентифікація, звітування та відповідність повідомлень на основі домену (DMARC). Про кожну з них ми і поговоримо в цьому розділі.
Що роблять ці три стандарти? Поширеною помилкою є те, що вони захищають ваші електронні листи від вхідних спроб фішингу або спуфінгу. В якійсь мірі вони це роблять, але точніше описати їх як захист вашої репутації: якщо ви надсилаєте електронний лист відповідно до цих стандартів, а домени одержувачів налаштовані на перевірку пов’язаних записів, вони можуть виявити спроби спуфінгу вашого домену. Хоча це може здатися нелогічним і Марно з точки зору соціальної інженерії, прочитайте решту цієї глави, щоб побачити, як вона може вам допомогти.
Коротше кажучи, SPF перевіряє, що хост або IP-адреса є у списку відправника, DKIM надсилає цифровий підпис, а DMARC реалізує як SPF, так і DKIM на додаток до перевірки хостингу. DMARC також надає звіти та повідомлення. SPF вважається найпростішим зі стандартів безпеки. Важливим моментом є те, що поштові сервери одержувача необхідно налаштувати на перевірку відповідності повідомлення стандартам, зазначеним при відправці, і за результатами перевірки виконати певні дії.
Щоб зрозуміти, як працюють ці стандарти, потрібно розуміти різні типи полів, які вказують на відправника електронного листа. Окрім поля «Відповісти», повідомлення електронної пошти містять поля «Від» і «Пошта_від». У полі Від, яке також називається 5322.From, відображається відправник. Поле MailFrom або 5321. MailFrom – це фактична служба електронної пошти, яка надіслала електронний лист. Наприклад, якщо я надсилаю електронні листи за допомогою MailChimp, моя особиста адреса електронної пошти буде в полі 5322.From, а сервер і адреса MailChimp – у полі 5321.MailFrom.
Числа, прикріплені до цих полів, беруться з описів стандарту, в якому вони були визначені. Тепер давайте розглянемо ці три стандарти в хронологічному порядку, починаючи з DKIM.
DKIM став інтернет-стандартом у 2011 році. Він призначений для автентифікації електронних листів і запобігання спуфінгу, і вимагає від відправників криптографічного підпису частин електронного листа, включаючи поле 5322.From. Оскільки зловмисник, ймовірно, не матиме доступу до закритого ключа, який використовується для додавання цифрового підпису до поля, одержувачі електронної пошти можуть швидко виявляти спроби спуфінгу.
Заголовок DKIM – спеціальне поле, додане до повідомлення електронної пошти, вказує, де отримати відкритий ключ для перевірки підпису. Відкритий ключ зберігається в TXT-записі DNS з використанням тегів домену DNS (d=) і селектора (s=), які можна знайти в електронному листі. Відкритий ключ DKIM є єдиною частиною інфраструктури, яку може бачити широка громадськість, але його знаходження залежить від знань селектора, який вам відомий лише в тому випадку, якщо ви отримали електронний лист із справжнього домену (або вам вдалося його зламати).
Процес DKIM виглядає наступним чином. Спочатку ви створюєте електронний лист. Коли ви надсилаєте електронний лист, закритий ключ, пов’язаний із вашим записом DKIM, створює два цифрові підписи для перевірки автентичності електронного листа. Один підпис призначений для самого заголовка DKIM, а інший — для тіла електронного листа. Кожен електронний лист має унікальну пару підписів. Підписи ставляться в шапку і відправляються разом з листом. Після отримання (якщо DKIM налаштовано на поштовому сервері одержувача) сервер автентифікує повідомлення за допомогою відкритого ключа, опублікованого в записах DNS. Якщо ключ може успішно розшифрувати електронний лист, це означає, що електронний лист є автентичним і не був підроблений.
У той же час DKIM рідко використовується для аутентифікації. Замість цього ми в основному використовуємо його для автентифікації та для так званого хостингу DMARC, який обговорюється в розділі “Автентифікація, звітність та відповідність повідомлень на основі домену” далі в цьому розділі. Одним з недоліків DKIM є те, що він ефективний лише в тому випадку, якщо його реалізує як відправник, так і одержувач.
Крім того, навіть якщо ваша організація впроваджує DKIM внутрішньо, вона може захистити ваших користувачів лише від зовнішніх суб’єктів, які намагаються замінити інших внутрішніх співробітників, що добре для вашої репутації, але в іншому випадку мало що робить для забезпечення безпеки. Зрештою, зловмисники можуть підробити довірену третю сторону. Але, як згадувалося раніше, одержувач повинен налаштувати свої поштові сервери для перевірки автентифікації DKIM, що зазвичай досягається шляхом впровадження DMARC. У разі відсутності DMARC електронні листи з помилкою аутентифікації все одно передаються одержувачу.
DKIM вперше був представлений в RFC 6376. Пізніше RFC 8301 додав наступну специфікацію щодо типу шифрування, яке може використовувати DKIM:
В даний час дана специфікація визначає два алгоритми: rsa-sha1 і rsa-sha256. Підписанти ПОВИННІ використовувати rsa-sha256. Верифікатори ПОВИННІ мати можливість перевірити підпис за допомогою rsa-sha256. Шифрування rsa-sha1 НЕ ПОВИННО використовуватися для підписування або перевірки.
У 2018 році було видано ще один RFC щодо DKIM. RFC 8463 додає новий алгоритм підпису, ed25519, який використовує SHA-256 і алгоритм цифрового підпису Edwardscurve (EdDSA) замість ключа RSA.
Для ефективної роботи DKIM необхідно налаштувати його не тільки на DNS-сервері, але і на поштовому сервері. В іншому випадку вона буде діяти лише як стримуючий фактор. Розгляньмо, як налаштувати DKIM у домені, розміщеному через Google Workspace. Інші поштові сервери мають подібні функції.
Звичайний Gmail використовує ключі DKIM Google за умовчанням, як і домени, розміщені в Workspace, у яких не налаштовано DKIM. Ви не можете налаштувати власний DKIM для облікового запису Gmail, розміщеного в gmail.com, але це можна зробити для домену за допомогою Workspace. Згідно з інструкціями служби підтримки Google, якщо користувач не налаштовує власний відкритий ключ DKIM, Google використовуватиме такий ключ за умовчанням: d=*.gappssmtp.com.
Давайте налаштуємо власний закритий ключ. Спочатку увійдіть у консоль адміністратора робочої області як суперадміністратор. Увійшовши в консоль, натисніть Автентифікувати електронну пошту , як показано на рис. 11.1.
Тепер ви побачите опцію автентифікації DKIM, і вам буде запропоновано вибрати домен для налаштування підтримки DKIM (рис. 11.2).
Після натискання кнопки Create New Record потрібно вибрати довжину ключа та селектор (рисунок 11.3). Зверніть увагу, що деякі хостинг-провайдери та платформи DNS не підтримують довжину ключа 2048 біт. Відповідно до інструкцій Google, якщо це так, поверніться до 1024-бітних ключів за замовчуванням.
Тепер виберіть потрібний домен і натисніть кнопку Створити новий запис. Буде створено новий ключ (прихований на рисунку 11.4). Відкрийте нове вікно, щоб скопіювати та вставити ключ у DNS. Після цього натисніть кнопку Почати автентифікацію.
Після цього кроку увійдіть в cPanel, поширений інструмент управління доменами, який використовується багатьма хостинг-провайдерами. cPanel повинен мати редактор зони DNS з полем, що дозволяє вводити відкритий ключ в запис TXT (рисунок 11.5).
Зверніть увагу, що панелі керування записами DNS можуть обмежувати вас до 255 символів: занадто мало для рекомендованого галузевими стандартами 2048-бітного ключа. (Коли це сталося зі мною, я зв’язався зі службою підтримки клієнтів і попросив їх вручну ввести інформацію від мого імені, що вони неохоче зробили.)
Після збереження ключа може знадобитися до 48 годин, перш ніж запис пошириться на хости DNS. Вам потрібно буде натиснути кнопку Почати автентифікацію на панелі інструментів, щоб підтвердити її після завершення розповсюдження. Запис поширення іноді може зайняти до 72 годин, залежно від інфраструктури та постачальника.
Ось ще одне важливе міркування, яке обговорюється в наступному розділі: переконайтеся, що ваш хостинг і постачальник послуг DNS підтримують складені записи DNS, перш ніж використовувати будь-що, вище 1024-бітного ключа RSA. По суті, деякі інтернет-провайдери накладають обмеження на кількість символів, які можна ввести в один запис в DNS. Ваша реалізація DMARC зазнає помилки вирівнювання, якщо постачальник не підтримує конкатенацію (конкатенацію) записів, оскільки DNS інтерпретує її як два не пов’язані TXT-записи і не зможе виконати своє завдання.
Щоб настроїти DKIM в інших постачальниках послуг електронної пошти, таких як Exchange, Office 365 і Sendmail, можна знайти посилання на кілька посібників у http://email-security.seosint.xyz/.
Шифрування, яке використовується в DKIM, деякий час містило вразливості. До 2018 року DKIM дозволяв використовувати алгоритм SHA-1 для підписання і верифікації. Однак експерти з комп’ютерної безпеки знають, що SHA-1 стала небезпечною з 2010 року, ще до того, як був створений стандарт DKIM. Дослідники з CWI Amsterdam і Google з тих пір успішно провели так звану атаку зіткнення на протокол, після чого більшість фахівців з криптографії та безпеки відхилили його. Атака зіткнення дозволяє сторонам брати хеші двох невідповідних файлів і створювати з них однаковий хеш, створюючи враження, що вони збігаються. Всі великі постачальники веб-браузерів оголосили про припинення підтримки сертифікатів SHA-1 в 2017 році.
Насправді, створення зіткнення в потрібному місці під час операцій DKIM все ще вимагає великих обчислювальних потужностей, тому тільки великі і добре фінансовані організації, такі як національні розвідувальні агентства або великі технологічні компанії, мають технічну можливість здійснити таку атаку. Зрештою, Google була однією з двох організацій, яким вдалося інсценувати зіткнення SHA-1 (і навряд чи Google спробує відправити підроблені електронні листи вашій організації). Але якщо у вас є повноваження на це, використовуйте більш безпечний SHA-256.
По-друге, є уразливості в RSA, яка використовується як інфраструктура відкритих ключів DKIM. Як я вже згадував раніше, інструмент DKIM від Google підтримує два RSA: 1024-бітний і 2048-бітний. Другим варіантом RSA є поточний мінімальний галузевий стандарт. Тривають серйозні дебати про те, чи є RSA безпечним, враховуючи математичні, обчислювальні та криптографічні досягнення з моменту появи RSA. Кілька вчених і дослідників заявили, що вони можуть зламати RSA або послабити криптосистему RSA. Ослаблення криптосистеми – це метод зниження її сили шляхом виявлення великих використовуваних простих чисел і факторизації.
Використання 1024-бітних RSA, безумовно, є офіційно встановленою вразливістю, в той час як використання 2048-bit RSA не рекомендується, але і не забороняється. З практичної точки зору, без величезних обчислювальних ресурсів або доступу до квантових обчислювальних інструментів ні 1024-розрядні, ні 2048-розрядні RSA не можуть бути зламані менш ніж за два мільйони років в одній обчислювальній системі. Пізніші версії DKIM додали підтримку алгоритму Ed25519-SHA256, хоча він не був широко прийнятий.
Останнє слабке місце в DKIM – це не вразливість, а недолік. DKIM чудово реалізований і може захистити репутацію організації, але лише якщо сервер електронної пошти одержувача налаштовано на перевірку підпису DKIM та вжиття заходів щодо електронних листів, які нібито надсилаються з домену з підтримкою DKIM; Інакше репутація вашої організації все одно може бути зіпсована.
Як і DKIM, Sender Policy Framework (SPF) спрямована на запобігання спуфінгу з використанням записів DNS TXT. У цих записах SPF визначає домени, списки хостів, доменів і IP-адрес, а також IP-адреси, яким дозволено відправляти електронні листи з домену або від його імені.
Хоча деякі джерела описують SPF як аутентифікацію відправника, доцільніше називати це перевіркою даних; Якщо інфраструктуру настроєно, одержувач перевірить відомості про відправника з полів 5322 і 5321, щоб авторизувати відправників, як визначено в записі SPF.
Щоб зрозуміти, як це працює, уявіть, що хтось підробляє електронну пошту з домену. Одержувач перевіряє запис SPF і помічає, що для домену відправника встановлено «сувору перевірку», а відправника немає в списку надійних. При цьому у одержувача налаштована політика перевірки SPF. В цьому випадку лист не дійде до адресата. Якщо запису SPF не було, якщо в домені було встановлено параметр “м’яка перевірка”, або політика перевірки SPF була вимкнена, електронний лист було б доставлено призначеному одержувачу.
Оскільки SPF не вимагає криптографії, SPF і DKIM доповнюють один одного, а не конкурують. SPF заснований на логіці, так як він порівнює вхідні значення зі своїм списком. Хост, домен або iPad записані чи ні. DKIM використовує як логіку, так і криптографію у вигляді цифрових підписів. Ви можете прочитати більше про SPF у RFC 7208 від 2014 року.
Давайте впровадимо SPF в Google Workspace. Спочатку визначте будь-яких постачальників послуг, таких як Google або Outlook, і пов’язані домени, яким дозволено надсилати електронну пошту від імені вашої організації. (Ці домени можна вказати в записі MX.) Якщо використовується внутрішній поштовий сервер, наприклад Exchange, також визначте діапазони адрес, у яких можна надсилати електронну пошту від імені організації.
Потім для цих доменів і IP-адрес виберіть політику для різних ситуацій.
Pass (+): Дозволяє проходити всю електронну пошту (не рекомендується, за винятком короткочасного усунення несправностей).
No policy (?), neutral: Фактично, означає відсутність політики.
Soft fail (~): Щось проміжне між жорсткою перевіркою та нейтральною політикою; як правило, ці електронні листи приймаються, але позначаються як сумнівні.
Hard fail (–): Відхиляє електронного листа.
Як резервні копії можна настроїти щось на кшталт +all (не рекомендовано , оскільки це дозволить всю пошту), +mx (дозволить надсилати електронні листи з хоста, указаного в записі MX; не рекомендовано, якщо використовується хмарна електронна пошта, як-от Google або Office 365) або +nostarch.com (що дозволить отримувати електронні листи від nostarch.com).
Маючи ці відомості, можна створювати запис. Щоб почати, перейдіть до редактора записів DNS на панелі керування свого хостинг-провайдера та створіть новий запис TXT. Крім того, можна відредагувати наявні записи TXT, у тілі яких є v=spf1, як показано нижче:
dig walmart.com txt ; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> walmart.com txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6907 ;; flags: qr rd ra; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ; walmart.com. IN TXT ;; ANSWER SECTION: walmart.com. 300 IN TXT "v=spf1 include:_netblocks.walmart.com include:_smartcomm.walmart.com include:_vspf1.walmart.com include:_vspf2.walmart.com include:_vspf3.walmart.com ip4:161.170.248.0/24 ip4:161.170.244.0/24 ip4:161.170.241.16/30 ip4:161.170.245.0/24 ip4:161.170.249.0/24" " ~all" --сокращено-- ;; Query time: 127 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Tue Sep 08 05:42:49 UTC 2020 ;; MSG SIZE rcvd: 1502
Встановіть значення терміну дії пакета (TTL) на значення за замовчуванням 14 400. Значення TTL – це проміжок часу, протягом якого рекурсивні розпізнавачі імен DNS повинні кешувати наш запис SPF перед отриманням нового запису (якщо він змінився). Деякі критичні ресурси та балансувальники навантаження найкраще працюють із дуже невеликим значенням TTL. Рекомендовано призначати вищі значення TTL ресурсам, які не потребують частих змін або мають вбудоване резервування (наприклад, записам MX). Це робиться для боротьби з такими методами, як швидкий потік або динамічні записи DNS, які зазвичай використовуються в складних фішингових кампаніях та атаках на сайти соціальних мереж.
Потім назвіть запис TXT іменем домену організації. У тілі тексту введіть v=spf1, а потім механізми та правила, як згадувалося раніше. Щоб визначити ці механізми, потрібно знати п’ять типів дозволених полів:
ip4: адреса IPv4 або діапазон CIDR; ip6: IPv6-адреса; mx: запис MX відправника в службі DNS. a: адресний запис хоста в DNS; включають: посилання на політику іншого домену.
Тепер створіть рядок для входу в DNS. Скажімо, ви дозволяєте хостам використовувати запис MX nostarch.com на додаток до MailChimp і приватного, немаршрутизованого, важко перевіреного діапазону IP-адрес.
Текст для запису DNS матиме такий вигляд:
v=spf1 +mx include:192.168.1.22 include:192.168.2.0/24 include:servers.mcsv.net -all
Також можна зробити цей запис альтернативним способом. У розділі 4 ви дізналися, що No Starch використовує Google Workspace, тому ви можете замінити частину +mx серверами Google (яку можна знайти на інформаційній панелі Workspace). Щоб вмістити це в один рядок, видаліть включення для MailChimp SPF.
Альтернативний запис виглядатиме так:
v=spf1 include:_spf.google.com include:192.168.1.22 include:192.168.2.0/24 -all
Вставивши цей рядок у запис DNS, зачекайте до 72 годин, поки він пошириться на всі хости. Різні DNS-сервери в Інтернеті займають різний час для копіювання оновленої інформації. Цей час сильно залежить від параметра TTL, який наказує серверам кешувати інформацію протягом декількох секунд перед оновленням. З мого досвіду, SPF може почати працювати практично відразу, на відміну від DKIM. Незалежно від того, чи використовуєте ви Google як постачальника послуг електронної пошти чи ні, ви все одно можете скористатися сайтом перевірки MX панелі інструментів Google Admin Toolbox, щоб перевірити інформацію, надану відправником. Набір інструментів можна знайти за адресою https://toolbox.googleapps.com/ apps/checkmx/. Інструкції по налаштуванню SPF на інших платформах можна знайти тут: http://email-security.seosint.xyz/.
У главі 4 я згадував, що SPF дозволяє зловмисникам перераховувати домени, IP-адреси та діапазони IP-адрес, якими володіє або використовує організація. Зловмисники також можуть визначити, чи має ціль жорстку чи м’яку політику, перевіривши –all, ~all або ~? (нейтральний) у відповідній частині запису TXT. Ця інформація може вплинути на їхнє рішення про те, чи слід підробляти домен вашої організації або, можливо, використовувати щось інше. Соціальний інженер, який приділяє увагу деталям, може навіть налаштувати DKIM і SPF у своєму фішинговому домені, щоб обійти будь-які перевірки, які може мати організація, якщо вона застосовує будь-які політики.
SPF також може попередити зловмисників про ваші робочі відносини з іншими організаціями. Якщо іншим доменам потрібні повноваження для надсилання електронних листів від вашого імені, можливо, для них знадобиться створити записи SPF. Прикладами доменів, для надсилання яких потрібен дозвіл на надсилання електронних листів від імені організації, є списки розсилки, такі як MailChimp, Mailgun або Constant Contact. Також розгляньте інших постачальників, які надсилають електронні листи від імені організації, наприклад GoToMeeting або подібні платформи співпраці.
Останній аспект SPF – це не вразливість, а недолік. Як і DKIM, SPF легко впровадити і може захистити репутацію організації, але тільки в тому випадку, якщо сервер електронної пошти одержувача налаштований на перевірку записів SPF і дотримання певної політики. Однак невиконання цієї вимоги може завдати шкоди репутації вашої організації.
DMARC використовує існуючі реалізації SPF і DKIM і використовує їх для створення більш надійного рішення для запобігання спуфінгу, компрометації корпоративної електронної пошти та репутаційної шкоди. Вперше введений як стандарт Інтернету в 2015 році (RFC 7489), він спрямований на подолання недоліків як SPF, так і DKIM: він реалізує обидва попередні стандарти, але також повідомляє про успіхи та невдачі домену відправника. DMARC перевіряє розміщення відправника електронної пошти, тобто відповідність поля 5322.From автентифікованим доменним іменам. Іншими словами, він перевіряє, що електронний лист із полем “Від”, нібито надісланий від [email protected], дійсно надіслано з цього домену. Підроблений електронний лист може успішно пройти SPF і DKIM, але наткнеться на перевірку місця розташування відправника.
Ось що відбувається, коли для доставки повідомлення використовується протокол DMARC. Спочатку користувач пише електронний лист. Поштовий сервер-відправник вставляє в нього заголовок DKIM, а потім надсилає його одержувачу. Далі, щоб електронний лист пройшов через організацію з політикою DMARC, має відбутися дві речі. Спочатку електронний лист повинен пройти перевірку підпису DKIM ( поле 5322.From, з перевіркою за допомогою відкритого ключа, що міститься в DNS). По-друге, він повинен пройти перевірку записів SPF (5322.From) і TXT. Залежно від результатів цих перевірок, запис DMARC вкаже, чи повинен сервер прийняти або відхилити електронний лист. Всі несправності фіксуються для звіту. Потім електронний лист проходить усі процеси або фільтри, встановлені одержувачем, і, у разі успіху, потрапляє до папки “Вхідні” одержувача.
Широкого поширення набув протокол DMARC. Наприклад, в США його зобов’язані використовувати всі федеральні агентства і урядові організації. Особливо активно цей протокол впроваджувався в 2017 році. Крім використання цього протоколу, одержувач повинен самостійно перевіряти записи і застосовувати свої внутрішні політики.
Оновлення DMARC представлені у двох RFC: RFC 8553, який ввів підкреслення в іменах хостів; і RFC 8616, який стосується використання символів ASCII в неміжнародних символах SPF, DKIM і DMARC.
Перш ніж застосувати DMARC, слід налаштувати SPF і DKIM. Потім потрібно підготувати відомості для запису TXT. Ви можете знайти повний формат запису, визначений у розділі 6.3 RFC 7489, але вам знадобиться принаймні наступне:
Версія DMARC (v): версія DMARC, що використовується. В данийчас це 1, потім вказує v=DMARC1;
Політика (p): політика, що застосовується до даного домену;
Політика піддоменів (sp): політика, яка застосовується лише до піддоменів домену-відправника, наприклад, до електронних листів з адреси [email protected], але не з адреси [email protected]. За відсутності поля sp або кваліфікатора організація застосовуватиме основне поле p;
Відсоток «поганих листів», до яких застосовується політика (pct): число від 0 до 100, що визначає відсоток електронних листів від власника домену, до яких застосовується політика;Прапор rua: адреса електронної пошти, на яку надсилаються звіти. Складачі OSINT можуть дізнатися про цю адресу і використовувати її як зброю, тому рекомендується використовувати псевдонім.
Усі поля в записі DMARC, крім версії, мають містити визначники. Наприклад, для поля політики встановлено значення немає, помістити в карантин або відхилити. Указувач noone нічого не робить, тоді як карантин переспрямовує повідомлення електронної пошти до папки зі спамом або адміністраторів для перевірки та відхиляє Відхиляє повідомлення електронної пошти.
Ви також можете додати параметри аналізу безпеки та адресу для пересилання звітів про результати аналізу. Тег відмов на основі безпеки (fo) визначає, які події генеруватимуть звіт. Він має чотири параметри: 0 генерує звіт про аварійне завершення роботи, якщо спрацювали всі механізми захисту; 1 формує звіт про аварійне завершення роботи, якщо спрацювали окремі механізми; d генерує звіт про помилки DKIM у разі збою DKIM незалежно від місцезнаходження домену; та s генерує звіт про помилки SPF у разі збою SPF незалежно від місцезнаходження домену. Тег ruf вказує адресу електронної пошти, на яку надсилаються звіти. OSINT-колекціонери можуть читати його, як тег rua, і використовувати як зброю, тому використовуйте псевдоніми.
Два додаткових поля, adkim і aspf, визначають, чи потрібен власнику режим, який визначає дії, які потрібно виконати, якщо електронний лист не працює SPF або DKIM. Обидва мають можливі значення r для софт і s для суворої відповідності. М’яка відповідність вимагає точної відповідності лише для домену, тоді як жорстка відповідність вимагає повної точної відповідності. Обидва значення є необов’язковими та стандартними Встановіть режим м’якої перевірки.
Отже, нам потрібно вказати багато різної інформації. Налаштуємо запис DMARC для nostarch.com:
v=DMARC1; p=quarantine;pct=95; rua=mailto:[email protected]; fo=1; ruf=mailto:soc@ nostarch.com;
Цей запис містить політику карантину лише для домену. Це стосується 95% електронних листів, і будь-який збій призводить до аналізу безпеки, а звіти надсилаються до [email protected]. Для отримання загальних звітів DMARC призначається [email protected] адреса.
Створивши рядок запису, його потрібно додати до запису TXT у файлі зони DNS nostarch.com з іменами dmarc і TTL 14400.
Окрім розкриття тієї ж інформації, що й SPF, і того факту, що одержувачі вашої електронної пошти можуть не перевіряти SPF або DKIM, сам DMARC не створює значних проблем або вразливостей.
Однак просте створення записів DNS TXT для DMARC не забезпечує негайного захисту. Наприклад, може бути легко помилитися при налаштуванні реалізації DMARC. Налаштовуючи DMARC вперше, уникайте відхилення електронних листів, оскільки це позбавляє людей можливості перевіряти електронні листи на дійсність і може призвести до перебоїв або неправильно спрямованих повідомлень.
Ви можете пом’якшити ці ефекти, встановивши для початкової політики DMARC значення «немає» та переглянувши 100% електронних листів (p = немає; pct = 100;). З часом обережно зменшуйте значення поля PCT, доки не досягнете зручного для вас поєднання звітності та ефективності. Досягнувши хорошого рівня, змініть відсоток зворотного зв’язку на прийнятне, але реалістичне значення. Для бізнесу я рекомендую перевіряти від 60 до 85%, залежно від ваших ресурсів. Потім оновіть запис DMARC TXT, щоб відобразити цю зміну, наприклад p = карантин; PCT=75;.
Майте на увазі, що зловмисники, які використовують електронну пошту для отримання доступу до секретів вашої організації, можуть використовувати інструменти для підвищення своєї легітимності, тому не покладайтеся виключно на SPF, DKIM і DMARC. Наприклад, якщо суб’єкт зламає іншу організацію з налаштованими SPF, DKIM і DMARC, а потім надішле вашій організації електронний лист через законні канали, він пройде всі перевірки, пов’язані з цими трьома стандартами.
Іншим вектором загрози, який не покривається DMARC, є шифрування. Ці три стандарти не надають засобів шифрування електронної пошти. Звичайно, DKIM використовує криптографію, але тільки для підписування електронних листів. У наступних розділах описано, як заповнити цю прогалину.
Спочатку розроблені поштові протоколи SMTP, POP та IMAP не включали шифрування. У міру розвитку атак розробники поштових протоколів створили механізм безпеки транспортного рівня (TLS) для шифрування повідомлень. Іноді його можна розпізнати по імені STARTTLS після команди, яка використовується для запуску служби.
Ось як працює STARTTLS. По-перше, сервер-відправник підключається до приймального сервера, як зазвичай. Потім він запитує обмін через розширений протокол SMTP, який дозволяє передавати зображення та вкладення. Далі відправник запитує сервер-одержувач, чи підтримує він STARTTLS. Якщо відповідь позитивна, з’єднання перезапускається, а електронна пошта шифрується за допомогою версії протоколу SSL або TLS, узгодженої обома хостами. Якщо відповідь негативна, електронний лист надсилається незашифрованим. Інший варіант, який називається примусовим TLS, запобігає надсиланню електронної пошти, якщо з’єднання незахищене. Використання примусового TLS не є широко поширеним через блокування пошти, якщо шифрування неможливо домовитися.
Найбільша проблема з STARTTLS полягає в тому, що це опортуністичний (примирливий) протокол, тобто він використовує шифрування лише тоді, коли він доступний. Якщо шифрування недоступне або не підтримується, повідомлення буде надіслано у відкритому вигляді. Ще одна проблема з STARTTLS полягає в тому, що саме шифрування «рукостискання» (обмін ключами) відбувається у відкритому тексті, що дозволяє потенційним зловмисникам красти інформацію про сеанс або змінювати повідомлення, використовуючи атаки “людина посередині”. Ви можете побачити обидві ці проблеми, які використовуються в атаках STRIPTLS, де зловмисник або відключає фактичну команду STARTTLS, або моделює ситуацію, коли TLS недоступний. Налаштувавши SMTP на вимогу TLS для вихідних з’єднань, ви можете зменшити загрозу STRIPTLS, але ви можете втратити служби вихідної електронної пошти, якщо TLS не налаштовано належним чином або одержувач не налаштував отримання електронних листів TLS або заблокував порт.
Інший спосіб пом’якшити загрозу STRIPTLS – це додаткова функція розширень безпеки системи доменних імен (DNSSEC), яка називається автентифікацією іменованих сутностей на основі DNS (DANE). Реалізація DANE вимагає від організацій створення запису DNS, який маршрутизує всі з’єднання через певний порт або протокол для узгодження сеансу за допомогою відкритого ключа, розміщеного в DNS. Ця інформація також може бути неправильно використана або зібрана в рамках OSINT-зусиль, як і будь-що інше в загальнодоступних записах DNS, оскільки зловмисник може запитувати записи DNS і робити висновки із записів. Хоча DANE досить легко реалізувати, цього не можна сказати про DNSSEC в цілому, тому я не бачив, щоб він став широко поширеним.
Приблизно в той же час, коли розроблявся DANE, було запропоновано інше рішення тієї ж проблеми (атаки STRIPTLS): протокол SMTP MTA Strict Transport Security (MTA-STS).
MTA-STS – це ще один спосіб впровадження TLS для захисту повідомлень електронної пошти. У цьому методі обидві сторони домовляються про рукостискання TLS, використовуючи записи DNS TXT, а також файли, завантажені в певні каталоги в заздалегідь визначеному загальнодоступному піддомені домену, що посилає.
Цей стандарт застосовується тільки до SMTP-трафіку між поштовими серверами. Зв’язок між клієнтом і сервером здійснюється за допомогою протоколу HTTP Strict Transport Security (HSTS). Через складність реалізації MTA-STS я не буду тут описувати цей процес. Ви можете знайти посилання на навчальні посібники на http://email-security.seosint.xyz/.
Звітність SMTP TLS (TLS-RPT) – це метод збору статистики про потенційні збої в переговорах TLS і пов’язаних областях. Це приблизно те ж саме, що і DMARC, якби MTA-STS був елементом DKIM. Зібрану інформацію можна використовувати для усунення несправностей або аналізу загроз.
Налаштування TLS-RPT відносно просте, оскільки для цього потрібен лише запис TXT DNS з _smtp._tls.domain.tld та адреса звітів у тексті. Якщо в електронному листі, який використовує зашифрований метод (DANE або MTASTS), виникає помилка, на адресу звіту буде надіслано сповіщення. Ось приклад для nostarch.com:
smtp._tls.nostarch.com 300 «v=TLSRPTv1;rua=mailto:[email protected]»
Верхній рядок – це ім’я поля та TTL. Другий рядок – значення. Тут ми встановили TTL на 300 і надішліть звіт до soc@ nostarch.com.
Останнім кроком до безпеки електронної пошти є використання технологій фільтрації. Зазвичай це означає наймання посередника або постачальника послуг, який буде отримувати ваші електронні листи до вас. Торговельний посередник просканує їх на наявність ознак шкідливої пошти, які він спостерігає на всіх клієнтах, і перевірить наявність SPF, DKIM і DMARC, якщо вони налаштовані. Фільтрація електронної пошти не ідеальна, але вона знімає більшу частину навантаження з технічного персоналу. Однак майте на увазі, що наймання постачальника, швидше за все, вимагатиме внесення змін до ваших загальнодоступних записів DNS, і зловмисник може виявити ці зв’язки за допомогою методів OSINT, як обговорювалося раніше.
Існує безліч конфігурацій і додатків для проміжної фільтрації. Вибираючи постачальника послуг, враховуйте пропускну здатність його електронної пошти за хвилину або секунду. Також вирішіть, чи потрібно підтримувати фільтрування електронної пошти за допомогою програмного забезпечення, апаратного пристрою або хмарної служби. Кожен варіант має унікальні проблеми, особливо з точки зору впровадження, підтримки, доступності та звітності, і кожен пропонує різні функції. Фільтрування електронної пошти легше застосовувати в хмарних екземплярах, оскільки вони найкраще захищають доступність електронної пошти. Однак будь-яке рішення, яке вимагає конфігурації, особливо за межами записів DNS, може призвести до збоїв, збоїв або поганої безпеки. Якщо ви вирішите використовувати постачальника хмарних послуг, ви також будете залежати від SLA (угоди про рівень обслуговування) та вашого контракту з постачальником. Однак вони спрощують процес; Ви несете відповідальність лише за оновлення запису MX у файлі зони DNS і вибір правильних настройок.
Деякі постачальники також підтримуватимуть та керуватимуть вашими реалізаціями SPF, DKIM та DMARC замість вас. Зважте ризики того, що може статися, якщо система вийде з ладу, і переваги, які ви отримаєте від її використання. Чи надає постачальник інформацію про загрози? Чи спеціалізується він саме на цій послузі? Що обумовлюється в договорі?
Як фахівці з безпеки, ми повинні побудувати наші системи таким чином, щоб вони могли не тільки справлятися зі звичайними навантаженнями, але й протистояти зловживанням таким чином, щоб зловмисник був змушений діяти досить довго, залишаючи нам час для виявлення та реагування.
Захищаючи свої системи від фішингу, радимо впровадити елементи керування, крім тих, які використовуються виключно для електронної пошти. Хоча ми не будемо обговорювати їх у цьому розділі, реалізуйте захист від зловмисного програмного забезпечення, будь то антивірус, функція виявлення та реагування на кінцеві точки (EDR) або будь-який інший продукт для захисту від зловмисного програмного забезпечення. Більшість шкідливих програм потрапляє в мережу компанії електронною поштою, коли користувачі завантажують його за посиланням у фішинговому електронному листі.
Запобігти катастрофічним наслідкам фішингу можуть дві інші технології: моніторинг цілісності файлів (FIM) і запобігання втраті даних (DLP). FIM відстежує файли з певного списку для модифікації. Ви можете написати просте рішення FIM, яке бере криптографічний хеш кожного файлу і зберігає його десь. Потім додаток підтверджує, що файли не змінювалися, і якщо вони змінилися, перевірить, чи була зміна авторизована. Це важливо для виявлення зловмисників вже в мережі. Якщо вміст файлу було змінено без дозволу, це може свідчити про запуск або встановлення нових програм, вимагацьке ПЗ або несанкціоноване втручання у важливі файли.
DLP не дозволяє користувачам відправляти файли електронної пошти за межі організації, завантажувати файли в публічну зовнішню мережу і файлообмінні сервіси (наприклад, Google Drive або Dropbox) або зберігати дані на неавторизованих USB-пристроях (якщо тільки можливість підключення таких пристроїв не заблокована). Багато рішень DLP також мають можливість заборонити користувачам обмінюватися конфіденційними або обмеженими даними, такими як дані платіжних карток клієнтів. Це важливо, оскільки не дозволяє користувачам передавати інформацію, яка становить комерційну таємницю та інтелектуальну власність. Наявність DLP також усуває багато причин, за якими користувачі підключають USB-накопичувач до своїх робочих станцій, зменшуючи ймовірність успішної атаки приманки.
Ми використовували матеріали з книги “Соціальна інженерія та етичний хакінг на практиці”, які були написані Джо Греєм.
747 
593 
665 
669 
616 
648 
609 
639 
644