Lesson 12: Implementing Secure Network Access Protocols Flashcards
Dynamic Host Configuration Protocol (DHCP)
provides an automatic method for network address allocation. As well as an IP address and subnet mask it can include optional parameters, such as the default gateway, Domain Name Server (DNS) address, DNS suffix, or NetBIOS name server address. This avoids the configuration errors that can occur if addresses are specified manually.
The key point about DHCP is that only one server should be running. DHCP broadcasts are typically limited to the local subnet. A router can be configured to forward the packets to another network (as is often the case with networks divided into separate VLANs, for instance). More than one DHCP server may be running for fault tolerance, as long as they are all configured correctly, and address pools don’t overlap. If a rogue DHCP server is set up, it can perform DoS (as client machines will obtain an incorrect TCP/IP configuration) or be used to snoop network information. There are various tools that can be used to detect rogue DHCP servers, including DHCPLOC for Windows® (https://gallery.technet.microsoft.com/DHCPLOC-Utility-34262d82) and dhcp_probe for Linux® (https://www.net.princeton.edu/software/dhcp_probe). Windows DHCP servers in an AD environment automatically log any traffic detected from unauthorized DHCP servers.
Another DoS attack against DHCP is installing a rogue client; that is, one that repeatedly requests new IP addresses using spoofed MAC addresses, with the aim of exhausting the IP address pool (DHCP starvation). It is possible to configure a DHCP server to bind only to known MAC addresses (DHCP Registration), but this is time-consuming and quite easily subverted, as it is trivial to harvest and spoof valid MAC addresses.
The best defenses against attacks on DHCP are accomplished by general network security best practices:
•
Use scanning and intrusion detection to pick up suspicious activity.
- Enable logging and review the logs for suspicious events.
- Disable unused ports and perform regular physical inspections to ensure that unauthorized devices are not connected via unused jacks.
- Enable DHCP snooping on switch access ports to prevent the use of unauthorized DHCP servers.
Domain Name System (DNS)
resolves host names and domain labels to IP addresses. It uses a distributed database system that contains information on domains and hosts within those domains. The information is distributed among many name servers, each of which holds part of the database. The name servers work over port 53. The distributed nature of the system has the twin advantages that the maintenance of the system is delegated and the loss of one DNS server does not prevent name resolution from being performed.
DNS spoofing
an attack that compromises the name resolution process. One use of DNS spoofing is to facilitate a pharming attack. In a pharming attack, the attacker compromises the process of DNS resolution in some way to replace the valid IP address for a trusted website such as mybank.com with the attacker’s IP address. The attacker can then receive all the packets directed to mybank.com at a malicious site, designed to fool the user into thinking it is genuine, with the intention of capturing credentials when the user attempts to authenticate. Alternatively, DNS spoofing could be used for a Denial of Service attack, by directing all traffic for a particular FQDN to an invalid IP address (a black hole).
DNS Cache/Hosts File
Before DNS was developed (in the 1980s), name resolution took place using a text file named HOSTS. Each name:IP address mapping was recorded in this file and system administrators had to download the latest copy and install it on each Internet client or server manually. Even though all name resolution now functions through DNS, the HOSTS file is still present and most operating systems check the file before using DNS. Its contents are loaded into a cache of known name:IP mappings and the client only contacts a DNS server if the name is not cached. Therefore, if an attacker is able to place a false name:IP address mapping in the HOSTS file and effectively poison the DNS cache, he or she will be able to redirect traffic. The HOSTS file requires administrator access to modify. In UNIX and Linux systems it is stored as /etc/hosts, while in Windows it is placed in %SystemRoot%\System32\Drivers\etc\hosts.
An attacker can also compromise a DNS client by performing a Denial of Service attack on the victim’s legitimate DNS server. The attacker could then use ARP spoofing to respond to DNS lookups from the victim network.
DNS server cache poisoning (or pollution)
another redirection attack, but instead of trying to subvert the name service used by the client, it aims to corrupt the records held by the DNS server itself. The intention is to redirect traffic for a legitimate domain to a malicious IP address.
A typical attack would proceed as follows:
- The server in grommet.com wants to find an address in widget.com. It queries the root and .com name servers and gets an address for the name server for widget.com.
- The attacker spoofs the name server for widget.com. To do this, the attacker must compromise the genuine widget.com name server through some sort of DoS attack. The attacker just needs to ensure that his or her malicious DNS responds to grommet.com’s queries before the legitimate one.
- The attacker spoofs responses to the grommet.com server and poisons its cache, meaning that traffic for widget.com from grommet.com gets directed to the attacker’s IP address.
Berkley Internet Name Domain (BIND)
Attacks on DNS may also target the server application and/or configuration. Many DNS services run on BIND (Berkley Internet Name Domain), distributed by the Internet Software Consortium (http://www.isc.org). There are known vulnerabilities in many versions of the BIND server, so it is critical to patch the server to the latest version. The same general advice applies to other DNS server software, such as Microsoft’s. Obtain and check security announcements and then test and apply critical and security-related patches and upgrades.
DNS footprinting
means obtaining information about a private network by using its DNS server to perform a zone transfer (all the records in a domain) to a rogue DNS or simply by querying the DNS service, using a tool such as nslookup or dig. To prevent this, you can apply an Access Control List to prevent zone transfers to unauthorized hosts or domains, to prevent an external server from obtaining information about the private network architecture.
You should also consider that DNS is a critical service that should be configured to be fault tolerant. DoS attacks are hard to perform against the servers that perform Internet name resolution, but if an attacker can target the DNS server on a private network, it is possible to seriously disrupt the operation of that network. Active Directory® (for instance) relies on DNS to work properly.
DNS Security Extensions (DNSSEC)
help to mitigate against spoofing and poisoning attacks by providing a validation process for DNS responses. With DNSSEC enabled, the authoritative server for the zone creates a “package” of resource records (called an RRset) signed with a private key (the Zone Signing Key). When another server requests a secure record exchange, the authoritative server returns the package along with its public key, which can be used to verify the signature.
The public zone signing key is itself signed with a separate Key Signing Key. Separate keys are used so that if there is some sort of compromise of the zone signing key, the domain can continue to operate securely by revoking the compromised key and issuing a new one.
The Key Signing Key for a particular domain is validated by the parent domain or host ISP. The top-level domain trusts are validated by the Regional Internet Registries and the DNS root servers are self-validated, using a type of M-of-N control group key signing. This establishes a chain of trust from the root servers down to any particular subdomain.
Cybersquatting
an attack where an adversary acquires a domain for a company’s trading name or trademark, or perhaps some spelling variation thereof. While there are often trademark and intellectual property laws against doing this, companies need to be careful to renew domain names that they want to continue to use and to protect the credentials used to manage the registration. A domain name must be re-registered every year.
following attacks all exploit the domain name registration process in some way:
- Domain hijacking—an adversary gains control over the registration of a domain name, allowing the host records to be configured to IP addresses of the attacker’s choosing. This might be accomplished by supplying false credentials to the domain registrar when applying for a new domain name or re-registering an existing one. An attacker might also be able to exploit the legitimate account used to manage the domain (via a weak password or RAT installed on a client computer) or even to compromise the domain registrar’s security procedures in some way.
- Typosquatting—misspelled domains can be profitable depending on the frequency that users enter the misspelled name (for example, visiting amazoon.com or amazun.com). This is also referred to as URL hijacking. Such domains can generate advertising revenue through Google™ or be used to host malware or launch pharming attacks.
- Kiting—a domain name can be registered for up to five days without paying for it. Kiting means that the name is continually registered, deleted, then re-registered.
- Tasting—this is the registration of a domain to test how much traffic it generates within the five-day grace period; if the domain is not profitable, the registration is never completed.
Simple Network Management Protocol (SNMP)
Apart from address allocation and name resolution, several other protocols are used in network housekeeping. Simple Network Management Protocol (SNMP) is a widely used framework for management and monitoring. SNMP consists of an SNMP monitor and agents.
• The agent is a process (software or firmware) running on a switch, router, server, or other SNMP-compatible network device.
This agent maintains a database called a Management Information Base (MIB) that holds statistics relating to the activity of the device (for example, the number of frames per second handled by a switch). The agent is also capable of initiating a trap operation where it informs the management system of a notable event (port failure, for instance). The threshold for triggering traps can be set for each value. Device queries take place over port 161 (UDP); traps are communicated over port 162 (also UDP).
• The SNMP monitor (a software program) provides a location from which network activity can be overseen. It monitors all agents by polling them at regular intervals for information from their MIBs and displays the information for review. It also displays any trap operations as alerts for the network administrator to assess and act upon as necessary.
If SNMP is not used, you should remember to change the default configuration password and disable it on any SNMP-capable devices that you add to the network. If you are running SNMP v1 or v2c, keep to the following guidelines:
- SNMP community names are sent in plaintext and so should not be transmitted over the network if there is any risk that they could be intercepted.
- Use difficult-to-guess community names; never leave the community name blank or set to the default.
- Use Access Control Lists to restrict management operations to known hosts (that is, restrict to one or two host IP addresses).
SNMP v3
SNMP v3 supports encryption and strong user-based authentication. Instead of community names, the agent is configured with a list of usernames and access permissions. When authentication is required, the SNMP message is signed with an MD5 (or SHA) hash of the user’s passphrase. The agent can verify the signature and authenticate the user using its own record of the passphrase.
SNMP v3 can also use DES or (in most products) AES to encrypt the contents of traps and query responses.
A query can be set to use no security (noAuthNoPriv), authentication only (authNoPriv), or authentication and encryption (authPriv).
Network Time Protocol (NTP)
Many applications on networks are time dependent and time critical, such as authentication and security mechanisms, scheduling applications, or backup software. The Network Time Protocol (NTP) provides a transport over which to synchronize these time dependent applications. NTP works over UDP on port 123.
Top-level NTP servers (stratum 1) obtain the Coordinated Universal Time (UTC) from a highly accurate clock source, such as an atomic clock. Lower tier servers then obtain the UTC from multiple stratum 1 servers and sample the results to obtain an authoritative time. Most organizations will use one of these stratum 2 servers to obtain the time for use on the LAN. Servers at lower tiers may then perform the same sort of sampling operation, adjust for the delay involved in propagating the signal, and provide the time to clients. Clients themselves usually obtain the time using a modified form of the protocol (Simple NTP).
Remote access
Remote access means that the user’s device does not make a direct cabled or wireless connection to the network. The connection occurs over or through an intermediate network, usually a public Wide Area Network. Historically, remote access might have used analog modems connecting over the telephone system or possibly a private link (a leased line). These days, most remote access is implemented as a Virtual Private Network (VPN), running over the Internet. Given that, administering remote access involves essentially the same tasks as administering the local network. Only authorized users should be allowed access to local network resources and communication channels. Additional complexity comes about because it can be more difficult to ensure the security of remote workstations and servers and there is greater opportunity for remote logins to be exploited.