cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1730
Views
0
Helpful
3
Replies

Cisco ESA - DHAP still useful?

tminchin
Level 1
Level 1

Just a question - do people still find the DHAP (Directory Harvest Attack Prevention) still useful? We've had it on for years but in the last couple of months had two major "denial of service" of email due to DHAP triggering and causing way more harm than actual good.

Scenario 1 - a person works at one institution and forwards email to us for a few years. She then ceases her secondment at our organisation and we cancel her account. The forwarding from her original account continues and the emails are not accepted by LDAPACCEPT - they are using Mimecast and they start to generate hourly "not delivered year emails" which are also attempted to be forwarded to us (to be not accepted by LDAPACCEPT and in turn generate warning emails from Mimecast). Eventually due to one persons forwarded email we end up having DHAP triggerring on Mimecasts Australian email cluster and most of the Australian university sector and other customers can't email us anymore (until we manually disable DHAP).

Scenario 2 - Outlook.com cluster (16000 IP addresses - I extracted them myself) all have low reputation due to some malware which creates free accounts and then sends malicous emails with URLs to email addresses (many out of date). This is what the Cisco TAC told us anyway. This triggers DHAP and the malicous content also lowers the reptuation. Eventually again we have to manually disable DHAP to allow all the genuine freemium email in from Outlook.com hosted email (Hotmail.com/Outlook.com/Live.com etc) as again customers can't contact us.

 

I can see how DHAP is useful if there is a server which is wholy malicious in nature - but when you have multi tenancy IP addresses sending you email (and their admins don't seem to care about deliverability) it seems to be somewhat dangerous to the quality of your email service.

3 Replies 3

Mathew Huynh
Cisco Employee
Cisco Employee

Hey,

 

DHAP i believe is very useful still for protection; but there will always be some servers which does poor setup and triggers your DHAP and could potentially be a 'loss in business' due to this behaviour - it's not on you but the sender as you shared; who do not care about deliverability.

 

DHAP alerts etc; are very limited so it should not have any real impact there.

When we do reject with LDAPACCEPT or RAT - we don't generate any emails so there shouldn't be extra load - we will send the 5XX code to the sender - it should be the senders responsibility to do the NDR.

 

Thanks,

Mathew

tminchin
Level 1
Level 1

Rejecting on LDAPACCEPT/RAT isn't so bad resource wise.

 

However with DHAP however what happens is that it only takes a certain number of LDAPACCEPT failures (ie 20 in an hour is the Cisco ESA default for DHAP) and then the entire Senderbase group of mail servers is denied access for an hour.

 

So all it takes it takes for someone to stop email from *.outlook.com mail servers is to send our ESA's a single email of address to our organisation with email addresses which are invalid (say 200 which are the right domain name but not in LDAP) which then triggers DHAP and an SMTP 4xx. Outlook.com servers then try to send it over and over again which continually triggers DHAP - meanwhile legit email is blocked from Outlook.com servers as they can't get delivered. In the end we had to turn off DHAP and in this case capture it with a filter to see what it was.

 

So you can see why I'm feeling it might be bit of a feature which has past it's use by date. Especially for multi user systems.

Hey there,

 

I definitely do understand that - but that's the risk of solutions which are multi-tenanted where deliverability to external servers is probably an after-thought in some cases.

 

In your circumstance - should this be an ongoing issue you could always create a new sendergroup just for the O365 servers where DHAP is switched off but still have DHAP overall.

 

Nevertheless - please do ensure your configuration you have is built for your needs; in which it seems you're already one step ahead there :).

 

Thank you for your insights thought - i believe this will help the other users of the Cisco Secure Email solution.

 

Cheers,

Mathew