Below I list the units within the CCNP ENCOR course that cover these specific topics. Keep in mind however that the lessons on the site do not correspond directly on a one-to-one basis with the blueprint:
5.5.a Threat defense 5.5.b Endpoint security
Both threat defense and endpoint security as general concepts can be found in the lessons under Section 8.1 Device Access Control.
Based on the above, I will talk to Rene and see if we can âfill in the gapsâ in some areas. Thanks so much for bringing these topics to our attention!
Isnât this a mistake? I thought that we move servers to the DMZ if we need them publicly available to the internet, yet the highlighted sentence says that traffic from the outside to the DMZ is denied, so no one can really initiate connections to it
Rene said the following - "Instead of blocking all IP addresses that belong to lolcats.com, you can create a filter that looks for the URI in HTTP requests ". My question is, how exactly is this accomplished if the protocol thatâs being used is HTTPs? This means that the payload and the L7 data are encrypted, so the firewall shouldnât be able to decrypt it, or is there a workaround to this?
What are some reasons to have a router in addition with a firewall? From what Iâve read, firewalls can perform routing, NAT, have IPSec tunnels configured, and even support BGP. So what are some reason to have both a firewall and a router and not just use the FW instead?
These are all excellent questions, and they show that you are not just accumulating information in your mind, but youâre learning to think analytically and gain not just knowledge but understanding as well. Way to go! Now on to your questions.
Based on the behavior of a firewall, by default, the security levels of the INSIDE, DMZ, and OUTSIDE interfaces will always be HIGH, MEDIUM, and LOW, respectively. This results in the permission and denial that Rene states in the lesson, so that is correct. So why is traffic from OUTSIDE to DMZ denied? This is simply the default behavior. Once this is done, you must then use access lists that will permit ONLY traffic to the IP addresses and port numbers of your servers. We donât want the outside world to have free access to all of the DMZ subnet by default. You may have servers or other devices running in the DMZ that donât need to be accessible from the OUTSIDE. So, any servers you want to be accessible from OUTSIDE must be specifically and explicitly permitted. This is simply ensuring that you are allowing access only to those IP addresses that really need it. Everything else is denied by default.
Reneâs statement is true for HTTP, however, HTTPS encrypts the entire HTTP message, including the request URI, headers, and payload. So such filtering is not possible. Of course, the IP address and the port numbers remain outside of the encryption, so those can be used. Is there a workaround to use the FQDN for filtering in a firewall? Yes, there are some possible workarounds.
One would be to use the firewall as a âman in the middleâ proxy that will perform deception, read the URI, reencrypt, and send it to its intended destination. This, however, can become complex, process intensive, and could create problems with certificates and authentication. It is possible, but it can be difficult and prone to many issues.
The Server Name Indication (SNI) in the TLS handshake can be read in an HTTPS exchange, and it reveals the hostname of the requested website. FWs can use this to allow or deny access based on domains, but they canât inspect the full URI or the payload. However, not all TLS sessions reveal the SNI. Newer TLS features such as Encrypted Client Hello (ECH) hide the SNI, making this method less reliable.
There are additional more intricate and technical methods that you can research that are way beyond the scope of this lesson. But the question is still a good one and can lead to a whole other area of learning.
Indeed, firewalls can perform most, if not all, of the functions of an edge router, so why not just deploy a FW and not an edge router? For smaller networks, it is preferable, both financially and for simplicity, to deploy a single device at the network edge that performs all required functions. But for larger networks, it is preferable to separate those roles. There are several reasons for this:
Share the load - By separating roles, we are sharing the memory, CPU, and network resources across multiple devices, allowing for scalability. Security filtering, NAT, routing, and IPSec VPNs can be very resource-intensive, so putting all of that strain on a single device not only creates a single point of failure but can cause an increase in latency and possible packet loss.
Use devices for what they were designed for - Firewalls are designed with a focus on security, while edge routers are designed with a focus on routing. Unavoidably, a firewall is better (more efficient, more reliable, more feature-rich) at security features while a router is better (more efficient, more reliable, more feature-rich) at routing.
For larger mission-critical networks, itâs better to separate the roles for redundancy, increased efficiency, better performance, and more features in each area of employment.
Share the load - By separating roles, we are sharing the memory, CPU, and network resources across multiple devices, allowing for scalability. Security filtering, NAT, routing, and IPSec VPNs can be very resource-intensive, so putting all of that strain on a single device not only creates a single point of failure but can cause an increase in latency and possible packet loss.
However, wouldnât this mean that the firewall would need to be configured in some sort of L2 mode? Because I donât know what the default configuration is, but isnât routing enabled for them by default? Which means that they would also have to route the traffic from and towards the router if we decided to use two separate devices.
When separating the roles of routers and firewalls using dedicated devices, the firewall does not necessarily need to operate in Layer 2 mode. A common deployment involves the router handling WAN/ISP connectivity, BGP/OSPF, and external routing, while the firewall in routed mode manages security policies, NAT, VPNs, and internal routing. Traffic typically flows through the router first before reaching the firewall. And if you use static routes for the firewall, you can alleviate any dynamic routing processing overhead as well while ensuring proper traffic flow between devices.
Modern firewalls, such as Cisco ASA and Firepower, do support two primary modes: routed mode (Layer 3) and transparent mode (Layer 2).
Routed mode is the default for most firewalls, allowing them to act as routers with security policies, NAT, and VPN capabilities. In this mode, all interfaces require IP addresses, and the firewall participates in routing.
Transparent mode, on the other hand, functions as a âbump in the wire,â preserving existing Layer 2 domains and IP addressing while enforcing security policies without the need for âre-IPâingâ networks.
Which you will use depends on your design and your requirements.
Transparent mode (Layer 2) is best used in scenarios where existing IP addressing cannot or should not be modified, a firewall needs to be inserted into a network without reconfiguration, or simple Layer 2 filtering is required, such as bridging two segments of the same subnet.
In terms of scalability and high availability, separating roles between routers and firewalls helps distribute resource usage more efficientlyârouters handle BGP and other routing protocols, as well as QoS policing, shaping, and possibly infrastructure ACLs while firewalls manage IPSec VPNs and NAT. By separating roles, and by duplicating each device (i.e. two firewalls and two routers) redundancy is also improved by implementing high-availability (HA) pairs, such as ASA Failover for firewalls and VRRP/HSRP for routers, reducing single points of failure.
So even if a firewall is required to perform routing, it can still share the load in terms of what mechanisms it will deploy.
