отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
Cisco Employee

Спросить эксперта: "Как избежать фишинга через электронную почту. Защита e-mail инфраструктуры с помощью Cisco ESA посредством аутентификации сообщений"

со Станиславом Терновским

 

Read the bio

Во время сессии "Спросить Эксперта" Станислав Терновский ответит на вопросы о том, как защитить инфраструктуру электронной почты с помощью Cisco ESA посредством аутентификации сообщений. А также Вы сможете задать свои вопросы относящиеся к основным принципам и настройке протоколов SPF, DKIM, DMARC на Cisco ESA.

 

Станислав - инженер центра технической поддержки Cisco (TAC) в Кракове. Станислав специализируется на работе с продуктами Cisco в области безопасности такими как Email Security уже более 6 лет. Станислав также является сертифицированным экспертом CCIE SP

 

Пожалуйста, не забывайте оценивать ответы Станислава, чтобы он знал, что Вы получили совет, который Вам помог. Общение может быть продолжено на нашем форуме и после окончании сессии. Сессия продлится до 30 июня.

 

Хотите узнать больше информации об этом событии?

 

  Contest-green-button-russian.jpg    

Теги (6)
7 ОТВЕТ.

Cпасибо за содержательный

Добрый день!

 

Станислав,  у меня вопрос по Outgoing Accept Query.

Нужно Allow/Deny internal senders from relaying out to the Internet, depending upon the existence of their mail address in the LDAP.

 

Согласно документу (TAC ID 118580):

1) Private Listener не подходит, т.к. bypass RAT.

2)  для Public Lister не подходит RELAY Connection Behavior (т.к. bypass RAT).

 

Т.о. нужно использовать только Public Listener с ACCEPT Connection Behavior, а следовательно, почта будет обрабатываться как входящая (Incoming Mail Policy).

 

Собственно, данное ограничение и описано в начале документа:

LDAP Accept Query is applied only to inbound connections. For this reason the 'Connection Behavior' of the Mail Flow Policy must NOT be set to Relay for this setup to work.

 

Есть ли какой-нибудь способ обойти данное ограничение?

New Member

Добрый день,Вы правы насчет

Добрый день, Дмитрий!

Описанный в данной статье способ - это единственный вариант обойти это ограничение на сегодняшний день.

Также существует Feature Request CSCuq22301 "Feature request for SMTP Accept LDAP query for outgoing messages" для аналога LDAP accept query только для проверки "MAIL FROM" вместо "RCPT TO".

К сожалению,  дата/версия, когда планируется внедрить эту функцию, неизвестны.

 

С уважением,

Стас.

ACCEPT Connection Behavior,

Станислав, спасибо. Вопрос по

Станислав, спасибо.

 

Вопрос по ключам подписи.

В случае >1 шлюза в домене, два решения как прописать DK:

1. использовать один ключ (и селектор) на всех шлюзах (одна запись в зоне)

2. использовать разные ключи + разные селекторы: кол-во записей в зоне = кол-ву шлюзов.

 

Второй вариант предпочтительней?

 

New Member

Дмитирий, добрый день!С моей

Дмитирий, добрый день!

С моей точки зрения, несколько DKIM записей - более защищенное решение, диверсификация шлюзов. При компрометации приватного ключа одного шлюза, ключ второго не будет скомпрометирован.

А принимающим SMTP серверам все равно какую DKIM TXT DNS запись запрашивать.

 

С уважением,

Станислав.

 

Станислав, А как прописывать

Станислав,

 

А как прописывать ключи в случае кластера?

В domain signing profile прописал 2 ключа (на уровне кластера).

Через override setting на каждом шлюзе ?

 

И еще вопрос - не понятно, почему DKIM not aligned:
Info: Start MID 1234 ICID 5678
Info: MID 1234 ICID 5678 From: <xxx@gmail.com>
Info: MID 1234 ICID 5678 RID 0 To: <yyy@example.com>
Info: MID 1234 SPF: helo identity postmaster@mail-ig0-f177.google.com None 
Info: MID 1234 SPF: mailfrom identity xxx@gmail.com Pass (v=spf1) 
Info: MID 1234 DKIM: pass signature verified (d=gmail.com s=20120113 i=@gmail.com)
Info: MID 1234 DMARC: Message from domain gmail.com, DMARC pass (SPF aligned True, DKIM aligned False)
Info: MID 1234 DMARC: Verification passed

и i=, и d= tags совпадают с доменом в поле From. Политика домена прописана по дефолту (relaxed):

$ dig +short _dmarc.gmail.com. txt
"v=DMARC1\; p=none\; rua=mailto:mailauth-reports@google.com"

 

 

 

New Member

Дмитрий, добрый день


Re >>> "А как прописывать ключи в случае кластера?"

В случае кластера сгенерированная пара ключей копируется на все ESA в кластере. Например, у вас кластер из 2 машин. В этом случае приватный ключ скопируется и на ESA1, и на ESA2. А далее вы можете использовать данный Signing Key в подписывающих профайлах и тд.


Re >>> "В domain signing profile прописал 2 ключа (на уровне кластера). Через override setting на каждом шлюзе ?"

Если я правильно вас понял, то вы хотите, чтобы каждый член кластера использовал свою собственную пару приватный/публичный ключ. В таком случае, я бы рекомендовал настройки Signing Keys, Signing Profiles задать на машинном уровне.

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

Поправьте меня, если я неправильно вас понял.


Re >>> "И еще вопрос - не понятно, почему DKIM not aligned"


Хотелось бы глянуть на оригинальное сообщение, а именно на заголовки "From", "DKIM-Signature". Так тяжело сказать. Если у вас есть возможность, то скиньте сюда перечисленные заголовки, и тогда проанализируем, почему ESA выдала "DKIM aligned False".


С уважением,
Станислав.

Станислав,>>Поправьте меня,

Станислав,

>>Поправьте меня, если я неправильно вас понял.

Все верно. Ответ понятен, да и, честно говоря, уже разобрался.

 

>>Хотелось бы глянуть на оригинальное сообщение

Файлы вложил.

317
Просмотры
10
Полезный материал
7
Ответы
СоздатьДля создания публикации, пожалуйста в систему