CCNA v3.0: Describe the impact of firewalls in an Enterprise Network (Part 1)


The CCNA v3.0 added a new topic; to describe the impact of firewalls, access points and wireless controllers in an Enterprise Network.

We will start by looking at firewalls today, and over a couple of posts, because there is a lot to them. Don't worry too much though as the exam syllabus lists this as a "describe", rather than a "configure". So there will only be a couple of questions on these in the exam.

We will cover access-points and wireless controllers together in a separate post (as it makes sense to do that).

What is a Firewall?

A firewall can be either software-based, or hardware-based, but pretty much all of them are based around a Linux kernel. No matter what the make or model, they all do pretty much the same thing, and that is to separate the host machine, or network, into zones.

Zones allow us to segregate the network into different security areas. We will be concentrating on the syntax for ASA firewalls, mainly, as these are Cisco devices, and so will probably be the main focus in the v3.0 CCNA exam.

You can try the ASA out on Packet Tracer, but these are the 5505 ones (so really down at the small-end of the scale), and the software version is really old. You are much better off, of you really want to play around with firewalls, by looking at UNetLab, or GNS3.

With the ASA we can assign names to an interface, the most common being "Outside", "Inside" and "DMZ". We will first look at the Outside and the Inside.

We can have more than one "Outside", if we have multiple connections to the Internet. The Outside is given a security level value, which is 0 by default. Our Inside interface will also be given a security level value, usually this is 100.

By default we can go from a higher level to a lower level, but not from lower to higher.


Once we set up a firewall, we will see this in action, but the important thing to note is that we will be able to get from the inside network to the Internet, but the Internet would not be able to get into us. Firewalls are stateful, meaning it knows what traffic is leaving it, and will allow the return traffic, but this also means that, without some specific rules, traffic cannot get in.

So, let's see this in action. This is our existing network:

CCNA v3.0 Firewalls - simple gateway

We have OSPF running through the network, and the Inside routers can reach the Internet (8.8.8.8):
Inside-1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/5 ms
Inside-1#

Inside-2#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/6 ms
Inside-2#
The Internet can also reach the inside:
Internet#ping 192.168.1.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/5 ms
Internet#
Clearly, this is not very secure. So, we will look at the impact of firewalls in an Enterprise Network, by swapping the Gateway router for an ASA, which gives us a network that looks more like this:

CCNA v3.0 - Impact of a firewall in an enterprise network
First of all, we will set up our basic IP address:
ASA(config)# int gi0/1
ASA(config-if)# ip add 192.168.1.1 255.255.255.0
ASA(config-if)# no shut
ASA(config-if)# 
Can we reach this from Inside-1?
Inside-1#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Inside-1#
No, we cannot. Let's assign the interface to the "Inside" zone, and see if that helps:
ASA(config-if)# nameif Inside
INFO: Security level for "Inside" set to 100 by default.
ASA(config-if)# 

Inside-1#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/6/12 ms
Inside-1#
So, now we have some measure of success, we can ping from Inside-1 to our ASA. We still cannot get any further, as we have not configured our Outside interface. Let's add this in:
ASA(config-if)# exit
ASA(config)# int gi0/0
ASA(config-if)# ip add 10.1.1.2 255.255.255.0
ASA(config-if)# no shut
ASA(config-if)# nameif Outside
INFO: Security level for "Outside" set to 0 by default.
ASA(config-if)# 
Instead of OSPF, we will set up some basic static routes for the moment:
Inside-1(config)#ip route 0.0.0.0 0.0.0.0 192.168.1.1
Inside-1(config)#

ASA(config-if)# route Outside 8.8.8.8 255.255.255.255 10.1.1.1
ASA(config)#end
ASA# ping Outside 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/10 ms
ASA#

Inside-1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Inside-1#
Now we can ping 8.8.8.8 from the ASA, but not from a host on the Inside. The Internet does not know about the 192.168.1.0/24 network.

With our Inside and Outside interfaces assigned, our network, logically, now looks like this:

CCNA v3.0 - Firewall security levels

Before we put the ASA in the network, we had full reachability between the Inside-1 and -2 routers and the Internet. We did this through OSPF, and the ASA is no exception - we can set up OSPF on our ASA:
ASA(config)# router ospf 1
ASA(config-router)# router-id 2.2.2.2
ASA(config-router)# network 0.0.0.0 0.0.0.0 a 0
ASA(config-router)# 
The adjacencies form, and the Internet can see the 192.168.1.0/24 network, and the Inside routers can see the 8.8.8.8 network, we just can't reach it:
Internet#sh ip route ospf | b Gate
Gateway of last resort is not set

O     192.168.1.0/24 [110/11] via 10.1.1.2, 00:03:53, GigabitEthernet0/0
Internet#

Inside-1#sh ip route ospf | b Gate
Gateway of last resort is not set

      8.0.0.0/32 is subnetted, 1 subnets
O        8.8.8.8 [110/12] via 192.168.1.1, 00:00:09, GigabitEthernet0/0
      10.0.0.0/24 is subnetted, 1 subnets
O        10.1.1.0 [110/11] via 192.168.1.1, 00:23:32, GigabitEthernet0/0
Inside-1#
Inside-1#ping 8.8.8.8             
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Inside-1#

Internet#
*May 29 14:54:10.377: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
*May 29 14:54:12.377: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
*May 29 14:54:14.377: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
*May 29 14:54:16.377: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
*May 29 14:54:18.376: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
Internet#
The logs above do show that the Internet is sending the reply back to the Inside-1 router. But it is not reaching it, because the return traffic is not permitted by the firewall. We need an access-list (ACL) to permit this.

Firewalls have Access-lists

We will start our access-list by permitting ICMP traffic:
ASA(config)# access-list outside->in extended permit icmp any any
ASA(config)# access-group outside->in in interface Outside
ASA(config)# 

Inside-1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/10/13 ms
Inside-1#
We can now reach the Internet from Inside-1, because we allowed ICMP (which is the protocol used by ping) to come back into the network. We can also telnet from Inside-1 to the Internet (because we are going from a higher-level interface to a lower-level interface):
Inside-1#telnet 8.8.8.8
Trying 8.8.8.8 ... Open

User Access Verification

Password: 
Internet>
Internet>exit

[Connection to 8.8.8.8 closed by foreign host]
Inside-1#
Our Telnet source port will be one of the higher ports, to the destination port of 23, but the return traffic will be allowed because we have a stateful firewall, therefore because the traffic is initiated from the Inside, the return traffic will be permitted. What we cannot do is initiate a connection from the Internet, to Inside-1:
Internet#telnet 192.168.1.10
Trying 192.168.1.10 ... 
% Connection timed out; remote host not responding

Internet#
We can amend our ACL to permit this traffic:
ASA(config)# access-list outside->in permit tcp host 10.1.1.1 any eq telnet
ASA(config)# 

Internet#telnet 192.168.1.10
Trying 192.168.1.10 ... Open

User Access Verification

Password: 

Inside-1>
Inside-1>exit

[Connection to 192.168.1.10 closed by foreign host]
Internet#
The 10.1.1.1 address is the source address on the Internet router, and "any" means any host on the Inside of our network. Until we added this last ACL rule, we were not explicitly denying the telnet traffic, but it was still denied. This is because ACLs have a default deny rule at the end of them, therefore any traffic that is not explicitly permitted, will be denied, by the implicit deny rule. It is implicit because it does not show up in the configuration:
ASA# show access-list 
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
            alert-interval 300
access-list outside->in; 2 elements; name hash: 0x307dc218
access-list outside->in line 1 extended permit icmp any any (hitcnt=1) 0x6d9415b4 
access-list outside->in line 2 extended permit tcp host 10.1.1.1 any eq telnet (hitcnt=1) 0x95b68c2a 
ASA# 
As you can see here, we have the two rules we added, but there is no rule stating that other traffic is to be denied, the rule exists, but we just can't see it, because it is implicit.

Firewalls and NAT.

Strictly speaking, we wouldn't be running OSPF straight from the ISP into our network. The RFC1918 addresses we use on our internal network are not routable on the Internet, and if you were to advertise a default route to the ISP, well, I am sure they would not be happy about it.

Therefore we will hide our network behind Network Address Translation (NAT):
ASA(config)# object-group network INSIDE-NAT-SUBNETS
ASA(config-network-object-group)# network-object 192.168.1.0 255.255.255.0
ASA(config-network-object-group)# exit
ASA(config)# nat (inside,outside) after-auto source dynamic INSIDE-NAT-SUBNETS interface
ASA(config)# 
Can we still reach the Internet?
Inside-1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/11/13 ms
Inside-1#

Internet#
*May 29 15:27:23.020: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
*May 29 15:27:23.032: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
*May 29 15:27:23.044: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
*May 29 15:27:23.057: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
*May 29 15:27:23.070: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
Internet#
We can, but now we are hidden behind the firewalls outside interface (10.1.1.2).

The takeaway from this post is that you cannot just run out, buy a firewall, plug it in, and expect it to work. At the very minimum you will need to add some access lists, and remember the default deny rule. You should always NAT your traffic as well. Because of the NAT we will not be able to telnet from the Internet router to 192.168.1.10, but we will look at how to fix this in the next part.

In the second part of this post we will also look at the role of the DMZ (Demilitarised Zone), and in the third part, we will look at the different modes a firewall can be in. So far we have been looking at a routed firewall (it has a layer-3 IP address). This is just one flavour of firewall, but is the most common, certainly the one you are most likely to encounter.


CCIE #49337, author of CCNA and Beyond, BGP for Cisco Networks, MPLS for Cisco Networks, VPNs and NAT for Cisco Networks.

Related Posts

Previous
Next Post »