Embed Size (px)
Citation preview
Станислав Терновский
Инженер центра технической поддержки Cisco TAC (Krakow)
Июнь 17, 2015
Как избежать фишинга через электронную почту. Защита e-mail инфраструктуры с помощью Cisco ESA посредством аутентификации сообщений.
Cisco Support Community
Expert Series Webcast
Вебинар на русском языке
Июль 21, 2015
Недавно компания Cisco представила на рынке новое семейство коммутаторов – Nexus 9000. Благодаря реализованным в этих устройствах решениям и технологиям, они оптимизированны для работы в датацентрах нового поколения и являются следующим шагом к SDN.
На данном семинаре инженер подразделения техничекой поддержки Cisco Александр Нестеров рассмотрит архитектуру устройств семейства Nexus 9000, а так же решения и технологии реализованные в них.
Платформа Nexus 9000 –
архитектура и особенности
https://supportforums.cisco.com/ru/event/12535056
Александр
Нестеров
Как стать активным участником? Легко!
• Создавайте документы, пишите блоги, загружайте
видео, отвечайте на вопросы пользователей.
• Вклад оценивается на основе таблицы лидеров
• Также оценивается количество документов, блогов
и видео, созданных пользователем.
• Вклад оценивается только по русскоязычному
сообществу, не включая рейтинг, набранный в
глобальном Cisco Support Community.
Премия "Самый активный участник Сообщества Поддержки Cisco"
Оцени контент
Ваши оценки контента дают возможность авторам получать баллы.
Хотите чтобы поиск был удобным и простым? Помогите нам распознать качественный контент в Сообществе. Оценивайте документы, видео и блоги.
Пожалуйста, не забывайте оценивать ответы пользователей, которые щедро делятся своим опытом и временем.
https://supportforums.cisco.com/ru/community/4926/pomoshch-help
17 июня – 23 июня 2015
Сессия «Спросить Эксперта» со Станиславом Терновским
Получить дополнительную информацию, а также задать вопросы эксперту в рамках данной темы Вы можете на странице, доступной по ссылке: https://supportforums.cisco.com/community/russian/expert-corner Вы можете получить видеозапись данного семинара и текст сессии Q&A в течении ближайших 5 дней по следующей ссылке https://supportforums.cisco.com/community/russian/expert-corner/webcast
Конкурс “Защита e-mail инфраструктуры с помощью Cisco ESA”
17 июня в 14:00 мск
Мы предлагаем Вам принять участие в конкурсе после проведения вебкаста, который так и будет называться
«Защита e-mail инфраструктуры с помощью Cisco ESA»
• Первые три победителя получат фирменный куб Cisco-TAC
• Ответы присылайте на [email protected]
• Задание конкурса будет размещено сегодня после проведения
вебкаста (14-00мск)
Скачать презентацию Вы можете по ссылке:
https://supportforums.cisco.com/ru/document/12534301
Спасибо, что присоединились к нам сегодня!
Присылайте Ваши вопросы! Используйте панель Q&A, чтобы задать вопрос.
Станислав ответит на Ваши вопросы после
презентации в режиме он-лайн
Сегодняшняя
презентация включает
опросы аудитории
Пожалуйста, примите
участие в опросах!
Станислав Терновский
Инженер центра технической поддержки Cisco TAC (Krakow)
Июнь 17, 2015
Cisco Support Community Expert Series Webcast
Как избежать фишинга через электронную почту. Защита e-mail инфраструктуры с помощью Cisco ESA посредством аутентификации сообщений.
Вопрос 1
Сталкивались ли вы с фишингом в сообщениях электронной почты?
1. Да
2. Нет
3. Что такое фишинг?
• Введение в фишинг
• Настройка протокола SPF на Cisco ESA
• Настройка протокола DKIM на Cisco ESA
• Настройка протокола DMARC на Cisco ESA
Содержание
Введение в фишинг
Фишинг
Фи́шинг (англ. phishing, от fishing — рыбная ловля, выуживание[1]) — вид
интернет-мошенничества, целью которого является получение доступа к
конфиденциальным данным пользователей — логинам и паролям.
www.ru.wikipedia.org
Пример фишинга
Краткая история фишинга
- Первое упоминание термина “фишинг” было в утилите AOHell.
- 1996 год
- Первое использование фишинга в сети AOL
- 2001 год
-
Первая в истории фишинг атака на платежную систему E-gold
-
“post-9/11 id check” атака после событий 11 сентября 2001 года
- 2003 год
- Первая фишинг атака против банка
Основы SMTP протокола
Настройка протокола SPF на Cisco ESA
Sender Policy Framework
SPF - Sender Permitted From
Описан в RFC 7208 в апреле 2014, который заменил RFC 4408.
Краткое описание: идея заключается в объявлении ай-пи адресов, которые
авторизированы отправлять почту от имени домена, и сделать этот список
публично доступным через DNS.
Использует DNS TXT(тип 16) запись. Ранее также использовалась DNS SPF
(тип 99) запись. Она была отменена в RFC7208 из-за крайне редкого
использования и возможных путаниц.
Могут проверяться “HELO/EHLO” и “MAIL FROM” SMTP команды.
email Передача
DNS txt запись
Хосты, которые
могут отправлять
example.com
Входящее
соединение
Запрос SPF
записи
Проверка ip
сервера, “mail
from”, HELO
Действие над
сообщением
Принцип действия SPF
acmilan.com. 599 IN TXT "v=spf1 ip4:77.92.66.4 -all"
Семантика SPF записи
версия
механизмы SPF
Можно запросить txt DNS запись вручную:
$ nslookup –q=txt example.com
$ dig mx example.com
Проверка txt DNS SPF записи
Механизмы SPF ip4 - соответствует ipv4 ай-пи адресу или диапазону ай-пи адресов :
192.168.1.1 или 192.168.1.0/24
ip6 - соответствует ipv6 ай-пи адресу или диапазону ай-пи адресов :
2001::1 или 2001::/64
mx:<domain> - соответствует ай-пи адресу, полученному из MX записи домена.
a:<domain> - соответствует ай-пи адресу, полученному из A записи домена.
all(?all, ~all, -all) - данный механизм указывает необходимые действия касательно всех
остальных ай-пи адресов.
Вердикты SPF проверки
- None
- Neutral
- SoftFail
- Fail
- TempError
- PermError
cisco.com. 2071 IN TXT "v=spf1 ip4:173.37.147.224/27 ip4:173.37.142.64/26 ip4:173.38.212.128/27 ip4:173.38.203.0/24
ip4:64.100.0.0/14 ip4:72.163.7.160/27 ip4:72.163.197.0/24 ip4:144.254.0.0/16 ip4:66.187.208.0/20 ip4:173.37.86.0/24"
" ip4:64.104.206.0/24 ip4:64.104.15.96/27 ip4:64.102.19.192/26 ip4:144.254.15.96/27 ip4:173.36.137.128/26 ip4:173.36.130.0/24
mx:res.cisco.com mx:sco.cisco.com ~all»
amazon.com. 900 IN TXT "v=spf1 include:spf1.amazon.com include:spf2.amazon.com include:amazonses.com -all”
spf1.amazon.com. 900 IN TXT "v=spf1 ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.192.0/19
ip4:194.154.193.192/27 ip4:194.7.41.152/28 ip4:212.123.28.40/32 ip4:203.81.17.0/24 ip4:72.21.212.0/25 ip4:178.236.10.128/26 -all”
spf2.amazon.com. 900 IN TXT "v=spf1 ip4:176.32.105.0/24 ip4:176.32.127.0/24 ip4:106.50.16.0/28 -all”
amazonses.com. 900 IN TXT "v=spf1 ip4:199.255.192.0/22 ip4:199.127.232.0/22 ip4:54.240.0.0/18 -all”
openspf.org. 3600 IN TXT "v=spf1 -all"
Пример SPF записи
Рекомендации по SPF
- Цель SPF - запись для каждого домена должна заканчиваться “-all”
- Задать в SPF записи все сервера, которые отправляют эл.почту
- Добавить SPF запись для каждого сервера(HELO проверка): example.com. IN TXT "v=spf1 mx:example.com -all"
mailserver.example.com. IN TXT "v=spf1 a -all”
- Добавить нулевую SPF запись для всех доменов/серверов, которые
не шлют эл.почту: sales.example.com. IN TXT "v=spf1 -all”
mailserver2.example.com. IN TXT "v=spf1 -all”
Received-SPF: SoftFail identity=mailfrom; clientip=192.168.1.1; receiver=user.example.com; envelope-from="[email protected]"; x-sender="[email protected]"; x-conformance=spf_only; x-record-type="v=spf1"
Received-SPF заголовок
Настройка SPF на ESA
Проверка входящих сообщений:
- Настройка Mail Flow Policies.
Настройка Message Filter
quarantine-spf-failed-mail: if spf-status("mailfrom") == "Fail" {
quarantine("Policy");
} else {
if spf-status("mailfrom") == "SoftFail" {
quarantine("Policy");
}
}
quarantine-spf-failed-helo: if spf-status(”helo") == "Fail" {
quarantine("Policy");
} else {
if spf-status(”helo") == "SoftFail" {
quarantine("Policy");
}
}
Настройка протокола DKIM на Cisco ESA
Domain Keys Identified Mail
- Определен в RFC5585:
- Дополнен в следующих RFC: RFC6376(DKIM Signature), RFC5863(DKIM
Development, Deployment and Operation), RFC5617(Author Domain Signing
Practices)
- Краткое описание:
- DKIM – это метод e-mail аутентификации. Это цифровая подпись,
которая прилагается к письму, по которой можно определить, отправлено
ли данное письмо от настоящего отправителя(является ли отправитель,
указанный в заголовке “From” настоящим)
- Использует txt DNS записи для публикации публичного ключа домена.
Подпись
email(DKIM
signature)
DNS txt запись Private/public
пара ключей
example.com
Входящее
соединение
Запрос DKIM
записи
Проверка
b и bh
Действие над
сообщением
Принцип действия DKIM
Передача
DKIM подпись
Обязательные поля
Опциональные поля
D
Рекомендуемые поля
V A S H B BH
C I L Z
T X
Q
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt;
c=relaxed/simple;s=hwblxdtwo6g37yq6ivfmb4s74hozqz45; d=amazon.co.uk;
t=1425865051;h=Date:From:To:Message-ID:Subject:MIME-Version:Content-
Type;bh=9WsR2iJGBIkY7MHOnVW5066wYifSwMnY0+yB+rpuvlc=;b=gPv
Mr5hqkns68nK5xes9GGz5j53f3rwrltVrYMZrU6BDTjAw0iifi4jqlO80gC3xeH5
R02VlP6HD9dN43ZsyvdsBIS79zMtZqIxKmmm2D4jgS/nOrObXkAR3egXc5uu
BBhy3llkMx78xrBKjRy1kYzuErSOLuIr/9jEYNYtYSD4=
Семантика/пример DKIM подписи
версия используемые алгоритмы селектор
домен
подписываемые
заголовки
хеш
заголовков
хеш
тела сообщения
Алгоритмы DKIM подписи
RSA-SHA1 или RSA-SHA256
512 бит 1024 бит 2048 бит
Клиент обязан
Сервер обязан
Клиенту следует
Сервер обязан
Сервер обязан Сервер обязан Клиент обязан
(long-lived keys)
Рекомендуемая длина ключа
DKIM канонизация
Канонизация – это приведение заголовков и текста сообщения к стандартному
виду для уменьшения вероятности изменения письма в пути промежуточными
устройствами.
2 вида канонизации:
Простая - практически никаких изменений не разрешено
Нестрогая - разрешены некоторые изменения. Например, регистр,
текста заголовков, перенос строк, изменение количества
пробелов.
DKIM канонизация заголовков
Простая канонизация заголовков:
- Запрещено изменять заголовки
- Порядок, регистр, количество пробелов сохраняется
Нестрогая канонизация заголовков:
- Имена заголовков преобразуются в нижний регистр
- Последовательности пробелов(WSP) заменяются единственным пробелом
- Удаляются пробелы в конце строки
- Удаляются пробелы до/после “:”, разделяющего название заголовка от его
содержимого.
DKIM канонизация тела сообщения
Простая канонизация тела сообщения:
- Никаких изменений в теле сообщения за исключением:
- Удаляются пустые линии в конце.
- Добавляется символ “перевода строки” в конце тела сообщения, если
его нету.
Нестрогая канонизация тела сообщения:
- Все изменения простой канонизации
- Не удаляются все пробелы в конце строки
- Последовательности пробелов заменяются единственным пробелом.
Обязательные поля
Опциональные поля
Рекомендуемые поля
P
H=SHA1
V=DKIM1
DKIM DNS запись
K=RSA S=EMAIL T=Y T=S G N
Можно запросить txt DNS запись вручную:
$ nslookup –q=txt selector._domainkey.example.com
$ dig txt selector._domainkey.example.com
Проверка txt DNS DKIM записи
Пример DKIM DNS записи
hwblxdtwo6g37yq6ivfmb4s74hozqz45.dkim.amazonses.com. 3600 IN TXT
"p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUV9ADPklk6pAvcAmlyWm
M+y/Zdxnzw2fId6fPewIbX8khcPJJsbv+LWaMGhO3jfTGonOs3OwVvqvaZHtgwwOQD2
N31auTFPG8tWtI3d0pFQoQ+vSh/A1oLjSVBoOm6+B842WtcaO0LmtAxBgjDvYh3eiT
moY+7cLagVW51zBnpQIDAQAB”
iport._domainkey.cisco.com. 86400 IN TXT "v=DKIM1\; s=email\; p=MIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQCctxGhJnvNpdcQLJM6a/0otvdpzFIJuo73OYFuw
6/8bXcf8/p5JG/iME1r9fUlrNZs3kMn9ZdPYvTyRbyZ0UyMrsM3ZN2JAIop3M7sitqHgp8p
bORFgQyZxq+L23I2cELq+qwtbanjWJzEPpVvrvbuz9QL8CUtS+V5N5ldq8L/lwIDAQAB\;"
Authentication-Results: MX1.example.com; dkim=pass (signature verified) [email protected]; dmarc=fail (p=quarantine dis=quarantine) d=amazon.co.ukX-Remote_IP: 54.xxx.xxx.97
Authentication-Results заголовок
Вердикты проверки DKIM подписи
- None
- Neutral
- HardFail
- Pass
- TempError
- PermError
Настройка DKIM на ESA
Подпись исходящих сообщений:
- Сгенерировать пару ключей
- Настроить подписывающий профайл домена
- Активировать подпись сообщений для RELAYED Mail Flow Policy
Проверка входящих сообщений:
- Настроить проверяющий профайл
- Активировать проверку для Mail Flow Policies
- Настроить Content фильтр
Настройка протокола DMARC на Cisco ESA
DMARC
Domain-based Message Authentication, Reporting and Conformance – идентификация
сообщений, создание отчётов и определение соответствия по доменному имени.
Политика DMARC позволяет отправителю указать, что их электронная почта
защищена механизмами SPF и DKIM, и что необходимо делать с письмами,
если они признаны поддельными(не прошли проверок аутентификации).
SPF
политика
DKIM
политика
DMARC
политика
Подпись
email(DKIM
signature)
SPF (txt) DNS
запись
DKIM (txt)
DNS запись
DMARC (txt)
DNS запись
Хосты, которые могут отправлять
Проверка
SPF
Проверка
DKIM
DMARC
политика
Align
identifiers
Применение
DMARC
политики
Отправление
DMARC
репорта
Передача
Принцип действия DMARC
DMARC DNS запись
Обязательные поля
Опциональные поля
V=DMARC1 P
PC
T SP ADKIM ASPF RI RUA RF FO RUF
Можно запросить txt DNS запись вручную:
$ nslookup –q=txt _dmarc.example.com
$ dig txt _dmarc.example.com
Проверка txt DNS DMARC записи
_dmarc.amazon.co.uk. 900 IN TXT "v=DMARC1\; p=quarantine\; pct=100\;
rua=mailto:[email protected]\;
ruf=mailto:[email protected]"
Семантика DMARC записи
версия политика
выборка(sampling rate)
URI для агрегированных отчетов URI для отчетов об ошибках
DMARC политики
Политики, запрашиваемые владельцами доменов:
- None
- Quarantine
- Reject
Получатели могут отклоняться от этих политик, но в таком случае им следует
проинформировать владельца домена “почему”(посредством агрегированного
отчета)
Выборка (“pct” таг) информирует получателей применять политику к заданному
% сообщений от общего количества(– процентная доля сообщений,
подлежащих фильтрации )
DMARC отчеты
Поддерживаются 2 типа URI:
- mailto:
- http://
2 типа отчетов:
- Агрегированный отчет(Aggregate report):
- Генерируется с определенной периодичностью(раз в 24ч)
- Статистика по определенному домену
- Отчет об ошибках
- Генерируется каждый раз, когда email не проходит DMARC проверку
- Детализированная статистика по каждому событию
DMARC отчет об ошибках
2 формата отчетов:
- afrf – Отчет об ошибках аутентификации. Определен в RFC6591
- iodef – Спецификации IODEF. Определен в RFC5070
DMARC domain alignments
Когда сообщение проходит DMARC проверку:
- DMARC проверяет подлинность домена из заголовка “From”
- DKIM проверяет подлинность домена из DKIM-подписи(“d=” тэг)
- SPF проверяет подлинность домена из “MAIL FROM/HELO”
- Identifier Alignment – это концепция сравнения заголовка “From” и
результатов проверки механизмов SPF и DKIM.
- Сообщение проходит DMARC проверку, если, как-минимум, один из
механизмов (SPF и/или DKIM) проходит проверку.
Строгость соблюдения DKIM/SPF
Владелец домена может определить 2 варианта соблюдения DKIM/SPF
политик:
- Строгий (“s” - strict)
- Мягкий (“r” - relaxed) – применяется по умолчанию
DKIM(“adkim”):
- Мягкий: Заголовок “From” может быть сабдоменом домена в
“d” поле DKIM подписи(sales.example.com; “d”=example.com)
- Строгий: Заголовок “From” должен соответствовать тэгу“d”
SPF(“aspf”):
- Мягкий: “MAIL FROM” может быть сабдоменом домена
- Строгий: “MAIL FROM” должен соответствовать домену
DMARC identifier alignment: SPF
MAIL FROM: [email protected]
From: Stanislau Tsiarnouski (stsiarno) [email protected]
To: Stanislau Tsiarnouski<[email protected]>
Subject: DMARC test
MAIL FROM: [email protected]
From: Stanislau Tsiarnouski (stsiarno) [email protected]
To: Stanislau Tsiarnouski<[email protected]>
Subject: DMARC test
aspf=“r” aspf=“s”
✔ ✔
✔ ✗
MAIL FROM: [email protected]
From: Stanislau Tsiarnouski (stsiarno) [email protected]
To: Stanislau Tsiarnouski<[email protected]>
Subject: DMARC test
✗ ✗
DMARC identifier alignment: DKIM
DKIM-Signature: v=1; […] d=cisco.com; […]
From: Stanislau Tsiarnouski (stsiarno) [email protected]
To: Stanislau Tsiarnouski<[email protected]>
Subject: DMARC test
adkim=“r” adkim=“s”
✔ ✔
DKIM-Signature: v=1; […] d=cisco.com; […]
From: Stanislau Tsiarnouski (stsiarno) [email protected]
To: Stanislau Tsiarnouski<[email protected]>
Subject: DMARC test
✔ ✗
DKIM-Signature: v=1; […] d=ironport.com; […]
From: Stanislau Tsiarnouski (stsiarno) [email protected]
To: Stanislau Tsiarnouski<[email protected]>
Subject: DMARC test
✗ ✗
Вердикты DMARC проверки
- Pass
- Fail
- TempError
- PermError
Настройка DMARC на ESA
Проверка входящих сообщений:
- Настройка DMARC Verification Profile
- Настройка Mail Flow Policies.
Вопрос 2
Какие нюансы ESA вы бы хотели узнать более детально в следующем вебинаре?
1. Общие рекомендации по оптимальной конфигурации
2. Обзор AMP engine
3. Конфигурация фильтров(Message/Content). Regular Expressions
Вопрос 3
Используете ли вы технологии, рассмотренные во время презентации, чтобы защитить вашу email инфрастуктуру?
1. Да, уже внедрены
2. Нет, но планировали внедрение
3. Нет, и в ближайшее время внедрение не планировали
Отправьте свой вопрос сейчас! Используйте панель Q&A, чтобы задать вопрос.
Эксперты ответят на Ваши вопросы.
Приглашаем Вас активно участвовать в Сообществе и социальных сетях
Vkontakte http://vk.com/cisco
Facebook http://www.facebook.com/CiscoSupportCommunity
Twitter https://twitter.com/CiscoRussia
You Tube http://www.youtube.com/user/CiscoRussiaMedia
Google+ https://plus.google.com/106603907471961036146
LinkedIn http://www.linkedin.com/groups/Cisco-Russia-CIS-3798428
Instgram https://instagram.com/ciscoru
Подписаться на рассылку [email protected]
Мы также предоставляем Вашему вниманию Сообщества на других языках!
Если Вы говорите на Испанском, Португальском или Японском, мы приглашаем Вас принять участие в Сообществах:
Русское http://russiansupportforum.cisco.com
Испанское https://supportforums.cisco.com/community/spanish
Португальское https://supportforums.cisco.com/community/portuguese
Японское https://supportforums.cisco.com/community/csc-japan
Китайское http://www.csc-china.com.cn
Если Вы говорите на Испанском,
Португальском или Японском, мы
приглашаем Вас принять участие и вести
общение на Вашем родном языке
Технические семинары в клубе Cisco Expo Learning Club
http://ciscoclub.ru/events
Пожалуйста, участвуйте в опросе
Спасибо за Ваше внимание!
