Thursday, December 26, 2013

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.

Or 

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 )

Or

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.




2:

Next define a class map that matches this ACL;




3:

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"



4:

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



Ken Felix
Freelance Network / Security Engineer
kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^
=(   $  $  )=
          o
       /     \

2 comments:

  1. FYI, Fortigate firewalls raise a red flag on these fortimail queries as well.

    ReplyDelete
  2. Searching for the Ultimate Dating Site? Create an account to find your perfect match.

    ReplyDelete