Ken Felix Security Blog

In my attempt at trying to write a more specific route-policy for ospf route rejection, I ran across a interesting things that I would like to point out, & that deals with IOS-XR specifically.

Our main goal; " was to filter routes being injected via a a few down stream ospf speakers, and to prevent the possible corruptiing our route table ".

In order to filter these ospf routers advertisements, a simple distribute list was attached to our interface using the following route-policy;

and the corresponding prefix-sets where defined ;

here's our new route-policy that's more specific & looks good ;

Now if one would try to apply this to our distribution in interface we get the following error and the configuration is rejected;

It's strange that cisco IOS-XR behaves in this manner. You can craft a route-policy that pass the parser, but one can not use at the attach point. Since IOS-XR is trying to duplicate what's already been done via other router OSes, I found this error quite interesting.

1: In classic traditional IOS, one could easily build the same using a route-map

2: And in Junos one could easily build the same, by using a import policy

Be advised, none of these methods will drop the LSA from entering the ospf database.

Stay tune, as I research more into this strange behavior and for alternatives means at ospf filtering.

Ken Felix

Freelance Network / Security Engineer

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

^ ^

=( ^ ^ )=

/ \

Why friends, don’t let friends buy cisco ASA J

The ASA security appliance is one of the most common firewall in use by a lot of enterprise networks, but can be one of the most frustrating unit on planet earth. It has been the root of a lot of problems, both performance related and inspection related. It's also very pricey for the performance that the ASA chassis provides and encompass a whole slew of license restrictions.

Here’s the problem;

1: I’ve spent approx 3 days trying to debug why my fortimail 3000D didn’t allow for TLS on inbound mail connections

2: All of my test showed that TLS was disabled when testing from the outside

3: TLS was enable within the webGUI of the Fortimail AS/AV appliance

4: I never thought of testing from the inside and validating any differences in behavior ( I was single focus in that it was the fortinet Fortimail appliance since it was quite new )

5: Fortinet TAC gave me the ideal of using the exec smtptest 127.0.0.1 command locally on the fortimail ( I’ve always used it from an external testing, never realized we had a listener on 127.0.0.1:25/tcp )

6: Looking at the problem, I suspected the FortiMAIL was the culprit, but it turned out to be our choice of firewall and it’s inspection features ( cisco ASA )

7: Other fortimail appliances that I managed & that works great, are not behind a cisco ASA security appliance

How can the Adaptive Security Appliance ( aka ASA ) & with it’s wonder inspection features, actually weaken a security feature for mail, does not make any sense.

Sadly, this problem with the cisco ASA, & with it dis-allowing a common security function ( TLS encryption for mail ), is just down right disturbing. Adaptive my ASS!.

The ASA in my dictionary, means AnotherSorryAppliance !

Moving on, let’s look at the diagnostics & the issues encountered;

Using the mxtoobox against the public facing address of my fortimail appliance, which is operating in gateway mode we get the following;

http://mxtoolbox.com/diagnostic.aspx

and with out the inspect esmtp enabled on the ASA we get the following;

]

So now what?

Why did this failed when the inspection policy was enabled in the global policy?

My initial suspicions where; that the ASA was inspecting the EHLO output between the client ( mxtoolbox ) and the server ( Fortimail 3000D ) twice, and this is causing the problem with the ASA fixing up the commands between the two parties. But this was not the case.

A side by side comparison when using telnet show you what the ASA is doing ( leftside was done locally and right remotely )

It really boils down to the cisco ASA is masking the EHLO reply & the command options it was presenting to the remote client.

So how do we remediate this?

What first take a look at the follow cisco link about inspect to get an understanding of what the purpose of the XXX;

http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_configuration_example09186a008064730a.shtml

You could easily disable esmtp inspection, but that would allow for bad things to happen to your mailserver if something bad where too actually happen

a DoS attack
the handling of non ESMTP or SMTP commands
exposing your mail banner
etc………

Here’s how socpuppets fixed & remediated the problem, and for allowing the fortimail security appliance to actually support TLS encryption.

1: we had to change the inspect esmtp to use a custom profile.

2: in this inspection, we allow for TLS

"allow-tls"

3: we apply this profile to our inspect esmtp statement

4: and then re-test and monitor

Now after the above changes, any with our follow up testing; " we can easily see that STARTTLS is now indeed working ".

So any external mail clients that want to provide encryption, can easily do so & the ASA will not strike the support for STARTTLS option in the reply.

We can also issue the show command to monitor statistics or use debug esmtp to see our inspection in action.

( sample debug output )

SMTP: Initial state:10

SMTP: EHLO REPLY - Reply len:15, match_len:15, reply_re_state:0

SMTP: REPLY DONE - eid: 19

SMTP: State changed to:10

SMTP: Initial state:10

SMTP: EHLO REPLY - Reply len:74, match_len:74, reply_re_state:49

SMTP: EHLO REPLY - match id:41