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

       /     \

ipv4 ospf routing with OSPFv3

IPv6 ospf routing uses  a new process type known as  ospfv3. Their's a few differences between OSPFv2 and OSPFv3.

Primarily OSPFv2  has suppored ipv4  unicast,  and with MOSPF , we can also support ipv4 multicast routing.


With  OSPFv3,  we can also support both  ipv4+ipv6  unicast and multicast routing within these two common AFI.

I will demonstrate how you can accomplish ipv4 routing on a pair of cisco devices, using  OSPFv3.


Here's out topology;

The 6509 is configured for VRF so we have a simple vrf definition;

NOTE: We have two AFI defined but in reality I  only need  ipv4 unicast for this demo and just for  ipv4 unicast routing.


On the ASR we 1st define our  ospf -process #333 for ipv4  unicasting routing;

Very simple, we define a ospfv3 router instance with a unique process #. We must have one ipv4 address active for the RID. I made our process number match, but they do NOT have to match for ospf routing.

Next, we define our interfaces for the OSPFv3 process. This helps to eliminate the  BDR/DR selection process,  and speed up convergence.  I've built these point-2-point  interface as defined as p2p , in order to take advantage of this. In a multi-access lan, you obviously could not do this. So if you have more than 2 ospf routers on a common segment, then the ospf network-type will be of a broadcast type.

You may notice that I adjust the hello-interval to maxiumum value of 65535. This is a trick to reduce the number of hello that are process on a loopback interface. If you think about it, a hello interval of 10sec ( the default btw ) is useless on a interface that will never built adjacenies to another ospf router.

Okay so far this concludes the  ASR side of things.


The 6509 is configured almost identical, but we a  vrf definition due to we are in a VRF.

Okay now let's check out some of the ospfv3 show commands;

route-table

ospfv3 database

interface and neighbors

And now for a full interface show output;

1st the port-channel sub-interface;

notice I highlighted the ipv6 local EUI address. Yes you need ipv6 enable on the interface.


Now the  loopback interface  ;

notice I highlighted the ipv6 local EUI address. Yes you need ipv6 enable on the interface, & also the EUI address  has been computed for a loopback interface. Also we can see the hello/dead timers

A few Key points to keep in mind;

• OSPFv3 supports multiple  AFI  ( ipv4 unicast/multicast ipv6 unicast/multicast )
• No need to run a OSPFv2 process for ipv4 routing,  and a OSPFv3 process for ipv6 routing
• you can collaspe both AFI into one single OSPFv3 process
• It uses a ip6 link-local address for the ospf adjacenies
• you have to enable ipv6 under the interface
• OSPFv3 process #s are built globally
• You config the ospf process  under the  interfaces
• you must have ipv6 unicast-routing enabled globally , and regardless if you actually plan on routing ipv6 unicast prefixes
• the same show commands for  classic OSPFv2 are support in OSPFv3
• the ospfv3 database are similar but a few new LSA and changes are added with OSPFv3 routing
• most advance routers support this ( cisco IOS, IOS-XR, Juniper, Brocade )
• Juniper SRX firewall support multiple AFI , but cisco ASA, Fortinet and Checkpoints does not

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(   ^   ^  )=

          o

       /     \

A Juniper SRX and Fortinet Fortigate comparison

In this blog,  we will look at just  some of the  few differences between the Juniper SRX and the Fortinet  security appliances known as he  Fortigate , or  a.k.a FGT thru out this blog.

Both companies has a wide range of  firewall appliances,  and have a strong support within the ipv4/ipv6 security arena. I ‘ve been involved with both vendor for at least  9+ years now.  Fortigate hands down,  has a wider range of firewalls models from the smaller SOHO office type, to the big  Carrier class. They also have a wider  choices of security appliances than Juniper or Cisco.  This alone does NOT make them the best pick for all deployments, but could be factor in your evaluations between the 2 vendors. 

In any bake off, you should weigh the complete package,  from the cost per unit, port, features, post sales supports and any future requirements & integrations.

This  blog is not a who is better, but  more of a informational posting & from my personal experience and observations.

1:  Configuration committal

What this means, the SRX supports what’s called a configuration commit method for deploying changes. This approach allows for you to deploy and stage changes, and then commit the changes  at a later time if so desired.

Fortigate on the other hand, use a configuration tree and after you  exit the config branch of the  tree, your changes are committed.  There’s no on board committal scheduler.

2: Commit rollback

Commit rollback also goes to the SRX. You can rollback to a pre existing state or  previous life.  Great for change management and change controls.

FGT does not have this feature,  the best they have is a delay time to roll back to a previous configuration or a full config restoration which always  requires a reboot.

If you want configuration change controls and rollback, you will need to invest into a Fortimanager  appliance, which is another appliance &  at some extra cost.

3: IPV6 support and other advance supported features

IPv6 support goes to both models, but from my experience; “ the SRX has better support for routing  than the FGT”. They also incorporated more routing based features like DVMRP. And for layer security , 802.1x is also supported to some degree.

Please remember ;  “Juniper is a network routing company”.  So it makes for complete sense  that they have taken a stronger stances on IPv6 routing support, and other routing features, when compared to Fortinet.

On the other hand , Fortinet has always supported IPv6 for ages, and have numerous other  IPv6 features like  DHCPv6,  where as a SRX does not until just recently. Their advanced UTM  & application awareness features are a plus and included within the  appliance.

4: SSLVPN Support

The FGT supports SSLVPN on-appliance.  The Juniper approach is to buy a 2^nd appliance & just for SSL vpn terminations. This plain out sucks, but they are about making money.

5:  Integral Wireless Lan Controller

The Fortigate lineup outside of the smallest  FGT models, all  supports some type of integral WLC & with a limited support  number of APs and AP  wireless tunneling.  The Juniper SRX  supports wireless lan controls in the larger Branch Model  or  their bigger appliances & with an limited AP count.

6: Integral Wifi Interfaces

This feature goes to the FGT.  Fortinet has incorporated  within their  SOHO to the very  lower-end  models, some type of  Wifi Interfaces. These interfaces support a wide range of  SSID and  multiple security authentication modes. These same models also support fixed wired ports and cost slightly more, than the wired only models. So if you need a Dlink  type of  autonomous AP, but within a advance  firewall appliance, a Fortigate FWF model should not be over looked.

7:  Unix shell access

The  SRX support a unix shell. It allows for one to do a host of items such as;

• ·      Mount external format file systems ( thumb drives,  cdrom, external-floppies, etc…. )
• ·      The creation & execution of administration scripts
• ·      Writing packet captures  from the cli  using stand pcap expression
• ·      Md5/sha256 hash utilities
• ·      Xml outputs
• ·      Simple text editors vi /vim / ed
• ·      Snapshot creations
• ·      Common Unix  utilities  sed, awk, grep, egrep, cut, etc….
• ·      The Mounting  of  iso or nfs mounts points
• ·      manpages

The FGT does not have this option, and this pretty much sucks if your like me; “ a CLI junkie J  “

8:  Admin port access change

This is a big one for me personally. The FGT  let’s one easily change the  administration access ports for  both ssh, web, or telnet

( please don’t use telnet  access for managing a  security appliance J )

The SRX makes this task extremely hard or next  to impossible, & with out hacking around the inetd configurations other parts of the firewall filter configurations.

9:  MPLS  termination

The SRX supports  MPLS labeling with ease. I never fully recommend this for the average deployment, but if you need to terminate MPLS labels, you can do so with a  SRX. The FGT  lineup are  not MPLS aware, and this goes back to Juniper being a routing  company, and that  Fortinet  is a  security company.

10:  GRE tunnels  interfaces supports

Both model support the common GRE interface. A GRE interface is treat as another  interface ,  and allows for  fwpolicies, ip address,  and you can run routing protocols over these interfaces.

11: zones –based policies

 A SRX security  gateway uses the concept of zones only. Fwpolicies are built from one zone to another  zone. Where the Fortigate uses a port-based  fwpolicies. This means ; “ firewall policies are built from one port to another port ( interfaces ) “.

Keep in mind that the Fortigate does allow you to group  interfaces into a common zone , and then you can write fwpolicies  from a zone to another zone or a zone to another port, but this is not the normal default method

 ( see my earlier posting on my blog about the zones )

12:  Explicit Proxy  &  webtraffic inspections

I wanted to stay away from UTM advance features in this SRX  & FGT cook off , since the  Fortigate is way superior in this area. But I wanted to speak on the differences in that the  FGT has way better support for  webtraffic inspection and intercepts,  than what the SRX offers.

Once again within the SSLVPN support,  “ in the Juniper world, you have to buy a 2^nd components or add some type of license “.

They do have other application aware  features like AppSecure, but this  has been flaky across all platforms from my experience and is an additional cost and license to purchase. Just like with the cisco ASA,  everything on a SRX seems to be a license “ buy or add-on” .  The FGT appliance , is pretty much buy it, and turn  on what you need.

13:  ServerLoadBalancer supported VIPs

Load balancing VIPs,  with multiple back-ends , is  a serious plus in the Fortigate lineup. One might say; “ why not buy a server load balancer ? “  My answer to that ; “ not all load balancing requires a 2^nd  complex component for simple redundancy load balancing requirements”

Keep in mind the LB VIPs options in the Fortigate appliances, are very basic.  Your not going to write any iRule/aRules,  or do any complex responder policies in a Fortinet  FGT appliance.

If you need a true SLB, buy any of  well known SLB  from vendors like A10 networks, ServerIron,  Citrix, F5 or heck now that I think  of it; “ Fortinet has a load balancer”.

But if you need a simple load balanced VIP , an with simple health checks, the  FGT appliances does offer this feature in the firewall appliance.

14: Virtual  Firewalls Appliances

In the last 4 years or so,  Fortinet has been jumping on to VMware supported virtual firewalls bandwagon.  I myself , have not been a big fan of this approach, but it’s support , available  and they are making a strong stance in this area. The Fortinet sales team are pushing the virtual appliances more and more. And not just for demos.

15: Licensing

Yeah, my favorite subject. This is a 9 letter bad word in the  IT network arena, but we can’t avoid it.

The juniper SRX is based on a  license model &  for various features. The FGT is not for the most part . Outside of  vdom supports or licensing within the virtual firewalls appliances, you have pretty much  have no licenses or other restriction outside the matrix guides and limitations based on the size of the appliance.

16: WebGUI access

Both units has a WebGUI  interface.  The SRX  interface is slowly advancing , where as the FGT interface is slicker and way more advance. As a matter of fact, they have too much stuff in the WebGUI  ( imho ). So with the later Fortigate OS, you have the ability to select how much clutter you can display in the WebGUI and dashboards.

The Juniper WebGUI is also much slower than the speedier  Fortigate interface ( mho ). You can easily wait 1-2 mins for a committal ,  and changes in the Juniper Device manager interface, and this more relevant in the smaller units.

17:  The capacity for Interface Monitoring in real time 

Most FGT show commands are a one time executed,  and not real time by any means. The SRX allows for certain  interface monitor in real time , or delayed  intervals. I find this  useful when working with interfaces and look for changes, while debugging or diagnostics.

18: LLDP support

Yeap , the Juniper SRX has support  for LLDP &  over most physical interfaces. The Fortinet FGT appliances  is  LLDP un aware. This can be very helpful with diagnostics and debugging interfaces  & layer one or two issues.

19: ARP aging timers

The SRX support a per interface arp aging  timer, where as the FGT does not as of the latest codeset from Fortinet.

20:  WCCP Support

The SRX  does not support WCCP.  So what this means; “ your limited in the deployment options for redirection of traffic to a 3^rd party  webfilter/inspection engine”.

The Fortinet FGT has supported  WCCPv2  for ages  and  it works quite well in the bigger units. I personally seen issues with it dragging it’s feet or hanging in the smaller chassis platforms, YMMV.

I hope these 20 items,  helps you in your evaluation of these two superior firewall appliances.

 Happy Holidays from Ken @ socpuppets.

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(   ^   ^  )=

          o

       /     \