Cisco ESA to 3rd Party DLP Integration

[yohannugera]

Hi,

As per the customer requirement, we need to offload DLP checking on Cisco ESA to a 3rd party DLP solution (McAfee).

To test the scenario, we've created a sample mail box in customer's exchange. In Cisco ESA, I've configured a new outbound policy to match all the mails coming from this mailbox (by sender). In content filters, I've created few rules as requested by McAfee DLP team.

1. To forward all mails coming from exchange servers to DLP (Conditions: remote-ip!={DLP IPs}, Action: set-altn-dst=={DLP VIP}

2. To forward all mails with a x-header to outside (action is taken as per the header value, so created few content filters)

Overall, the mail flow should look like this.

Outlook Email Sender --> Exchange Server --> IronPort ESA --> NDLP --> IronPort ESA --> Internet

But, even if we do like this, the traffic sent from IronPort ESA to DLP was not visible from DLP end. Saying, DLP end cannot find any emails coming from the IronPort ESA. We've taken a tshark (like tcpdump) on McAfee DLP server and found that the traffic is hitting from ESA's public IP.

So,  the traffic is getting NAT-ed from the next-hop firewall. But, both Cisco ESA and DLP are in the same LAN. Now we have few questions to be answered.

1. Why the traffic is routed to the next-hop even if the remote-ip in same LAN?

2. Is this the Cisco recommended way of implementing a 3rd party DLP (or any other solution) since the same mail is traversing through Cisco ESA twice?

[marc.luescherFRE]

Hi there,

a few things to consider or new ideas:

a) instead of using Conditions: remote-ip!={DLP IPs}, Action: set-altn-dst=={DLP VIP} we are using alt-host as the action and have a defined SMTP route from our ESA to the DLP appliances

b) it would be helpfull if you can identify a clear message header or new SMTP X-header when a message was processed by the DLP appliance and is clear to go.

c) did you define any default routes in the ESA to the next hub

d) for smaller installation it makes sense to do such a DLP bypass as you had planned, for larger installation we would use at least 2 SMTP listeneres on two ports or even two appliances once for inbound and one for outbound.

I hope that helps

-Marc

[yohannugera]

Hi Marc,

Thank you for the input. Actually, test mail flow to the DLP is working at the moment.

But, we're having an issue with the return email flow. As you've pointed out, we've configured a header to get attached to the return email. The action needs to be taken by Cisco ESA is set as the value in that header.

Now the issue here is, we've configured a Bounce Verification profile in Cisco ESA. So, it rewrites all outbound email sender address. So, when the DLP return the email, it returns with the sender as this rewrited sender. So, as it doesn't match with the actual sender and the Cisco ESA is unable to correlate previous mail with this, we're unable to notify the end-user regarding DLP action (whether it's being blocked or bounced).

Did you encountered with the same issue? Do you have an idea on how to resolve the issue without removing the bounce verification profile from Cisco ESA?

Regards,

Yohan Nugera.

[Mathew Huynh]

Hey there,

Your filtering rule seems fine; if coming from a sender for example ,set alt-mailhost to your McAfee DLP.
McAfee DLP should be sending it back, so you will need to have a a sendergroup for McAfee DLP IP + RELAY beahviour and also message filter or so setup where if the email is injected by McAfee DLP IP, skip all scanners and filters (you may need to put in an extra content filter as well to skip remaining filters if coming from McAfee DLP to avoid having a mail loop).

Then it should relay out the internet for final delivery without double handling.
Now the issue of McAfee seeing the traffic from ESA's public IP.

I assume you have more than one IP interface configured; if so you can also put in your initial content filter that is routing to McAfee DLP to use the right interface (as to avoid the NAT rule if it's choosing the wrong interface). This is the Deliver from IP interface content filter action.

Regards,
Mathew

[yohannugera]

Hi Matthew,

Actually, both Cisco ESA and DLP were in different LANs. So that's why it got routed to the next-hop. Anyway, it's fixed now.

We're having an issue with DLP to ESA mail flow. All return emails have a prefixed part (which were added by Cisco ESA as per the bounce verification profile).

For example: if Cisco ESA receives an emails from test@testcompany.com, it rewrites its sender like pvrh=133525=xx=test@testcompany.com.

Is there a way to remove bounce verification process for single?

Regards,

Yohan Nugera.