In this video, we'll cover some ways that an IT Support Specialist can implement network hardware hardening. We talked about general network hardening, and now we're going to dive deeper into more specific tools and techniques for hardening a network. We'll pay close attention to features and options available on networking infrastructure hardware. In an earlier lesson on networking, we explored DHCP. It's the protocol where devices on a network are assigned critical configuration information for communicating on the network. You also learned about configuring DHCP in another course of this program. So, you can see how DHCP is a target of attackers because of the important nature of the service it provides. If an attacker can manage to deploy a rogue DHCP server on your network, they could hand out DHCP leases with whatever information they want. This includes setting a gateway address or DNS server, that's actually a machine within their control. This gives them access to your traffic and opens the door for future attacks. We call this type of attack a rogue DHCP server attack. To protect against this rogue DHCP server attack, enterprise switches offer a feature called DHCP snooping. A switch that has DHCP snooping will monitor DHCP traffic being sent across it. It will also track IP assignments and map them to hosts connected to switch ports. This basically builds a map of assigned IP addresses to physical switch ports. This information can also be used to protect against IP spoofing and ARP poisoning attacks. DHCP snooping also makes you designate either a trusted DHCP server IP, if it's operating as a DHCP helper, and forwarding DHCP requests to the server, or you can enable DHCP snooping trust on the uplinked port, where legitimate DHCP responses would now come from. Now any DHCP responses coming from either an untrusted IP address or from a downlinked switch port would be detected as untrusted and discarded by the switch. Let's talk about another form of network hardware hardening, Dynamic ARP inspection. We covered ARP earlier from the how does it function standpoint. ARP allows for a layer to men-in-the-middle attack because of the unauthenticated nature of ARP. It allows an attacker to forge an ARP response, advertising its MAC address as the physical address matching a victim's IP address. This type of ARP response is called a gratuitous ARP response, since it's effectively answering a query that no one made. When this happens, all of the clients on the local network segment would cache this ARP entry. Because of the forged ARP entry, they send frames intended for the victim's IP address to the attacker's machine instead. The attacker could enable IP forwarding, which would let them transparently monitor traffic intended for the victim. They could also manipulate or modify data. Dynamic ARP inspection or DAI is another feature on enterprise switches that prevents this type of attack. It requires the use of DHCP snooping to establish a trusted binding of IP addresses to switch ports. DAI will detect these forged gratuitous ARP packets and drop them. It does this because it has a table from DHCP snooping that has the authoritative IP address assignments per port. DAI also enforces great limiting of ARP packets per port to prevent ARP scanning. An attacker is likely to ARP scan before attempting the ARP attack. To prevent IP spoofing attacks, IP source guard or IPSG can be enabled on enterprise switches along with DHCP snooping. If you're an IT Support Specialist at a small company that uses enterprise-class switch hardware, you'll probably utilize IPSG. It works by using the DHCP snooping table to dynamically create ACLs for each switchboard. This drops packets that don't match the IP address for the port based on the DHCP snooping table. Now, if you really want to lock down your network, you can implement 802.1X. We've added details about how to configure this in the supplementary reading. But for now, let's discuss this at a high level. It's important for an IT Support Specialist to be aware of 802.1X. This is the IEEE standard for encapsulating EAP or Extensible Authentication Protocol traffic over the 802 networks. This is also called EAP over LAN or EAPOL, it was originally designed for Ethernet but support was added for other network types like Wi-Fi and fiber networks. We won't go into the details of all EAP authentication types supported. There are about 100 compatible types, so it would take way too long. But we'll take a closer look at EAP-TLS since it's one of the more common and secure EAP methods. When a client wants to authenticate to a network using 802.1X, there are three parties involved. The client device is what we call the supplicant. It's sometimes also used to refer to the software running on the client machine that handles the authentication process for the user. The open source Linux utility wpa_supplicant is one of those. The supplicant communicates with the authenticator, which acts as a sort of gatekeeper for the network. It requires clients to successfully authenticate to the network before they're allowed to communicate with the network. This is usually an enterprise switch or an access point in the case of wireless networks. It's important to call out that while the supplicant communicates with the authenticator, it's not actually the authenticator that makes the authentication decision. The authenticator acts like a go between and forwards the authentication request to the authentication server. That's where the actual credential verification and authentication occurs. The authentication server is usually a RADIUS server. EAP-TLS is an authentication type supported by EAP that uses TLS to provide mutual authentication of both the client and the authenticating server. This is considered one of the more secure configurations for wireless security, so it's definitely possible that you'll encounter this authentication type in your IT career. Like with many of these protocols, understanding how it works can help you if you need to troubleshoot. You might remember from Course 4 that HTTPS is a combination of the hypertext transfer protocol, HTTP, with SSL-TLS cryptographic protocols. When TLS is implemented for HTTPS traffic, it specifies a client's certificate as an optional factor of authentication. Similarly, most EAP-TLS implementations require client-side certificates. Authentication can be certificate-based, which requires a client to present a valid certificate that's signed by the authenticating CA, or a client can use a certificate in conjunction with a username, password, and even a second factor of authentication, like a one-time password. The security of EAP-TLS stems from the inherent security that the TLS protocol and PKI provide. That also means that the pitfalls are the same when it comes to properly managing PKI elements. You have to safeguard private keys appropriately and ensure distribution of the CA certificate to client devices to allow verification of the server-side. Even more secure configuration for EAP-TLS would be to bind the client-side certificates to the client platforms using TPMs. This would prevent theft of the certificates from client machines. When you combine this with FDE, even theft of a computer would prevent compromise of the network. We're covering a lot of complex processes right now, so feel free to watch this video again so that the material really sinks in. If you're really interested in implementing these processes yourself or want to dive into even more details about how it all works, check out the supplementary readings for this lesson. Keep in mind, as an IT Support Specialist, you don't need to know every single step-by-step detail here. Knowing what these processes are and how they work can be very beneficial while troubleshooting and evaluating infrastructure security. When you're ready, I'll catch you on the next video.
