Sunday, April 18, 2010

CBAC in Action, Part 2

In my previous CBAC post I covered how to deny all external traffic unless it is in response to a request someone on the LAN has made, e.g If you send a ping, CBAC will allow the ping reply traffic to come through the firewall.

However, this situation may not be ideal for everyone. What if you wanted to allow one or more protocols in to your network but still have the security that CBAC provides? For example, if you wanted a contractor to be able to SSH in to your network any time, day or night? I will show you how using the same topology as last time (except you will see that R3 has been renamed to SSH Source). Our goal is to allow R3 to SSH in to R2 without being blocked, while still blocking R4 (hacker) completely.

If you recall, our inbound ACL on R1 looks like this:

ip access-list extended DENY_IN

deny ip any any

So if we try to SSH in from R3 now, we should fail, which we do. See the output below:

R3#ssh -l cisco 192.168.0.2
% Destination unreachable; gateway or host down

However, if we add the following line to the ACL:

ip access-list extended DENY_IN
!!Allow SSH traffic in to the network if its source address is 10.10.10.2 and it is destined for 192.168.0.2
permit tcp host 10.10.10.2 host 192.168.0.2 eq 22
deny ip any any


We should now be able to SSH in to R2 from R3, which we can:

R3#ssh -l cisco 192.168.0.2

Password:

R2>

But just to make sure that all of our security measures are still enforced, lets try to ping from R3 to R2:

R3#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
R3#

And let's also try to SSH in from R4 (hacker):

R4#ssh -l cisco 192.168.0.2
% Destination unreachable; gateway or host down

R4#

As you can see from the above two tests, even though R3's SSH traffic can get through to R2, its ping traffic cannot. And you can also see that R4's SSH traffic cannot get through at all. This is because the new ACL entry specifically says that only SSH traffic sourced from R3 and destined for R2 is allowed to enter the network.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

CBAC in Action, Part 1

In a previous post I talked about CBAC and a few of the ways in which it, in conjunction with NBAR can be used to secure your network. Today I will create a lab to show you how to put it to good use.

In this lab we have four routers, R1, R2, R3 and R4 (very original I know). Here are there designations:

  • R1 = Local LAN - Your network
  • R2 = Core - The core of your network and your internet connection
  • R3 = Ping Destination - A location you want to ping to
  • R4 = Hacker - A hacker that is trying to access your network


Now in order to protect the network we need to apply access lists and CBAC rules to the interfaces which are connected to untrusted networks. As per the diagram, this would be interface Fa0/0 and Fa1/0.

At present there are no security measures in place, so as per the example below, R3 (the ping destination) can successfully ping R2:

R3#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/57/100 ms
R3#

And, R4 (the hacker) can also ping R2:

R4#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 416/469/528 ms
R4#


And of course, R2 can ping both R3 and R4.

Now, to stop these external users (R3 and R4) from being able to communicate with R2, we will need to put inbound ACLs on R1's interfaces which connect to them - (Fa0/0 and Fa1/0). An ACL that denies all traffic will do the trick:

!!Create the ACL
ip access-list extended DENY_IN

deny ip any any
!
!!Apply it to the interface connected to R3
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
ip access-group DENY_IN in
!
!!Apply it to the interface connected to R4
interface FastEthernet1/0
ip address 10.50.50.1 255.255.255.0
ip access-group DENY_IN in

As per the below output, R4 is now unable to ping to R2:

R4#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
R4#

However, this also means that if R2 tries to ping R3 or R4, the ping will be unsuccessful because the returning traffic will be blocked by the incoming ACL:

R2#ping 10.10.10.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
R2#

This is obviously not ideal. To resolve this issue we need to create a CBAC rule which will watch our outgoing traffic and then create dynamic ACL entries at the top of our existing ACL to allow the return traffic to get back in to the network.

The following commands need to be entered on R1:

!!Create the CBAC rule to keep track of ICMP traffic
ip inspect name CBAC_OUT icmp
!
!!Apply it to the interface connected to R3
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
ip access-group DENY_IN in
ip inspect CBAC_OUT out
!
!!Apply it to the interface connected to R4
interface FastEthernet1/0
ip address 10.50.50.1 255.255.255.0
ip access-group DENY_IN in
ip inspect CBAC_OUT out

As per above, R3 and R4 are still unable to ping to R2:

R4#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
R4#

But we can now ping to them from R2:

R2#ping 10.50.50.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.50.50.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/121/192 ms
R2#

To view the temporary ACL entries that CBAC creates, perform a ping from R2 to R3 and then issue the "show ip inspect sessions" command on R1:

R1#show ip inspect sessions
Established Sessions
Session 664FD9A4 (192.168.0.2:8)=>(10.10.10.2:0) icmp SIS_OPEN

As you can see by the output of the above command, only ICMP traffic destined for the IP address that issued the ping command is allowed back in to the network, no other traffic. And, once the pings stop the temporary ACL entry is removed.

R1#sh ip inspect sessions

R1#

We have now successfully secured the network. External users are unable to send data to us unless we request that they do. In this example it was a ping reply but it can also be returning traffic from a HTTP server, FTP server, telnet session, SSH session, SIP call, etc.

For more information on CBAC or to see a more advanced CBAC configuration, please see my CBAC in Action, Part 2 post.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Get Involved - Fourms

Whether you are are a seasoned Cisco professional or just starting out, one of the best sources of information you will find (apart from this blog :P) are internet forums. You will be amazed at just how much you can learn from them, and, if you have the time, how much you can teach others too. It is also a great place to "network" (excuse the pun).

Forums that I frequently visit include:
  • Whirlpool Forum - An Australian forum that covers everything from VoIP to Network to PC Hardware.
  • Experts Exchange Forum -Like Whirlpool, "EE" covers a whole range of topics and has a reward system that encourages users to assist one another.
  • Cisco Forum - An excellent place to get assistance with your Cisco problems.
If you're having a problem and you just can't seem to resolve it, I can almost guarantee that someone on a forum will be able to help you (I speak from experience after having used the above mentioned forums). Everyone is so helpful and because most users are Cisco professionals there is nothing they have not seen before.

Forums also give you the confidence to try new things. For example, if you are interested in implementing a VoIP solution but you do not know the first thing about it, you can jump on to a forum and get the latest, most up-to-date information on prices, technologies and implementation methods with the push of a couple of buttons. They also gives you a sense of re-assurance because you know that if you don't understand something or if you get stuck, there are users on line who are ready to help 24 hours a day, 7 days a week.

You will find that some forums (including the ones mentioned above) not only allow you "chat forums", they also have other resources including Knowledge Bases or Frequently Asked Question pages which in themselves are a great source of information.

Once you do get your problems resolved it is always a good idea to stick around and assist others who are having trouble with their networks too. It is a great feeling when you know you've helped someone fix their problems and it is a great way to keep your knowledge fresh instead of letting it fade away in the back of your mind.
So if you are not part of a forum I strongly suggest you sign up today. You won't regret it!

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Saturday, April 17, 2010

CBAC Firewall

In my last post I mentioned the Cisco IOS firewall feature known as CBAC (Context-Based Access Control). Today I will describe it in more detail and explain how you can use it to increase the security of your network.

As you may know, a firewall is used to protect your network from the outside world and all of the nasty hackers out there. With each passing day hackers' intrusion techniques are become more advanced and highly complex, and unfortunately basic ACLs are simply not good enough to protect you anymore. Thankfully CBAC (more commonly known to the wider I.T community as Stateful Packet Inspection, (SPI)) has come to the rescue.

CBAC, with the help of NBAR, reads the packets coming in to and going out of your network and creates dynamic ACL entries that will either permit or deny these traffic flows.

For example, if you want to allow ICMP and HTTP traffic (pings and internet browsing) out of your network, you would have to create an "outbound" access list on your internet facing interface. Then, to allow the returning traffic to re enter your network you would have to create an "inbound" access list, however, this is where your potential troubles start. This is because unless your "inbound" access list specifies all of the IP addresses that you intend to ping to or surf to, you are going to have to allow all ICMP and HTTP traffic in to your network, regardless of the source,which is not very secure.

Fortunately, as mentioned above CBAC has come to the rescue. With its dynamic ACL creations all you have to do is create the "outbound" access list which specifies what your users can and cannot do and CBAC does the rest. This is because CBAC watches the traffic that leaves your network and then creates a dynamic ACL to allow the returning traffic (and only the returning traffic) back in to the network.

See my CBAC in Action and CBAC in Action, Part 2 posts to see a real life example of how you can configure CBAC in your network.
As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Friday, April 16, 2010

NBAR and its Many Uses

Overview 

NBAR, also known as Network Based Application Recognition is an invaluable tool that many people do not know exists or simply just don't use it enough. 

As the name suggests, NBAR reads packets that flow through a router and "recognises" the types of applications that are sending the packets. Examples of applications that can be recognised include:

  • FTP
  • Kazaa
  • HTTP URL Addresses
  • Bit Torrent
  • Many, many more!
And the good news is that this handy little feature can be put to use in many different ways, some of which I have discussed below.  

NBAR & Access Control 

Before NBAR came along, one of the techniques Network Administrators woulduse to stop users from getting up to mischief was blocking "bad" ports. However, with a little bit of know how it is very easy to change ports thereby making the "bad" traffic look like legitimate traffic. By using NBAR you don't need to specify port numbers, you just specify the application that you would like to block, apply it to an interface and you're done. Because NBAR reads the packets (up to, and including Layer 7 information), it is still able to block the traffic even if the users change their port numbers.

Note: NBAR can be used in conjunction with Context-Based Access Control (CBAC) to create an extremely effective firewall on a Cisco router. 

NBAR & URL Filtering

NBAR can also be used to block URLs. This can be a great little feature if you have a small office setup and do not have the time or the resources to set up a proxy server.

The filtering also allows you to use wildcard masks so blocking websites with multiple sub-domains (such as YouTube) can be done just as easily as blocking a single domain. 

NBAR & QoS

Another application for NBAR is with QoS policies. Rather than specifying port numbers for different traffic types, NBAR will automatically identify the port numbers for you. This is a small gain I know, but it makes life a little easier. It also makes your config somewhat more readable in that instead of creating a class-map and ACL that specifies TCP port 80 and 23, you can use NBAR to match "HTTP" traffic and "Telnet" instead.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Wednesday, April 14, 2010

GNS3 + Real Cisco Gear

For those of you who have never heard of GNS3 before, you are in for a treat!

What it does is allow you to run multiple routers on your computer in a virtualised environment, and, because it uses real Cisco IOSes you are not limited to a short group of commands as you are when using simulators, you actually have access to the entire command tree as if the IOS was put on a real router.

At risk of stating the obvious, this is a huge asset for anyone who is interested in networking. Whether you are a network engineer, studying for a certification or just an enthusiast, this application is perfect for you.


Another big advantage is the amount of money it can save you. Rather than spend a couple of hundred dollars on a router, using GNS3 you can simply whip up one, two, ten or more in an instant! Imagine the complex topologies you could create with that!

Now I know you must be thinking "this is too good to be true", and, when something is too good to be true it usually is, so I will let you in on one (very small) piece of bad news. GNS3 is unable to emulate switches. That is because switches do most of their work in hardware ASICs whereas the routers that GNS3 emulates do most of their work in software. Speaking of which, this leads me to my next (very small) bit of bad news. GNS3 is not able to support every single router released, however, to its defence, it does support a large number of them. For information on both of these downfalls, see the FAQ page.

Now, back to the positives. Although GNS3 cannot emulate switches, some of the routers it supports do support ethernet modules, so if you really want to test your Layer 2 skills in GNS3 you could always set up a few routers with switching modules and away you go.

And for those of you out there with existing labs, this post relates to you too! Why you ask? Because you can connect your physical equipment to your virtual lab. As you will see in my future posts, you are able to create a complex Layer 3 network in the virtual network and then connect it to your real router, switch or multi layer switch, then connect PCs to your switches so they become part of the network too. Amazing!!

So, if you haven't seen or used GNS3 yet I suggest you download it and give it a go, you won't be disappointed.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Tuesday, April 13, 2010

Welcome!

Hello and welcome to my blog.

I know what you are thinking, "not another Cisco Blog!", but this one will be different, I promise :)

The point of this blog is to patch up the holes that other blogs/websites leave in the information that they provide. While researching topics in the past, I have found on more than a few occasions that some sites fail to fully explain what it is they are talking about (whether it be a protocol, QoS, troubleshooting, etc) and by the end of it I am left scratching my head and feeling like I know less than I did before I found the site.

So with this in mind I am going to explain each topic I discuss in great detail to ensure that this sort of thing does not happen to my readers. Having said that though, I do not plan to re-invent the wheel. If there is a great resource out there that will assist me in explaining a topic, I will gladly link to it and perhaps expand on it if need be.

In addition to writing, I will also use real labs to further help me explain the subjects that I cover, and I will also include screenshots, packet captures and running-configs to further explain how the whole thing came together.

Anyway, that's all for now folks! Stay tuned and I hope you enjoy your stay!!

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.