Archive

Archive for the ‘Security’ Category

ASA version 9.0 released

October 30, 2012 5 comments

Version 9.0 of the Cisco ASA software has now been released. Here are some of the major features in the new release.

  • Filter ICMP by ICMP code
  • Clustering of multiple ASAs
  • OSPFv3 and EIGRP support
  • IPv6 support on outside interface for VPNs
  • NAT for IPv6 and NAT64
  • DHCPv6 relay
  • Unified ACLs for v4 and v6
  • Clientless SSL VPN – Support for new browsers and HTML5
  • Site to Site VPN in multiple context mode
  • Dynamic routing in multiple context mode
  • Mixed firewall support in multiple context mode

There seems to be some interesting features in here. If you are running v6
in your network this release seems much more useful. Also site to site VPNs
in multiple context mode is something that has been long overdue. It’s
also nice to see that you can run different firewall modes for each
context.

It was rumored that 9.0 was supposed to have BGP. I don’t see this mentioned
anywhere. I’m not sure if it got delayed or if they abandoned the idea but
some people like to run BGP on their firewalls. In my opinion it’s better
to keep a router for that but it wouldn’t hurt to have the option of running
BGP.

One thing that seems interesting is being able to cluster ASAs. I did not find
much information about this but it seems like the ASAs would be treated as
one logical unit. The difference to failover would be that you can use
the power of the multiple ASAs so if one ASA could inspect 100 Mbit/s you
should be able to inspect 200 Mbit/s with two of them. I’ll have to try
to find some more information on this feature.

Advertisements

Quick notes on Zone Based Policy Firewall (ZBFW)

February 15, 2012 3 comments

Continuing to check things off from the blueprint. Did some ZBFW labbing today. Here are some important stuff to be aware of.

ZBFW is basically a wrapper for CBAC. We create policys between zones and assign interfaces to zones instead of applying CBAC rules to interfaces.

By default all traffic to the self zone will be allowed (router from and to router itself). If we apply policys to self zone then everything is dropped except for the traffic that is explicitly permitted. We need to be aware of this to not mess with the routing if we get such a task at the lab.

The self zone can only inspect TCP, UDP and ICMP but not protocols like telnet and SSH. To work around this we can do a class-map matching an ACL AND the protocol TCP if we are matching telnet traffic.

It’s not very intuitive to see which traffic is dropped. We can turn on logging with ip inspect log drop-pkt. This helps a lot to see which traffic is being dropped.

ZBFW is massive in configuration, you will be typing a lot. It is easy to get confused and mix things. Name things intuitively, name class-maps CM_INSIDE_PROTOCOLS, name policy-maps PM_INSIDE_TO_OUTSIDE or names similar to that. If you don’t you will easily get lost after a while due to the massive config.

Packet counters for ZBFW can’t be trusted, this seems to be due to a bug. Verify by pinging or telneting to create traffic.

Use Notepad when creating the config, it is faster and less prone to errors.

All traffic flows are unidirectional so we need to create zone pairs for both directions depending if we want traffic to flow both ways.

We can have three different actions for traffic in the policy-maps.

Pass – Traffic gets through but not return traffic is permitted. Useful for “stateless” protocols like RIP
Inspect – Allow traffic through and also allow the return traffic back.
Drop – Drop the traffic

If we have a policy-map that allows some traffic through, the rest of the traffic not matching any class will be implicitly dropped, this is even if we don’t specify a class class-default.

That are the most important things you need to be aware of when configuring this feature.

Categories: CCIE, Security Tags: , , ,

AAA new-model – What does it do?

February 13, 2012 4 comments

To enable AAA we need the AAA new-model command but what does it really do? Many of us makes assumptions about this command.

By default if we have an empty config then we will be able to use the console and get straight into enable mode (priv15). If we try to telnet in (VTY) then we can’t login since no password has been set. If we set a password then we can login to priv 1 but we won’t be able to enable since no enable password has been set.

When configuring AAA we use method lists. We can use the list called ‘default’ or create our own. The sneaky thing about aaa new-model is that when we enable this the ‘default’ list goes active which is applied to the VTY. What surprised me is that this is not applied to the console. Someone had a theory that Cisco wanted to apply it to both console and VTY but too many users got locked out of their routers so they had to back on this implementation, true or not, I don’t know.

When aaa new-model has been enabled the device will ask for local authentication. If we haven’t defined any users then no access for you (VTY-nazi). Console will still work though, we will have to enable to enter priv 15 as usual.
Now if we define a user we will be able to login remotely as well, we do need to configure an enable password to get into priv 15 though.

For the lab I have seen that if people get a task with AAA they will create a new method list with no authentication and no authorization and apply it to the console and VTY. As I pointed out we should not have to enable this to the console but better safe than sorry I guess. This can be configured in the following way:

aaa new-model
aaa authentication login VTY none
aaa authorization exec VTY non
line con 0
login authentication VTY
authorization exec VTY
line vty 0 4
line authentication VTY
authorization exec VTY

How would you configure this, what do you do in real life? Post in comments.

Categories: CCIE, Security Tags: , ,

Quick post on IP applications

February 11, 2012 6 comments

I’m going through the blueprint and now I checked off IP accounting. The feature is very simple, it lets us see which source destination pairs that are sending traffic to each other. We can also configure to look what precedence values that are in the packets. There is also an option to look at the MAC-addresses of the packets passing through and also packets that are being denied by an access-list. The topology is dead simple, see below.

Configure your routing protocol of choice to get reachability. I’m using OSPF, it does not matter at all as long as you have connectivity. Now lets say that we are interested in which source and destination pairs that are sending traffic THROUGH the router (transit). Packets destined TO the router will not be seen in the accounting. I’ll configure accounting on R2’s interface to R1 and then initiate a ping from R1 to R3. I’ll send traffic both to the loopback and R3’s FastEthernet interface to see two different source/destination pairs.

OK, lets ping.

Now we will check the accounting database with the show ip accounting command.

So that shows us what sources/destinations are sending traffic to each other, interesting! We can also see the number of packets and number of bytes. If we want to check statistics for only certain hosts we can use the global ip accounting-list command to define what hosts we are interested in. We define hosts/networks as in ACL with network/wilcard combination.

Storing entries in the IP accounting database requires some memory, there could be a risk of exhaustion if we have too many entries but the default is set to max 512 entries. We can define this with the global ip accounting-threshold command.

So now we want to check what IP precedence values pass through our interfaces and also what MAC addresses that are sending/receiving traffic. Lets configure this.

Then we send some pings from R1, I will send with a ToS of 128, what IP precedence/DSCP is that? Think quick.

Lets verify at R2 if we see anything, the command to use is show interface precedence.

So a ToS of 128 was a IP prec of 4 but you already figured that, right? 🙂 What is that traffic with IP prec 6? Mysterious…We are running routing so that is OSPF which is marked with an IP precedence of 6 automatically by the router itself. We can also check what MAC addresses have been learned.

Here we also see OSPF represented by the MAC address 01-00-5E-00-00-05. We can also see when the last packet was sent which is quite handy. Now we will turn on accounting for access-lists as well, first we will define an ACL denying ICMP to 3.3.3.3 which is the loopback of R3. Note that we need the log keyword in the ACL.

Now we send traffic from R1 to 3.3.3.3.

For some reason I don’t see anything with the show ip accounting access-violations. Maybe this is a software issue? I tried turning off CEF as well. If any of my readers get this working I would be interested.

Lastly lets have a brief look at how traceroute works in IOS. Cisco devices uses UDP traceroute compared to ICMP used by Windows. The router sends packets with TTL of 1 and then N+1 the further away the probe goes. Traceroute sends three packets for every hop. The first hop will have a destination port of 33435, the second one will have 33436 and so on. If we want a router to not respond to traceroute we can turn off IP unreachables. Note that this will not hinder traceroute for which this router is not the final destination. Only the final device will send an ICMP unreachable (port unreachable) which is ICMP code 3. The other routers will send time exceeded which is ICMP code 11.

If we did want to block traceroute going through the router we could block this with an ACL denying packets that have ttl-exceeded or all packets lower than a certain TTL. If we need to find ICMP codes we can reference the ASA library. This should be available at the lab. You can find the reference by following this path.

Products > Security > Firewalls > Firewall Appliances > Cisco ASA 5500 Series Adaptive Security Appliances > Configure > Configuration Guides > Cisco ASA 5500 Series Configuration Guide using the CLI, 8.4 > Reference > Addresses, Protocols, and Ports > ICMP types

So this is just another feature that is handy to have.

Quiz – AAA authorization

December 18, 2011 6 comments

I’m doing the security section of Vol1 right now and this is something I think people might have confused. Look at the following configuration:

! Scenario 1
aaa authentication login default group tacacs+ none
aaa authorization exec default none
!
line console 0
privilege level 15
! Scenario 2
aaa authentication login default group tacacs+ none
aaa authorization exec default if-authenticated
!
line console 0
privilege level 15

Assume that the Tacacs+ servers are unavailable. What will be the result and what is the difference between scenario 1 and 2? Post your answer in comments.

Categories: CCIE, Security Tags: , , ,

Generate traffic with traceroute

May 28, 2011 6 comments

I found a very useful tool when practicing the INE labs. How to generate
traffic with traceroute. I’ve used telnet lots of times to generate TCP
traffic on different ports but what if we want to generate UDP traffic instead?
We can used traceroute to our advantage.

The topology is the one I’ve been using for my last posts with two routers
connected by a FastEthernet link.

First we create an access-list on R1 that will deny UDP on ports 9 and 19
but allow everything else.

We will confirm connectivity by doing a ping and then a telnet.

The traffic is passing successfully. Lets check the access-list on R1.

We have matches in the ACL, now lets generate traffic with traceroute.
We will type traceroute and then enter the options.

The important thing here is of course to change the port to something else
than the default port 33434. You can see by the !A in the answer that the
traffic was prohibited. Lets confirm this with looking at the ACL on R1.

And that is how you generate traffic with traceroute. Combined with the telnet
tool we can pretty much simulate most of TCP or UDP traffic. This gives us an
advantage in the lab so that we may test our ACLs to see that they are working
as expected.

Lock and key ACL

May 26, 2011 3 comments

The lock and key ACL is one of those features you’re not sure how to use in
production but it is viable for the CCIE lab. The lock and key ACL is a form of dynamic
ACL which requires a key before unlocking access. The lock and key ACL can only
have one dynamic entry per ACL.

We will be looking at a very simple topology with 3 routers. R2 will act as a
firewall for traffic coming from R1 going to R3. We will create an ACL that
denies telnet to R3’s loopback but allows everything else. We will run OSPF for
reachability but configuring it is out of scope for this post.

This is the topology.

All 3 routers have been configured with transit links and a
loopback address of 1.1.1.1, 2.2.2.2 or 3.3.3.3. All the magic
will occur on R2.

First we verify that we have reachability from R1 to R3 through
ICMP and telnet.

Reachability is good. Now we will start configuring the dynamic ACL on R2.

Lets try if we can telnet from R1.

As expected we can telnet to the Fa0/0 interface but not the loopback.

Now we need to create an user on R2 that will unlock the dynamic
ACE on R2. We also need to use the autocommand feature.

Now we have created the user and enabled the autocommand feature.
The autocommand will execute a command when the user logs in. The
enable-access feature is used to activate they dynamic ACE in the ACL.
We also need to enable local login on the VTY lines on R2.

Now we will login to R2 from R1 and see if we can telnet to R3.

After authenticating we get kicked out and the ACE has now been activated. We can now
telnet to R3’s loopback.

Lets look at the ACL on R2.

You can see that there is a dynamic entry allowing us to telnet to the loopback of R3.

So summarizing lock and key is a cool feature that is not very usable in real life but a
good tool to have on your lab exam.

You can download the configs, both initial and final and the .net file from here.
Don’t forget to set image dir and working dir.

Categories: CCIE, Security Tags: , ,