In part 1, we saw the effect of putting a firewall into an enterprise network. If you have not read that post then please read it before reading this one, otherwise somethings may not make sense. In the post we saw that we can go from higher-level interfaces to lower, but not from lower to higher, and this is all about the trust we put in our zones.
In this part, we will add a DMZ to our network, and explain why we do this. We will also fix the network so that the Internet router can telnet into our network, but will be confined to the DMZ. Before we do this though, let's go back to a little theory and discuss the difference between stateful and stateless firewalls.
Stateful vs. Stateless firewalls
Our ASA is a stateful firewall. Stateful firewalls keep a connections table, and this is the users traffic. We can look at the traffic in a number of ways, just on the source and destination (layer-3), or we can go all the way up to layer-7 and include the protocol, and the ports being used.Stateless firewalls (which were the first type of firewall) just perform packet filtering, and are more like extended access lists. There is less intelligence with stateless firewalls. Each request is treated separately to the response. So we need to be much more careful with stateless firewalls, and make sure that for each outgoing ACL (Access List), we have one to allow the return traffic, instead of the stateful firewall, which adds more intelligence, and will dynamically allow the return traffic, if the return traffic is part of an existing outgoing connection.
We saw this in the previous post, where we could telnet from Inside-1 to the Internet router, and the connection was set up, the return traffic was allowed through because of the stateful nature of the firewall. The firewall could see that the outgoing connection was set up, and the response was matched to this connection entry.
Before we added NAT, we could allowed the incoming telnet connection (originating from the Internet router), because we knew exactly who Inside-1 was. We then implemented NAT, which hid Inside-1 behind the external IP address of the ASA (10.1.1.2). Now, with NAT, the Internet router will not be able to telnet directly to the Inside-1 router, as the ASA will not know to which host the traffic is destined for. For this to work we would need to add another NAT rule, giving Inside-1 an external address, which can then be used by the ASA to correctly direct the traffic. However, this is really not the best design. Incoming connections should be directed to a DMZ (Demilitarized Zone), which adds another level of security to the network. So let's do this now.
DMZs
DMZs allow us to accept incoming connections, but keep them separated from our LAN. These get their own security level (0 by default, like the Outside). If we add this to our network, it starts to look like this:
We have another router hanging off the ASA, and this will get a security level of 0, as we can see if we set it up:
ASA(config)# int gi0/2 ASA(config-if)# ip add 172.16.1.1 255.255.255.0 ASA(config-if)# no shut ASA(config-if)# nameif DMZ INFO: Security level for "DMZ" set to 0 by default. ASA(config-if)# security-level 50 ASA(config-if)# DMZ(config)#int gi 0/0 DMZ(config-if)#ip add 172.16.1.10 255.255.255.0 DMZ(config-if)#no shut DMZ(config-if)#exit DMZ(config)#ip route 0.0.0.0 0.0.0.0 172.16.1.1 DMZ(config)#end DMZ#ping 172.16.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 2/2/3 ms DMZ#Notice that I have set a security level of 50. Security levels are all about trust. Our internal network got a security level of 100 (we trust it a lot), the Internet got a security level of 0 (we really don't trust it), but we do trust the DMZ, just not as much as the internal network, so we can set it to 50.
The next step is to allow the Internet router to telnet to the DMZ router. To do this we need to add another NAT rule to forward traffic from an address in the 10.1.1.0/24 network (10.1.1.100), to the DMZ router (172.16.1.10), and permit the traffic:
ASA(config)# object network obj-DMZ ASA(config-network-object)# host 172.16.1.10 ASA(config-network-object)# exit ASA(config)# ASA(config)# object network obj-DMZ-External ASA(config-network-object)# host 10.1.1.100 ASA(config-network-object)# exit ASA(config)# ASA(config)# nat (DMZ,Outside) source static obj-DMZ obj-DMZ-External ASA(config)#Notice that I have not actually added an ACL to permit this traffic. This is because we actually added one that permits this traffic in the previous post:
ASA(config)# access-list outside->in permit tcp host 10.1.1.1 any eq telnet ASA(config)#As such we do not need to add one to permit traffic coming from the outside to the DMZ. But we did need to add the NAT rule. For more information on NAT, pick up the CCNA and Beyond study guide from Amazon, there are a lot of NAT exercises in there.
We can see that this works by telnetting from the Internet router to the IP address 10.1.1.100, and we can also see the hit count on the ASAs ACL increase:
Internet#telnet 10.1.1.100 Trying 10.1.1.100 ... Open User Access Verification Password: DMZ>exit [Connection to 10.1.1.100 closed by foreign host] Internet# ASA# sh access-list outside->in access-list outside->in; 2 elements; name hash: 0x307dc218 access-list outside->in line 1 extended permit icmp any any (hitcnt=0) 0x6d9415b4 access-list outside->in line 2 extended permit tcp host 10.1.1.1 any eq telnet (hitcnt=2) 0x95b68c2a ASA#Returning to the NAT rule we set up, instead of referencing IP addresses, we used objects.
Firewall objects
Working with objects makes life much easier. We can group related services (such as HTTP and HTTPS) into one object (such as calling it "WEB-Traffic"):ASA(config)# object service WEB-Traffic ASA(config-service-object)# service tcp destination eq http ASA(config-service-object)# service tcp destination eq https ASA(config-service-object)#We can now reference this in our NAT or ACL statements, and this makes reading the configuration much easier (and keeps things cleaner). The downside to this is that it becomes harder to match ACL hits to an individual endpoint. If you have ten hosts within an object and a thousand hits on the ACL, it's hard to see which of these hosts are actually receiving the traffic. But this is just one of those things that you learn from as you go.
NAT order of operations
Before we leave this post we should return to a bit of theory, and look at the order of operations that a Firewall goes through as traffic comes in, or goes out.The actual order of events is fairly similar, but changes depending on the direction of the traffic.
The Cisco doc here, outlines all the steps taken. We can test this within the ASA itself though, using the packet-tracer command (I have truncated the output a bit to make it a little more readable):
ASA# packet-tracer input inside tcp 192.168.1.10 telnet 10.1.1.1 telnet detailed
Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.1.1.1 using egress ifc Outside
Phase: 2
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (Inside,Outside) after-auto source dynamic INSIDE-NAT-SUBNETS interface
Additional Information:
Dynamic translate 192.168.1.10/23 to 10.1.1.2/23
Forward Flow based lookup yields rule:
input_ifc=Inside, output_ifc=Outside
Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: QOS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (Inside,Outside) after-auto source dynamic INSIDE-NAT-SUBNETS interface
Additional Information:
Phase: 7
Type: QOS
Subtype:
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
Phase: 8
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
Phase: 9
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
input_ifc=Outside, output_ifc=any
Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
Module information for reverse flow ...
Result:
input-interface: Inside
input-status: up
input-line-status: up
output-interface: Outside
output-status: up
output-line-status: up
Action: allow
ASA#
The above is for traffic leaving the network, going from 192.168.1.10 to 1.1.1.1. In Phase 1, we look to see if we have a route to the destination, and this gives us our "egress" interface. In Phase 2, we perform NAT, mapping our inside subnets to our external interface's IP address (10.1.1.2). Because the type of NAT we are using is PAT (and again pick up CCNA and Beyond to understand more about PAT), this is setup and allowed in Phase 4. Phase 5 passes, because we have not implemented QoS (Quality of Service). Phase 6 is an additional check, called Reverse Path Forwarding, which means that we check to make sure that the reply to the traffic is going to come back through the interface we sent the original request out of. This helps eliminate routing loops, and general traffic weirdness. We have more QoS in Phase 7, which again passes, and we move on to Phase 8. Here we again set up NAT, but for the return traffic, you can tell this because it is for the "Reverse Flow". We have not set any IP options, so Phase 9 passes, and we move on to Phase 10. Here the flow is created, and we see that everything has worked.Let's look at traffic coming in now.
ASA# packet-tracer input outside tcp 10.1.1.1 telnet 10.1.1.100 telnet detailed
Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (DMZ,Outside) source static obj-DMZ obj-DMZ-External
Additional Information:
NAT divert to egress interface DMZ
Untranslate 10.1.1.100/23 to 172.16.1.10/23
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside->in in interface Outside
access-list outside->in extended permit tcp host 10.1.1.1 any eq telnet
Additional Information:
Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (DMZ,Outside) source static obj-DMZ obj-DMZ-External
Additional Information:
Static translate 10.1.1.1/23 to 10.1.1.1/23
Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: QOS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (DMZ,Outside) source static obj-DMZ obj-DMZ-External
Additional Information:
Forward Flow based lookup yields rule:
out id=0x7fb295a33350, priority=6, domain=nat-reverse, deny=false
dst ip/id=172.16.1.10, mask=255.255.255.255, port=0, tag=any, dscp=0x0
input_ifc=Outside, output_ifc=DMZ
Phase: 8
Type: QOS
Subtype:
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
Phase: 9
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
Phase: 10
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 41, packet dispatched to next module
Module information for forward flow ...
Module information for reverse flow ...
Result:
input-interface: Outside
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: allow
ASA#
The first step is to work out where the traffic is really supposed to go to, so in Phase 1 we un-translate 10.1.1.100 to 172.16.1.10. We then confirm that the traffic is permitted, and find a matching ACL in Phase 2. In Phase 3 we see that we are not doing any translation (or un-translation) on the source address of 10.1.1.1. In Phase 4 we allow the NAT, and again in Phase 5 and 6, because we do not have any IP options or QoS, the traffic is allowed. We again make sure that the traffic going out will match the interface that it came in on, by performing an RPF-check in Phase 7. In Phase 8 we pass the QoS, and in Phase 9 we set up the per-session NAT. Phase 10 passes because we have not set any IP Options, and in Phase 11 the flow is created.So here you can see the difference between incoming and outgoing traffic, where NAT is concerned.
Whilst most of this is probably beyond the needs of the CCNA exam, this is the kind of skills you should pick up as you study. It will certainly help solidify knowledge of other areas.
In the next section of this series we will discuss the different modes a firewall can be in, and these are routed (as we have seen here), transparent, and multi-context.
5 comments
commentsAlthough I appreciate the level of detailed information you have provided here, the topic does not seem to relate to this stuff. I feel it is more related to the impact of firewalls on networks by comparing the added security to performance overhead and bottlenecks created by firewalls.
ReplyAt the CCNA level it would not go into that depth, actually none of the Routing and Switching exams through CCNP and CCIE would go into that depth. Performance and bottlenecks would be something you would see in the design exams, more specifically the CCDE. I have done the CCDA and CCDP and performance overhead and bottlenecks did not come up in those.
ReplyHaving looked at some CCDE questions, that would be the kind of thing that comes up, but I really don't think that it would appear in the CCNA.
Me too I was beginning to wonder, is that CCNA level stuff??? Too taught for CCNA.
Replyremove the email window u dumb faggot don't force me to subscribe
ReplyQuite frankly, if you are that rude, and cant find the "close" button, I really would not want you to subscribe anyway.
Reply