Ken Felix Security Blog: A cisco ASA breaking a fortimail ( why friends don't let friends, buy a cisco ASA )

If you remember my earlier blog on a cisco breaking something as simple as mail SMTPS.
http://socpuppet.blogspot.com/2013/12/a-cisco-asa-breaking-smtptls-security.html

Will the Adaptive Security Appliance raised it's ugly head again, and broke our Fortimail inspection queries to the fortiguard services. This is yet another example of why I try detour persons away from the cisco ASA security appliances.

Here's the problems;

While monitoring the Fortimail AS event-logs for a new installation, I found the fortiguard AntiSpam queries where going unsnswered. Here's a proper message that should have be seen in our logs;

here's a message, where we get no answer ( see the red highlighted circle )

For reference, you can validate this from the CLI by using the following diagnostic command;

e.g

Fortimail01 # diag fortiguard rating ip 58.254.168.76
ip: 58.254.168.76, score=-1, Unknown

Here we used a known spammer that should provided a spam score.
Do you notice the score =-1 and status unkown?

And this address is included in a few RBLs at the tine of this post.

Okay here's the problem caused by the wonderful ASA appliance;

!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512

and it's applied to our global policy, under the class inspection_default;

policy-map global_policy

class inspection_default

inspect dns preset_dns_map <------LOOK HERE

inspect ftp

inspect h323 h225

inspect h323 ras

inspect ip-options

inspect netbios

inspect rsh

inspect rtsp

inspect skinny

inspect sqlnet

inspect sunrpc

inspect tftp

inspect sip

inspect xdmcp

inspect pptp

inspect ipsec-pass-thru

inspect icmp

inspect icmp error

inspect http

inspect snmp

inspect esmtp STARTTLS

class class-default

inspect pptp

user-statistics accounting

service-policy global_policy global <----LOOK HERE

Okay, how did I guess this was the problem?

Easy, the FortiGuard AS queries are DNS related. Since the ASA is inspecting DNS queries and response, it was safe to assume this could be a contributing factor to our problem.

Okay, how do we confirm?

We remove the service policy. Re-test and monitor the fortimail AS event-logs. Now using that same spam source-ip_addres & with the service inspection policy removed we get the following rating;

e.g

Fortimail01 # diag fortiguard rating ip 58.254.168.76

ip: 58.254.168.76, score=1, Spam

Wow a big difference. You can also cross reference this to senderbase for a 2 opinion from a different collective; http://www.senderbase.org/lookup/?search_string=58.254.168.76

Okay, now what I found that was very interesting?

The lookup from the Fortimail is being hampered by the cisco ASA inspect mechanism.

So we will have to build a pcap, and also diesect the query to see if we can negate this with a match NOT statement in our service policy later on.

We can disable dns inspect entirely on the cisco ASA until a resolution has been found ( not good since all dns inspection would be ineffectively removed and open you up for other possible dns attacks )

Other options would be to strike the service global policy and apply a interface specific policy for all other interfaces except the one our fortimail sits at. In my case this unit sit in a an external DMZ

Or

change the configuration to use a different query port

Or

Bypass the inspection for DNS traffic to/from the fortimail

I selected the later and will demostrate below on how you can do the same

What I found that was even more interesting & more disturbing ;

Queries to a barracuda RBL are not being hampered at all. You can see this via the following screenshot from our unix host command

So this tell me that the Fortimail queries are not be honored within the cisco ASA inspect policy. Maybe cisco is sabotaging the fortimail on purpose :)

Here's how you can bypass the inspect dns within the ASA, and traffic to/from your Fortimail Appliance.

1:

1st we craft a bypass ACL that defines the host ( fortimail ) and dns-server(s) that you don't want inspection for.

Next define a class map that matches this ACL;

Okay, now we re-arrange the service-policy and ensure that it's enabled globally. The ordering of the class-map comes before the generic class-default & we removed the inspect dns from the class inspection-default"

Lastly, we monitor via the command line that all is working , by querying a known bad and good source address;

& validating using a known blacklisted address

5:

We monitor the logs for any Fortiguard AS rating scores errors

note1: If the cisco ASA inspection was still bad & breaking the fortimail, output would have mimic the above earlier output of "unknown"

note2: I didn't install the fortiguard specific servers, since fortinet could in deed change these address

note3: I also trust all DNS query to any sources for any other DNS queries that our fortimail addpliance might query.

You can learn more about fortiguard antispam here;

http://www.fortiguard.com/static/antispam.html

scoring 1 thru 9 with 1 being worst and 9 better