Book Excerpt: Advanced Network Design, Chapter 4: Infrastructure
Security does not happen by accident. Sure, a crashed router will keep hackers (and everyone else) out of your network, but in most cases if you want security along with functionality, you have to make a conscious effort to make things secure. Most estimates will tell you it’s 20 to 30 times more expensive to fix a bug in a delivered piece of software than it is to address or prevent that bug in the design stage. The cost to “fix” a lack of security in a design can be much, much higher when you take into account the potential for lost revenue, productivity, data loss, customer loss, and so on. One of greatest areas for risk and reward when it comes to security investment is in the network infrastructure—how you design and secure the infrastructure of your organization can have a tremendous impact on the survivability and security of your organization.
CERTIFICATION OBJECTIVE 4.01
What should you learn next?
Advanced Network Design
Security is a process—you can’t “buy” absolute security, as much as many of us would like to. It simply does not exist. Security is also a constantly moving target. As your business needs change and technologies change, so must your approach to security and the steps you take to secure your infrastructure. Security is often at odds with the needs of the business. Employees want access to data any time, from any place, and using any platform they are able to get their hands on at the time. So how does one go about securing an organization facing this type of challenge? A good place to start thinking about and planning for security is in the design and implementation of your network infrastructure. A good network design can absolutely help in your quest to secure and defend your network and critical resources. The other upside is that a secure network design can also have performance benefits and benefit business continuity efforts.
Remote Access
In the reality of the modern work environment, the concept of a static workspace with a phone, network jack, and desk is essentially dead. Many organizations have whole-heartedly embraced the idea of a truly mobile workforce that can work any time from anywhere. All they need are their laptops/tablets/smartphones and network connectivity. It’s a great model for efficiency and productivity, but it’s not a great one for security. Each of those mobile employees must be able to reach back into the organization for e-mail and access to data/resources. Some of those employees are connecting from home whereas others are connecting from hotels, coffee shops, airport lounges, and so on. The question security practitioners need to ask is how do you allow employees to connect from any place with multiple platforms and still maintain some semblance of security? Fortunately, there are steps you can take to design and implement a more secure remote access solution.
Segmenting remote access traffic is an important step in the design of your infrastructure. Most organizations treat remote access traffic as potentially hostile and do not allow remote access traffic to come directly into the internal network. One approach is to accept remote connections at the VPN/access gateway, decrypt the traffic there, and then pass the traffic through a firewall and IDS/ IPS configuration, as shown in Figure 4-1. This allows for the filtering of remote access traffic (do remote users really need access to port 1433 or 3306?) as well as monitoring of the traffic for suspicious or malicious activity. Although, in theory, anyone making a successful connection to your VPN infrastructure is “legit,” there’s nothing wrong with keeping an eye on their activity, particularly if you’re looking to protect yourself against infected or compromised hosts. Segmentation also gives you a control point to restrict or reject all remote connections if necessary.
FIGURE 4-1 Segmentation of remote access traffic
Another common security practice is to verify the patch and antivirus (AV) status of any host that connects to the VPN network. For example, Microsoft’s Network Access Protection product can help control a client computer’s access to organizational resources based on whether or not that client meets the defined corporate policy. Is the client fully patched? Is it running an approved AV product? Is that AV product up to date with the latest signatures? If a connecting client is not in compliance, you can bring that client into compliance before allowing it to connect. Remote clients may not be routinely scanned and updated and should be checked before being allowed to connect to any internal resources.
Another topic that should be examined in your design is the use of token-based or multifactor authentication. Although by no means perfect, token-based or multifactor authentication systems can add one more layer of complexity to deter and thwart potential attackers. Some organizations shy away from these solutions due to the extra cost and complexity associated with tokens, biometrics, and so on. Your design must take all these factors into account and weigh the risk against the cost to see if deploying something beyond the traditional user ID/password in your remote access solutions is right for your organization.
Placement of Security Devices
Security practitioners universally agree that security devices are needed to help secure and defend a network from the nearly constant onslaught of hostile Internet based traffic. Where practitioners differ in their opinions is where security devices should be placed and in some cases how many of those devices should be deployed. When examining the design of your network and considering the placement of security devices, you must consider many different factors: What are you protecting? What type of traffic are you filtering? How much traffic will be encrypted? What volume of traffic can you expect?
Placement of security devices must take several factors into consideration, such as the purpose of the device, its own survivability, and at what point you want this device to interact with the network traffic. Generally speaking, security devices can be placed either at the network border or internally, both of which provide important security benefits. Using security devices both internally and at the border is an important part of a defense-in-depth strategy. Consider the very simple network shown in Figure 4-2. Here, we’ve shown four different locations where you could consider placing a security device such as an IDS/IPS or firewall. Each location greatly affects what traffic can be seen by security devices, what traffic they can filter/control, and so on.
Security devices placed at the network border serve to keep malicious traffic out and to prevent sensitive information from leaving the network. Your first line of defense at the network border should be a firewall. Better security can be achieved by using two firewalls—an outward facing stateless firewall with a separate stateful firewall immediately behind it. Place intrusion prevention (or detection) systems immediately behind your firewall where they can see all of the traffic entering or leaving your network. This arrangement also keeps intrusion prevention systems from generating alerts and wasting resources on traffic blocked by the firewall.
FIGURE 4-2 Possible locations for security devices
Internal networks can be divided into multiple tiers, as described later, and even the most basic networks should be divided into a publicly accessible portion, usually called the DMZ, and a non-publicly accessible internal network. Separate and protect the divisions between network tiers with stateful firewalls and inline IPSs. IDS or IPS devices should also be placed along internal network paths that may be carrying sensitive information such as internal directory services, network storage, or Supervisor Control and Data Acquisition (SCADA) communications.
Place devices monitoring network traffic, such as IDSs, on network taps rather than SPAN ports. If security devices are placed on SPAN ports, ensure that the total bandwidth of the SPAN port will not be exceeded at any time under normal circumstances and ensure that your device can handle mirroring all the traffic you want without overloading the switch and dropping packets. Remember to regularly check for updated software and firmware for all devices in the network, especially security devices. Almost all security devices, such as IDSs and IPSs, also require regular updates to their signature databases.
of your external firewall. Want to see internal attacks against your server farm? Then you’ll need devices that sit between the server farm and your user base. You will want to understand how the placement of security devices affects your ability to monitor and secure network traffic.
Critical Infrastructure / Supervisory Control and Data Acquisition (SCADA)
Supervisor Control and Data Acquisition (SCADA) systems were originally designed primarily for reliability and safety without security as a primary objective. SCADA systems are typically made up of several sensors for data collection with a SCADA master system monitoring the sensor data, alerting an operator if a change-of-state (COS) event occurs. Some SCADA systems incorporate system control functions, allowing for the automated response to COS events. Because SCADA systems are commonly used to control the physical processes of industrial systems, including critical infrastructure, successful attacks can have a devastating impact in the physical world.
For protection against remote attacks, do not connect SCADA systems to the Internet or other networks if you can possibly avoid it—what cannot be reached at all usually cannot be breached. However, sometimes communication over other networks is required. If SCADA systems must be connected to other networks, isolate the SCADA systems as much as possible in the following manner:
- Always protect the SCADA systems from other networks with a firewall.
- Configure routers to restrict network traffic via Access Control Lists (ACLs).
- Use VLANs to facilitate secure communication between networks.
- Filter traffic based on MAC address (although this can be spoofed).
- Closely monitor all traffic passing on the VLANs and networks used for SCADA traffic.
Even isolated SCADA networks are vulnerable from onsite attacks or attacks on management devices. Here are some additional steps that should be taken in order to improve the security of the SCADA devices themselves:
- Replace default passwords with secure passwords.
- Do not use the same passwords for different devices or users.
- Change passwords on a regular basis.
- Disable unused or unnecessary device features.
- Configure banners and device names to reveal no information.
- Manage the devices with secure hosts used for no other purpose.
- Use physical access control and monitoring.
- Perform regular security training and auditing.
VoIP
Voice over IP (VoIP) is a collection of protocols and technologies that allows software and hardware to transmit voice and other media over an IP network. Many consumers and organizations of all sizes currently use VoIP phones instead of traditional landlines. VoIP can provide organizations with cost savings while providing end users with other advantages such as location portability and call clarity. Along with these great advantages, VoIP also brings new security considerations and new sources of security vulnerabilities. The primary components of VoIP are hardphones, softphones, and IPBXs. Hardphones are standalone pieces of hardware resembling traditional phones. Softphones are implemented in software running on a client such as a desktop workstation or a laptop. An IP PBX (or IPBX) is responsible for setting up connections and performing all the functions of a private branch exchange (PBX). Figure 4-3 shows a simple VoIP network that uses a software-based PBX.
One of the most often overlooked aspects of security is availability. Traditional landlines have their own source of power provided through the cabling, thus leading to an increase in availability. When you switch to VoIP phones, a loss of power means the loss of phone service unless additional steps are taken. Therefore, VoIP and networking hardware such as IPBXs, hardphones, routers, and switches must have access to alternative sources of power such as uninterruptible power supplies (UPSs). Additionally, any security devices along the way, such as IPSs or firewalls, will require backup power as well.
VoIP systems may be attacked for a variety of reasons, including registration hijacking and toll fraud, eavesdropping, information gathering, denial of service, spam, and phishing. In order to protect against these attacks, the devices themselves must first be secured. In order to secure the VoIP devices, follow these guidelines:
- Update device hardware and software.
- Test modifications before deployment.
FIGURE 4-3 T Simple VoIP network
- Observe standard security best practices for computers with softphones such as applying OS updates, ensuring secure passwords, and using antivirus and antimalware software.
- Change any default passwords initially and on a regular basis.
- Disable any unused or unnecessary features, services, or ports.
- Lock the configuration so users cannot change it.
- Disable the user’s ability to view configuration options.
- Hardware- and software-based VoIP phones should use secure protocols such as IPSec or SIPS, SRTP, SRTCP, which provide mutual authentication, confidentiality, and integrity.
- Use HTTP digest authentication if mutual authentication protocols cannot be used. Securing VoIP devices is an important step. However, we must remember to apply defense-in-depth principles. This means securely planning for and deploying VoIP services. When designing the VoIP network, use the following guidelines:
- Use a VLAN to separate the VoIP network devices.
- Consider using a separate VLAN for each type of VoIP device.
- If network services such as DNS, DHCP, and NTP are required, do not use existing services; instead, use separate services dedicated to the VoIP network.
- Use a session border controller (SBC) when routing VoIP communications over the Internet.
- Connect the SBC to a firewall with an embedded application layer gateway (ALG).
IPv6
IPv6 is a replacement for the commonly used Internet protocol IPv4. IPv6 brings many improvements, most prominently a much larger address space of 128 bits (compared to 32 bits in IPv4). Important but less publicized additions to IPv6 include the required support of optional security features such as IPSec. IPSec can provide authentication, integrity, confidentially, and protection against replay attacks. IPSec is discussed in depth later in the chapter, in the section “Transport Security.” Although IPv6 was standardized in 1998, its adoption has been slow due to lack of support by older hardware and operating systems. Additionally, Network Address Translation (NAT) has delayed the need for the additional address space provided by IPv6. Because of this, many networks, especially home networks, use NAT routing, which is not supported by IPv6—which further hinders the adoption of IPv6. Despite adoption issues, IPv6 is here to stay, and security practitioners need to know how to secure IPv6 networks and how to take advantage of the security benefits inherent in IPv6. The IPv6 header is illustrated in Figure 4-4, showing the required elements and their placement in a packet header.
IPv6 brings with it security benefits other than IPSec. Packet fragmentation is only performed by hosts, partially removing a source of common vulnerabilities used to exploit TCP/IP stacks and bypass firewalls. Better support for quality of service (QoS) is built into IPv6, thus improving availability. The larger address range and required use of Classless Inter-Domain Routing (CIDR) notation enables better planning and deployment through the easier allocation of addresses and configuration of routes. Although NAT does have some security advantages, the removal of NAT can lead to much-needed improvements in security. NAT generally gives a false sense of security and can be a barrier to the integration of other security measures such as IPSec in transport mode.
FIGURE 4-4 IPv6 Packet Header
IPv6 packet header
Before deploying IPv6 on any network, you must give some additional security considerations careful consideration. Some older security devices and tools such as firewalls, IDSs, log analyzers, and flow analyzers may not support IPv6, thus enabling attackers to circumvent these security mechanisms. Furthermore, even devices supporting IPv6 may not be able (or configured correctly) to analyze the IPv6 encapsulation of IPv4 packets. Encapsulation of packets is used to maintain backward compatibility for older IPv4 hardware and software. Networks employing NAT should have security policies thoroughly reviewed and updated due to the removal of NAT. Remember to update security devices such as firewalls, IDSs, and analysis tools to account for the additional addresses.
Policies for ICMP and multicast network traffic will need to be reviewed because these protocols are used for other essential IPv6 protocols, such as Neighbor Discover Protocol (NDP) and StateLess Address AutoConfiguration (SLAAC). Multicast and ICMP communications for NDP and SLAAC communications should always be secured because they are responsible for routing configurations. Without security measures in place, attackers can perform spoofing attacks. Secure Neighbor Discovery (SeND) may be used instead of IPSec to secure NDP and SLAAC. However, many devices do not support SeND, thus leading to security vulnerabilities.
Lastly, be prepared for changes in attack vectors. Due to the vast expansion in the number of addresses, worms and botnets may increasingly rely on informationgathering techniques to locate targets instead of randomly scanning for vulnerable systems. With more complex network stacks supporting both IPv6 and IPv4, there is an increased chance of vulnerabilities. In order to mitigate this risk, be sure to frequently check for and apply software and firmware updates.
CERTIFICATION OBJECTIVE 4.02
Complex Network Security Solutions for Data Flow
Monitoring data flowing through networks is an important security objective for many organizations. Sensitive information such as customer data, intellectual property, and classified information are of critical importance. Monitoring data flows allows organizations to detect sensitive information leaving the network. Analysis of network traffic also helps in efforts to detect other threats such as malware and botnets. Data flows are typically analyzed by sniffing traffic or by the use of a proxy server. Proxies have the advantage of being able to cache web pages within the internal network, thus saving external bandwidth. Proxies have the additional security benefit of being able to filter allowed connections.
There are two types of proxy servers for handling web traffic: traditional proxies and transparent proxies. In traditional proxy servers, the client is configured to talk to the proxy server instead of the intended destination. Transparent proxies, however, have several advantages over traditional proxies:
- They have higher available bandwidth and lower latency.
- Client machines do not need special configuration.
- They are invisible to the end user.
- They are more difficult to bypass.
However, attackers’ tools and methodologies are constantly evolving and incorporating the latest technology, such as the military-grade encryption of network traffic. Encrypted data flows carrying malicious or sensitive information cannot be differentiated from data flows carrying legitimate information. Implementing policies to disallow and prevent encrypted traffic would likely do more harm than good because many legitimate traffic flows should be encrypted to ensure confidentiality.
How can security professionals implement solutions to analyze the rising amount of encrypted network traffic to successfully detect threats? Some proxy server products do allow for the interception, decryption, and re-encryption of SSL network traffic by basically performing a man-in-the-middle attack. However, SSL was designed to prevent man-in-the-middle attacks by only accepting certificates signed by a trusted Certificate Authority (CA). Therefore, client machines must be configured to trust certificates signed by the organization’s proxy. Fortunately, this can be automated using methods such as an Active Directory Group Policy.
Additionally, the proxy server can be configured to not intercept SSL data flows to specific websites, such as financial institutions, in order to better comply with privacy policies. Implementing solutions to monitor encrypted communications, combined with appropriate firewall rules, can allow organizations to more effectively detect sensitive information leaving the organization’s network. Furthermore, with these solutions in place, any unauthorized, encrypted information leaving the network is suspect and may indicate malware, botnets, or other malicious activity.
would normally be inaccessible to you. For example, SSL traffi c is typically inaccessible to traditional IDS/IPS solutions—but using the right kind of proxy will give you the ability to monitor SSL traffic effectively.
CERTIFICATION OBJECTIVE 4.03
Secure Data Flows to Meet Changing Business Needs
Although the detection of sensitive data leaving an organization’s network is crucial, protecting sensitive data to prevent it from leaving the network is of at least equal importance. The protection of sensitive data is part of a multilayer defense-in-depth strategy. In order to protect sensitive data, first create a security profile by identifying potentially sensitive information and answering the following questions:
- What applications are used to access this information?
- How is the information stored?
- What security measures are in place to secure the stored information?
- How is the information transmitted over the network?
- Is authentication and authorization enforced at all levels of access?
- Are authentication credentials transmitted securely?
- Are strong password policies enforced?
- What encryption algorithms are used?
- How are the encryption keys protected?
After creating a security profile, evaluate your current security posture and identify any potential weaknesses. Remember to follow a defense-in-depth strategy by ensuring confidentiality, integrity, authentication, and authorization using multiple methods at every possible level.
Your first line of defense is the use of strong authentication and authorization at all levels. This includes strong access controls at all levels of access, including physical, local account, remote account, database, and all services and applications. Do not pass authentication credentials in the clear. For example, do not use the Telnet service; instead, use a secure protocol such as SSH. Do not authenticate users or grant authorization based on IP address, because this can be easily spoofed. Additionally, remote users should connect to the organization’s network using secure technologies such as VPNs or VLANs.
Protect the confidentiality of sensitive information at all levels, including how it is stored on disk and how it is transmitted over the network. Using tight access control and authorization is a good first step. Additionally, sensitive data should always be encrypted when stored on disk or transmitted over the network. If encryption keys are stored on the disk, verify that they are strongly protected at multiple levels as well. For example, ensure that permissions and access control methods protecting the keys are as strong as possible. Additionally, protect encryption keys with passwords so that keys do not exist on disk in an unencrypted manner.
Verify that all applications accessing sensitive data are using well-known, secure encryption methods providing both confidentiality and integrity. For example, do not use FTP to access sensitive information; instead, use a secure protocol such as SFTP instead. Furthermore, use only the latest and most secure protocols. For example, configure SFTP clients and servers to only use the SSH 2 protocol, because it is significantly more secure than the older SSH 1.x protocols. Do not use products with proprietary or secret encryption or authentication methods because they may contain security vulnerabilities and are not as thoroughly tested as commonly accepted protocols. Security through obscurity should not be considered reliable, especially when it comes to complex cryptographic algorithms.
Isolate sensitive information as much as possible. Separate the network traffic into multiple VLANs, grouped by the type and sensitivity of information being transmitted. Do not store sensitive information and publicly available information on the same devices. Do not run any unnecessary or unrelated services on devices storing sensitive information. Furthermore, as a security professional, it is your job to ensure that all operating systems and applications, especially those accessing sensitive information, are up to date with the latest software. Subscribing to bug and vulnerability mailing lists is also a very good idea.
Emerging Technologies
Security should be prepared for and keep pace with ever-changing business needs. Mobile devices such as laptops, tablets, and mobile phones are becoming more powerful and prolific every day. Allowing mobile devices access to corporate data and corporate networks is attractive to businesses because it enables end-user mobility and improves productivity (in theory at least). Supporting mobile devices normally requires both wireless and remote access to company resources.
Security policies should be in place protecting the mobile devices themselves. Protect sensitive data stored on mobile devices using strong encryption. Mobile devices should always use authentication and strong passwords. Having separate mobile devices for business and personal use is recommended because the security of mobile devices is highly dependent on the applications installed on them by users. This is becoming more difficult as many organizations are adopting bring-your-own-device (BYOD) policies, which let users choose the type of mobile device they prefer. To help address the vast differences in devices this type of policy can create, many organizations are looking to increase their use of cloud storage, sandboxing,
and desktop virtualization.
Always protect wireless networks using the latest standard security technologies. For example, WEP should never be used. WPA2-Enterprise with AES encryption should be used instead. This provides strong authentication as well as strong assurances for the confidentiality and integrity of data transmitted over the wireless network. If guest access is required, maintain separate wireless networks with separate hardware if possible. Consider separating the wireless network from the wired network physically (or with VLANs) and requiring users to
access organizational resources using secure protocols such as VPNs that provide confidentiality, integrity, and authentication.
Mobile devices are here now in great number—and they are here to stay. However, implementing good security policies for mobile devices is just the beginning. What’s the next emerging trend in computing that you need to be prepared for? As a security professional, it is your job to be constantly prepared for ever-changing business needs.
CERTIFICATION OBJECTIVE 4.04
Secure DNS
The Domain Name System (DNS) is a critical part of our Internet infrastructure, mapping names to IP addresses. DNS servers have been in use since the early days of the Internet, and very little emphasis was placed on security during its design and implementation despite its importance to the flow of network traffic. Several industry standard checklists are available for securing DNS (examples can be found at Technet, DISA, and NIST). For a quick reference, here is a basic checklist for securing DNS services:
- Keep the DNS software up to date.
- Change the version string to provide no useful information.
- Separate internal and external DNS servers.
- Restrict allowed transactions by client IP address, but do not rely on this due to spoofing attacks.
- Use Transaction Signature (TSIG) to authenticate transactions.
- Disable or restrict zone transfers as tightly as possible.
- Disable or restrict dynamic updates as tightly as possible.
- Enable logging and analyze the logs regularly.
- Implement Domain Name System Security Extensions (DNSSEC) and sign zones.
Enabling dynamic updates allows clients to automatically register and update records on a DNS server. Dynamic updates are usually disabled by default and should remain disabled if not needed. However, dynamic updates may be necessary or desirable in order to reduce the administrative overhead for clients that move frequently or have dynamically assigned IP addresses. If dynamic updates are enabled, follow the checklist to restrict dynamic updates by IP address and, most importantly, use TSIG for dynamic updates.
Another good strategy for deploying DNS is to place your primary external name server behind one or more secondary name servers, only exposing the secondary name servers to the Internet. The primary name server should be restricted to communicate only with the secondary name servers. Thus, if the exposed secondary name server is compromised, your primary database will still remain secure.
Securing Zone Transfer
A great source of information to attackers is the process of “footprinting” their targets and the records contained within a DNS server. Zone transfers allow a primary or “master” DNS server to replicate portions of its database to secondary or “slave” DNS servers. The information contained within zone files can be an extremely helpful source of information to attackers, identifying IP addresses and functions of different devices on the network and possibly other critical information such as operating system type and version.
Most new installs of current DNS server software disable zone transfers by default. The default settings do not solve the problem, however, because normally the configuration needs to be changed in order to allow legitimate zone transfers to secondary DNS servers. Unrestricted zone transfers may be enabled for troubleshooting purposes or to allow the easy setup or modification of a network. However, there really is no reason not to at least restrict zone transfers; just remember these guidelines:
- The primary DNS server should restrict zone transfers to only secondary servers.
- All secondary DNS servers should have zone transfers disabled.
- Restrict zone transfers by IP address, but do not rely on this because IP addresses may be spoofed.
- Always restrict zone transfers by requiring a transaction signature.
- Restart the services after changing the configuration.
- Test all servers to ensure zone transfers are correctly restricted.
TSIG
Transaction Signature (TSIG) is used by DNS in order to provide nonrepudiation—or, to be more precise, TSIG provides both origin authentication and proof of integrity. TSIG is employed by DNS for transactions such as notifies, zone transfers, dynamic updates, and recursive queries. TSIG uses a shared secret key and a hash function to provide integrity and authentication, as well as a timestamp to prevent replay attacks. Because of this, the use of TSIG requires synchronized clocks. Protocols such as NTP are useful for ensuring clock synchronization. TSIG provides the following advantages:
- Proof of origin. It cannot be spoofed like IP addresses.
- Proof of integrity. It cannot be modified by a third party.
- Prevention of replay attacks.
Using TSIG is always recommended and provides substantial security gains. However, be aware of the following limitations before deploying TSIG:
- TSIG does not provide confidentiality of transactions.
- Administering a large number of keys may become difficult.
- Key revocation may be a burden if the same key is shared among multiple hosts.
DNSSEC
The Domain Name System Security Extensions (DNSSEC) is a set of extensions to the DNS service that provides origin authentication, integrity, and backward compatibility. Additional DNS record types were created to provide the extra required information, such as Return Record SIGnature (RRSIG) to hold digital signatures and DNSKEY to hold public keys. Trust anchors and authentication chains are used to securely authenticate the public keys and, by extension, the provided digital signatures.
The correct deployment of DNSSEC will improve the security posture of your organization. However, careful planning is required for a correct and secure deployment of DNSSEC, and zone signing is a critical part as well. Tools capable of automating common tasks such as key generation, rollover, and zone signing may be used and will assist you in your implementation. Figure 4-5 illustrates the relationship of tools and the functions they perform in a DNSSEC deployment. However, private keys must be well protected, especially when you are using automated signing tools. Sign zone files only on an extremely well protected and isolated primary DNS server. Restrict the primary DNS server’s communications to performing zone transfers with secondary DNS servers. Lastly, because of poor adoption, chains of trust in DNSSEC are extremely limited. Therefore, manually distribute your zone’s public keys using secure communications that provide both authentication and integrity.
FIGURE 4-5 Components of DNSSEC-Tools (from https://www.dnssec-tools.org/wiki/index.php/Tutorials)
CERTIFICATION OBJECTIVE 4.05
Secure Directory Services
Directory services in their simplest form provide information storage and retrieval services by mapping names to values. Organizations of all sizes commonly rely on accessing directory services within their networks for a multitude of purposes, including storing user information and security policies. Securing directory services and the information being stored in them is of critical importance. For all directory services, remember to protect them using firewalls with appropriate ACLs and prevent internal firewalls from silently dropping long-lived TCP connections to directory services. In the following sections, we look at some of the more common directory services and the best practices for securing them.
LDAP
Lightweight Directory Access Protocol (LDAP) is a directory service protocol for information storage and retrieval over a TCP/IP network. The LDAP protocol is supported by a variety of commonly used directory service software. Discussing implementation-specific details of securing specific software products supporting LDAP is beyond the scope of this chapter. However, be aware that as a security professional it is your job to research and secure your specific LDAP software. Here are some general best practices for securing LDAP software:
- Use Simple Authentication and Security Layer (SASL) instead of simple bind, if possible.
- If simple bind is unavoidable, then use TLS for confidentiality.
- Do not use deprecated SSL encryption for LDAP; instead, use SASL or TLS.
- Disable old account entries in a timely manner.
- Don’t delete old accounts to prevent reusing old identifiers (disable them instead).
- If delegation of authority is required, do not use password sharing.
- Avoid storing passwords in a way that would allow the clear-text password to be reconstructed.
- Passwords should be hashed with a good salt.
- Use care when enforcing password policies to provide availability and prevent accidental account lockouts.
- Use replication to back up data and provide availability.
- Implement replication in different physical or logical locations.
- Use a separate LDAP server for publicly accessible information.
- Limit the size of search results if possible.
- Secure the server operating system with standard security best practices.
- Protect the LDAP data store with tight permissions and encryption.
- Do not run LDAP or other services with unnecessary permissions.
- Configure resource limits such as file descriptors and TCP connections to ensure availability.
AD
Active Directory (AD) is a directory service implementation created by Microsoft. Active Directory is used in Windows domain networks and included with most versions of Windows Server since Windows 2000. Active Directory uses LDAP and Kerberos for authentication and authorization of computers within a Windows domain.
Perhaps the most important aspect to securing Active Directory lies in correct planning and delegation of administration. Delegation is usually done in order to match the organizational structure and to meet operational as well as legal requirements. Two kinds of administrative responsibilities can be delegated: service management and data management. A good plan for the delegation of authority increases security by ensuring isolation and autonomy of data and services.
For each department within the organization, determine the most suitable level of autonomy and isolation. Multiple organizational units should be used when data autonomy is desired. For domain-level service autonomy, employ multiple domains. Use separate forests for service isolation, forest-level service autonomy, and data isolation. When installing a domain controller, follow these best practices:
- Use automated installation processes to ensure predictable, repeatable, and
secure deployments. - Use the NTFS file system.
- Disable all network transport protocols besides TCP/IP.
- Install and secure DNS.
- Do not install IIS, SMTP, or other unnecessary services.
- Use strong passwords.
- Disable nonessential services.
- Test for and disable anonymous Active Directory access.
In addition to these best practices, be sure to audit your Active Directory service regularly. Auditing will—in addition to ensuring that your Active Directory services are not compromised—verify that isolation and autonomy are implemented as desired, and track important security-relevant changes. You can find more extensive checklists for securing Active Directory online at Microsoft Technet, SANS, and so on.
Federated Identity
Federated Identity allows an organization, or service provider, to securely identify users by delegating the authentication of users to another trusted organization called the identity provider. Federated Identity is designed to allow authentication to be performed once and to use the associated authorizations across multiple domains. Additionally, identity information, such as authorization for a particular domain, can be shared with other domains given the user’s consent. This is especially useful because it transfers the burden of verifying authorization for a particular domain to the domain in question.
Federated Identity technology is attractive to users tired of remembering countless usernames and passwords. It also lessens the administrative overhead by transferring much of the responsibility to the identity provider, as well as reduces the number of forgotten credentials. Security is increased by eliminating multiple databases of stored user credentials and maintaining several separate authentication mechanisms. Therefore, standards compliance for federal and state regulations such as HIPPA are made easier. Federated Identity also improves security by reducing the need for users to write down or save passwords on their computer.
Despite the many potential advantages, Federated Identity also has many downsides. Support for Federated Identity is not currently available for many applications or domains. Integrating a Federated Identity system into applications within a domain may be costly. Federation membership may require strict security policies that may not be appropriate and necessary for every application. If Federated Identity is widely adopted, an attacker, after stealing a user’s credentials, would have access to all of the user’s online accounts. Although privacy protections are provided by Federated Identity, governments, insiders, or multiple colluding organizations could easily trace all of a user’s online actions.
Single Sign On
Single Sign On (SSO) allows users to perform a single authentication and use the granted authorization for multiple applications within a single domain (as illustrated in Figure 4-6). Like Federated Identity, SSO is attractive to users and administrators because it reduces the number of separate authentication mechanisms. Similarly, implementing SSO for all resources within a domain may be impossible. However, unlike with Federated Identity, authorization does not extend to other domains and is normally not entrusted to third parties.
Authorizations are typically granted as tokens, usually as browser cookies, and are good for a specific predefined lifetime. Do not use a Single Sign On implementation that simply remembers passwords for multiple applications. Passwords should never be stored in a manner that would allow them to be reconstructed. To prevent session hijacking with Single Sign On implementations, only use secure protocols (such as SSL) that provide confidentiality and integrity guarantees.
When you’re using SSO for your organization, even greater care must be taken to protect users’ credentials. Granting access to multiple resources with a single set of credentials increases the potential negative impact of stealing a single set of credentials. For this reason, when you’re designing a SSO system, it is a good idea to combine password authentication with other forms of authentication, such as smartcards or a one-time password system.
FIGURE 4-6 Single Sign On allows access to multiple systems and applications.
CERTIFICATION OBJECTIVE 4.06
Network Design Consideration
Designing a secure network begins in the planning phase. Planning not only involves deciding the logical network structure and placement of devices, but also includes planning their physical placement as well. Security is an ongoing process— from planning, to installation, deployment, testing, and maintenance. The process of security must be revisited when you’re upgrading or installing new services, and when expanding, restructuring, or upgrading the network infrastructure.
Building Layouts
While planning the logical network structure, be sure to consider the layout and features of your physical environment. The building layout design process is the perfect time to incorporate network security needs. Less fortunate security professionals will have to make do with the current facilities or make their own building layout changes as needed. Incorporate physically secure, locked communication closets in your layout and limit access to those closets. Be sure to incorporate plenty of space in the comm closets and server rooms for easy maintenance, expansion, and installation of UPSs if needed. Always install UPSs for business-critical services and the routers and switches that provide access to them. Do not forget UPSs for critical network security devices such as firewalls, IDSs, and logging servers. The interior of buildings should be well lit, especially in and around server rooms and comm closets. Design secure cabling paths throughout the building layout. If using multiple routes for high availability, remember to run the physical cables along different physical paths to avoid single points of failure. Do not allow users to have direct access to network infrastructure components such as routers, switches, cables, and wireless access points. Lastly, remember to incorporate proper power and cooling into comm closets and server rooms. Use separate power circuits, where appropriate, when duplicating network resources to provide high availability.
reroute, cut, and so on. Switches housed in openly accessible areas instead of secure comm closets are far more likely to be compromised.
Facilities Management
Facilities management for network security incorporates several aspects, including upgrades and maintenance to the network infrastructure. If the facility was properly planned and designed, then adequate space, power, and cooling is already available. In any case, proper planning, installation, deployment, and testing are required to ensure the network remains secure.
An additional aspect of facilities management is the administration of personnel access control and monitoring. Begin implementing secure personnel access control using the following guidelines:
- Supply identification badges with assigned levels of authorization.
- Use video surveillance systems to monitor access.
- Use security alarms for restricted areas.
- Employ patrols and inspections of critical infrastructure.
- Lock all comm closets and server rooms.
- Restrict and monitor access to comm closets and server rooms.
- Lock individual devices or the racks housing them.
- Provide security training and implement unannounced inspections.
CERTIFICATION OBJECTIVE 4.07
Multitier Networking Data Design Considerations
Multitier network architectures typically have tiers grouped by functionality and arranged by the flow of data. The boundaries between tiers are typically secured using firewalls and other security devices such as IPSs. The key to multitier networking architectures is the deployment of firewalls and proper rules. Proper rules improve security by only allowing communication between adjacent tiers and limiting that communication to essential ports. Thus, in theory, an attacker only has limited access to a single adjacent tier. Multitier network architectures are a good example of employing a defense-in-depth strategy. Figure 4-7 shows the simplest multitier concept, with a DMZ for Internet-visible services separated from the internal network.
A common multitier network architecture divides the network into three tiers: the DMZ, the application tier, and the data tier. The DMZ consists of Internetfacing services such as web servers, proxies, e-mail gateways, and public DNS servers. A firewall is typically configured to only allow incoming connections to the public services in the DMZ. Nonpublic services such as internal web servers, directory services, internal DNS servers, and application servers are placed in the application tier. The application tier is placed behind the DMZ, with a firewall placed in between and configured to only allow incoming connections from the DMZ on ports used by the application servers. Lastly, the data tier is placed behind the application tier and contains services such as database servers, file servers, storage area networks (SANs), network attached storage (NAS), internal DNS servers, and any devices that contain sensitive information. Once again, the data tier is separated from the application tier with a firewall set to allow incoming traffic from only the application tier, on only the ports required to access the data.
Sometimes the DMZ and application tiers are combined into a single tier and placed behind a new proxy tier. External requests go to the proxy tier, which then makes appropriate requests to the services in the DMZ tier.
FIGURE 4-7 Simple DMZ implementation
organizations use a DMZ between their internal users and their server farm? Using the tiered approach to fi lter and shape traffic flowing between your internal user community and your critical servers can reduce the target profiles of your critical servers.
CERTIFICATION OBJECTIVE 4.08
Logical Deployment Diagram and Corresponding Physical Deployment Diagram of All Relevant Devices
A logical deployment diagram describes network resources and the desired network topology in a logical manner, with a focus on showing connections between devices in a readable manner. Typically, a logical deployment diagram is created first, after which a physical deployment diagram is then created. Physical deployment diagrams specify the exact position and placement of network servers, routers, links, and other resources. After development of a physical deployment diagram, ensure that it matches the logical deployment diagram.
It is common for intended or accidental changes to be made during the actual deployment of network hardware. Because of this, it is important to update both the logical and physical deployment diagrams as they are rolled out and when they are finished. As network additions and changes are made over time, be sure to continuously update the deployment diagrams. Additionally, the network layout should be audited regularly to ensure it is in agreement with both the physical and logical deployment diagrams.
CERTIFICATION OBJECTIVE 4.09
Secure Infrastructure Design
A secure infrastructure design begins in the planning phase. The first step in planning is to identify network components and their security needs. What devices will be connected to the network? How will the network components be accessed? Where is the sensitive information stored? How and where will sensitive information be accessed and transmitted?
Once the assets and security needs of devices have been thoroughly investigated, designing the infrastructure can begin. Use a multitier networking architecture to protect access to sensitive data. Use proxies and gateways to limit the exposure of services to the Internet. Place firewalls at the border and between network tiers. One or more servers should be dedicated to syslog services. Be sure to configure firewalls to enable stateful inspection. Consider placing an additional firewall at the boundary to perform basic ACL filtering before incoming traffic reaches firewalls with stateful inspection enabled. Firewalls should also be placed at other points of entry, such as wireless access points. Separate the network traffic according to the sensitivity of data being transmitted and isolate each part into separate VLANs using separate hardware if possible.
Intrusion detection and prevention systems (IDPSs) should be capable of monitoring network traffic at all times. Consider placing IDPSs at the perimeter, the DMZ, between routers and switches in the internal network, and at wireless access points. An IDPS should always be used on internal networks handling sensitive information. Deployment of an IDPS on all internal networks is recommended. Ensure that each IDPS has more than enough bandwidth and processing resources available to handle the traffic load. Hubs should not be used to provide traffic visibility to an IDPS, and SPAN ports may not provide the necessary bandwidth. Network taps should be considered a superior alternative to SPAN ports. If using multiple VLANs on a single switch, ensure that switch can route all traffic to a SPAN port without dropping packets and that the IDPS is capable of analyzing that volume of traffic. In order to limit exposure, IDS devices should listen in promiscuous mode on network interfaces without an assigned network address. For IPS devices, use inline detection and dropping of packets on interfaces without assigned network addresses. Separate interfaces should be configured for the maintenance and management of an IDPS. Routers and switches facilitating communications for critical services should employ high availability design principles such as redundancy. Fault tolerant devices provide redundancy within components such as dual power supplies, fans, and routing hardware. Redundancy within the network topology provides even better reliability by providing multiple independent paths throughout the network.
Tightly control access to the network. Allowing users to attach unauthorized devices to the network can be a security risk. Maintain a list of IP address ranges and authorized MAC addresses. Apply granular control of MAC address filtering. MAC address filtering cannot be relied upon, however, because MAC addresses can be easily sniffed and spoofed. Be prepared to block the IP and MAC addresses of unapproved devices or devices violating the organization’s security policy. Devices engaging in malicious activity, running unapproved services, suspected of malware infection, or those abusing network services and resources should be blocked (or quarantined) immediately.
- Visibility What traffic are you monitoring? Will any encrypted traffic be passing through the network at this point?
- Volume How much traffic will be passing through this location? Can the security device handle the expected volume? What will the anticipated volume of alarms be?
- Management access Will you be able to safely and securely access the management interfaces of the device in this location? What path will alarms follow when reporting back to the management server?
CERTIFICATION OBJECTIVE 4.10
Storage Integration
Organizations of all sizes, and even some individual users, require network-based storage solutions. Although fully fledged servers can provide network access to internal storage, the use of dedicated network-based storage has many advantages. Dedicated devices can ease the deployment and maintenance requirements of providing access to network-based storage. Separating devices providing file storage from other network services can reduce the impact of a single service being compromised. Additionally, dedicated devices have a single purpose and need not run the myriad of other network and local services provided by fully fledged servers, thus improving security. Restricting access also reduces risk, as Figure 4-8 shows. By only allowing application servers to connect to a NAS, the risk of direct compromise or infection from the user population is reduced. There are two main types of dedicated storage solutions: network-attached storage (NAS) and storage area network (SAN).
FIGURE 4-8 Restricting direct user access to network-based storage
NAS devices run common network file system services such as SMB/CIFS, NFS, FTP, SFTP, and AFP. As such, it is important to be well versed in the secure configuration of whatever file system services are enabled. Proper planning is required, and the security of a device’s available network file system services should be investigated before purchase. Anonymous access to network storage should never be enabled. Restricting access by IP address can be part of a defense-in-depth strategy, but should never be relied on due to the ease of spoofing. If username-and-password-based authentication is used, ensure that the authentication is done in a secure manner. Policies requiring the encryption of transmitted passwords and password hashes should be enforced. For example SMB/CIFS has optional LanMan authentication for older clients and should always be disabled. NFSv4 is significantly more secure than previous versions of NFS and mandates the use of several security measures such as Kerberosbased authentication. NAS devices should never be exposed to the Internet, and they should be restricted to a separate VLAN if possible. Secure protocols such as SFTP should always be used in place of insecure options such as FTP. As with all network-attached devices, unnecessary, unused, or insecure services such as SNMP should be disabled.
data silos and application servers.
Despite the similar acronym, SAN should not be confused with NAS. A pure SAN device exposes the storage as a block device and appears as a physical drive to the client. This type of configuration allows for greater flexibility. Any standard file system may be used, and the disks may be more easily moved from one device to another. SANs can be connected over Fiber Channel (FC) or an Ethernet TCP/IP network. SANs also have disaster recovery benefits by providing options for storage replication to remote sites. Before a SAN is purchased, planning is important and the available security features should be investigated. Just as with NAS devices, unnecessary protocols should be disabled and secure authentication methods should be used. Additionally, a SAN should never be exposed to the Internet, and should be kept on a separate dedicated network, if possible, for both isolation and performance. IPSec should always be used to secure SAN communications over IP for both confidentiality and integrity.
Zoning is used to create groups of host and storage nodes. When using zoning, members can only communicate with other members in the same zone. For flexibility, members may belong to multiple zones. Zoning is a good security practice; however, there are a few issues to be aware of. Zoning can be implemented in hardware or software, referred to as hard zoning and soft zoning, respectively. Soft zoning is vulnerable if an attacker knows or can guess the Fiber Channel address of a device outside its zone. Zoning identification can be done using the port World Wide Name (pWWN) or the Domain, Port (D,P), or both. Zoning configurations should use pWWN identification exclusively, if possible. Identification by pWWN prevents unauthorized zoning access by the rearrangement of cables. To reduce the risk of pWWN spoofing, pWWNs should be mapped to physical ports using Device Connection Control (DCC) policies.
SANs employ Logical Unit Number (LUN) Masking is a means to control authorization by making a LUN only available to certain hosts. The pWWN of a server’s host bus adapter (HBA) is used to configure LUN masking. LUN masking is usually implemented at the HBA level, which is vulnerable to any attack compromising the HBA. Better security is achieved when LUN masking is implemented at the storage controller and at the HBA.
CERTIFICATION OBJECTIVE 4.11
Advanced Configuration of Routers, Switches, and Other Network Devices
Network devices such as routers, switches, and printers are growing ever more complex, with ever-increasing remote management features and configuration options. Good security measures to take for any network devices include the following:
- Disable any anonymous access to information.
- Change the default usernames and passwords.
- Disable any unused or unnecessary services or features.
- Enforce the use of secure protocols only.
A common and very insecure protocol used on many networking devices is Simple Network Management Protocol (SNMP). SNMP is used for remote management and monitoring of network devices and allows the reading and writing of data such as statistics and configuration options. SNMP uses community strings for authentication that are basically passwords transmitted in the clear. SNMP should be disabled unless absolutely required. If SNMP must be enabled, then community write strings should be disabled on all devices possible. Default community strings should always be changed to the maximum possible length and contain both upper- and lowercase letters as well as numbers. Furthermore, all SNMP traffic should be blocked at the network perimeter. SNMP agents should also be configured to filter SNMP traffic from unauthorized internal hosts. Because all SNMP traffic including community strings is transmitted in the clear, SNMP should be used only on top of other secure protocols providing at least confidentiality and integrity. Efforts are being made to replace the traditional insecure SNMPv1 with the more secure replacement SNMPv3.
Use the following additional guidelines when appropriate for the configuring switches and routers:
- Use, but do not rely on, MAC address filtering when possible.
- A policy of one MAC address per switch port should be enforced.
- Configure ACLs to not permit known bad traffic, such as inappropriate or unused IP addresses, or internal source IP addresses on external ports.
- Ensure passwords for controlled access are required for all interfaces, including the Console, AUX, and VTY interfaces.
- Do not enable DHCP or BOOTP for edge routers.
- Set the correct date and time.
- Set up proper logging to a syslog server.
- Back up your switch and router configurations.
Transport Security
TLS and SSL exist on top of the transport layer, encapsulating application layer protocols. TLS and SSL provide confidentiality and integrity for application layer protocols such as HTTP, SNMP, and SIP. However, because the encryption occurs at the application layer, transport layer headers such as TCP and UDP headers are not encrypted. TLS and SSL can be used to create tunnels for specific applications. TLS and SSL can both be used to create VPNs by tunneling application layer protocols to their destination network.
IPSec is actually a collection of protocols to perform various functions. IPSec can provide confidentiality, integrity, and authentication of packets as well as protect against replay attacks. Authentication Headers (AHs) provide authentication, integrity, and protection against replay attacks for entire packets. Encapsulation Security Payload (ESP) provides authentication, integrity, and authentication for data or entire packets, depending on the choice of mode. When in transport mode, encryption occurs at the Internet layer, protecting the transport layer protocols. When in tunneling mode, the entire Internet layer packet is encrypted, and a new IP header created, encapsulating the packet. Both modes are useful for secure communication between two hosts. Tunneling mode can allow users to connect a single host on an untrusted network to a trusted remote network. Tunneling mode is also used to create VPNs by bridging two fixed, trusted networks.
Generally speaking, IPSec provides better security but comes with greater overhead, can be more difficult to deploy, and requires specialized support. Wireless networks, mobile devices, and remote access are much more easily handled by SSL-based VPNs. Additionally, SSL-based VPNs can provide more granular access controls.
Trunking Security
VLAN-hopping attacks enable an attacker on one VLAN to gain access to traffic on other VLANs (as shown in Figure 4-9). There are two general types of VLAN hopping attacks: switch spoofing and double tagging. Although the threat of VLAN-hopping attacks can be mitigated, the best protection is to use separate, dedicated hardware for each VLAN.
Some switches have dynamic trunking negotiation features, called Dynamic Trunking Protocol (DTP), to assist in their deployment. Even when static trunks are manually configured, DTP is still active. It is possible for attackers to abuse this feature and set up a trunk, enabling them to gain access to and inject traffic into other VLANs. This type of attack is called switch spoofing. To prevent switch spoofing, dynamic trunking should be disabled everywhere, if possible, and should never be enabled for any ports connected to end users. Switchport modes should be statically configured to be either access or trunk. DTP can then be disabled by issuing the switchport nonegotiate command on certain platforms.
FIGURE 4-9 T VLAN hopping attack
A second type of VLAN-hopping attack is called double tagging. Due to backwardcompatibility features in the 802.1q protocol, native VLAN traffic is not tagged by trunk ports. Attackers can exploit this by creating specially crafted packets with two tags. The first tag is stripped off by the trunk port of the first switch. The second tag, however, remains intact and allows the specially crafted packet to hop to a VLAN specified by the attacker. In order to prevent this attack, follow these procedures:
- Explicitly specify the native VLAN as an unused VLAN ID for all trunking ports.
- Do not use the native VLAN (VLAN 1) for any access port.
- Place any unused ports on a separate, unused VLAN.
- Enable tagging of native VLAN traffic for all ports.
- Use ingress filtering on edge ports to drop tagged packets.
Route Protection
Protecting networking routes within an organization and at its borders is critical to security. Attackers exploiting routing protocols and vulnerabilities may gain access to sensitive information, inject traffic, and redirect traffic flows. Successful exploitation may also lead to avenues of attack such as man-in-the-middle or denial-of-service attacks.
The Open Shortest Path First (OSPF) protocol is primarily used for internal routing. In the OSPF protocol, each node announces its link destinations and cost to its neighbors. Nodes also re-announce received link information so that all the nodes know the network topology. Each node then decides routes by calculating the shortest path.
Routing information in OSPF must be exchanged in a secure manner to avoid spoofing attacks. Use only MD5 authentication for the entire network. Authentication keys should be changed on regular basis. Some devices come with simple password-based security enabled and a preconfigured default password. With simple password-based authentication, the password is transmitted in the clear and therefore should be avoided. Be sure to configure all of the interfaces of OSPF devices to use non-broadcast mode. Non-broadcast mode aids in security through the explicit configuration of valid OSPF neighbors. Autonomous system boundary routers (ASBRs) can filter invalid routes from external sources. Additionally, administrators should be aware of IPv6 ICMP and multicast security implications discussed earlier.
Border Gateway Protocol (BGP) is used for interdomain routing between ISPs or sometimes within very large private networks. BGP is typically used to join multiple organizations that are separately owned and managed. Each organization is referred to as an autonomous system (AS) and is assigned an AS number (ASN). Because BGP typically involves routing communication through multiple autonomous systems, routes are chosen based on a number of factors, including local preference.
Security in BGP is hampered by the inability to control external security policies and BGP routers. However, the security of BGP can be improved by filtering incoming messages with improper address spaces such as your address space, the Martian address space, and known unallocated address spaces. Explicitly configure BGP peers, and only allow BGP prefix announcements with expected ASNs. Additionally, explicitly configuring the TTL of BGP packets to 255 and only accepting incoming BGP packets with a TTL of 254 will help to ensure that the packets originated from one hop away. Limiting the allowed number of received prefixes helps prevent malicious or accidental denial-of-service attacks.
Attackers, eavesdropping on BGP communications, may learn sensitive information about business relationships. Injection and modification of communications is also a serious threat, as previously discussed. In order to ensure authentication, confidentiality, and integrity for BGP communications, work with neighboring autonomous systems to secure the underlying TCP/IP connections used for the BGP protocol. MD5-based authentication, using shared secret passwords, should be enabled. Additionally, TCP/IP connections may be secured through the use of secure protocols such as IPSec.
Routing Information Protocol version 2 (RIPv2) is an older routing protocol intended for smaller, internal networks. RIPv2 is generally easier to configure, but has many deficiencies compared to OSPF. Deficiencies include but are not limited to the following:
- Fifteen hop maximum.
- No assigned cost; each hop has a cost of 1.
- Slower convergence could lead to availability issues.
- Higher bandwidth usage.
If deploying or upgrading a network, consider using OSPF instead. If RIP must be used instead of OSPF, use only RIPv2 because RIP version 1 has even more deficiencies and no support for authentication. When using RIPv2, always enforce MD5-based authentication for updates.
CERTIFICATION OBJECTIVE 4.12
ESB
Enterprise Service Bus (ESB) is a type of architecture for facilitating communications between applications or web services in a Service Oriented Architecture (SOA). An ESB has two main components: connectors and a routing engine. Connectors are primarily responsible for passing messages and data between services and the routing engine. Messages and data should be passed in a secure manner, meaning confidentiality, integrity, authentication, and availability should be used whenever possible and appropriate.
The confidentially and integrity of messages may be ensured by using secure protocols such as the latest versions of SSL and TLS. Secure protocols should be used for all messages passed over the network between services, connecters, and the routing engine. Alternatively, strong cryptographic algorithms can be used to sign and encrypt messages, although this must be done carefully to avoid security vulnerabilities. To further limit the risk of exposing sensitive information, one or more dedicated VLANs should be used for the transmission of information on an ESB.
Authentication may be provided through the use of certificates or usernames and passwords. Mutual authentication should be incorporated, if possible, using both client and server certificates. A good defense-in-depth strategy is to provide multiple levels of authentication. Tight access controls should be enforced, ensuring that the authenticated user or host has permission to access the requested sensitive information or functions.
Providing confidentially, authentication, and authorization is a good first step toward ensuring integrity. Additionally, all components should always check for and filter corrupt or malicious input. This includes checking both the size and format of messages, as well as ensuring that data types are correct and within expected ranges.
Denial-of-service attacks may target any of the architecture components, including services, connectors, and the routing engine. To help ensure availability, policies should be enforced that limit the rate of messages at the application layer. Appropriate limits should also be placed on bandwidth usage at the network level using firewalls, routers, and switches. Additionally, message-passing rates and bandwidth usage should be monitored for the preemptive detection and response to threats.
CERTIFICATION OBJECTIVE 4.13
SOA
Service Oriented Architecture (SOA) is a set of requirements and principles to facilitate the development of interoperable software services. Examples of standardized SOA frameworks include web services, SOAP, WCF, RPC, and CORBA. Using SOA improves interoperability and reuse of components because communication is done in a manner that’s operating system and programming language agnostic. SOA calls for authentication to be performed at the software service level with centrally managed identity credentials. Because SOA is a guiding set of principles, the security of the final product is not guaranteed. Great care must be taken when designing, implementing, and deploying a SOA for your organization’s specific needs. SOA implementations can suffer from a variety of flaws, such as the following:
- Insecure authentication
- Unprotected communications
- Disclosure of information
- Injection of malicious input
- Replay attack vulnerabilities
- Denial of service
- Insecure deployment
There is no silver bullet to ensure a secure SOA. Every project has different requirements and requires careful planning, review, and development. Standards with a focus on security, such as WS-Security, are discussed later. During planning and development, remember the following principles in order to mitigate these risks:
- Require authentication when possible.
- Always require authentication for sensitive functions.
- Use certificates for mutual authentication.
- Properly filter invalid or malicious input.
- Use prepared queries when accessing databases.
- Use XML gateways.
- Use secure XML parser options.
- Use the latest versions of secure protocols such as SSL and TLS.
- Use XML signing and encryption.
- Disable verbose fault messages in production systems.
- Use signatures with timestamps or nonces.
- Require security testing during implementation.
- Never expose SOA services to the Internet.
- Isolate SOA services on VLANs whenever possible.
- Log and analyze authentication requests and general errors.
CERTIFICATION OBJECTIVE 4.14
SIEM
Security Information and Event Management (SIEM) utilities analyze and correlate logs and events from multiple sources and provide real-time alerting features, as shown in Figure 4-10. SIEM utilities can also aid in the collection of information for compliance purposes. Before deploying an SIEM, identify log sources of critical systems and services in the organization’s network. Critical systems commonly include but are not limited to databases, file servers, domain controllers, Internet and intranet web services, web applications, proxies and filters, intrusion detection systems, firewalls, and routers. Consider all possible log sources, including application logs, operating system logs, antivirus logs, and malware detection logs. Be sure to configure the SIEM to look at successful and unsuccessful authentication attempts, detected attacks, detected viruses and malware, and general activity such as service requests. Also, consider the expected and actual network sources of connections and requests. Set the initial alert thresholds as something you would think unlikely to occur for nonmalicious activity. After deployment, be sure to spend time tuning the SIEM to reduce the number of false positives and irrelevant alerts. Also, be sure to tune for performance and ensure an appropriate amount of resources are free to protect against denial-of-service attacks and to allow for growth. Remember that an SIEM producing too many alerts will likely result in valid alerts going unnoticed.
An additional security consideration often overlooked is the security of security utilities. Before purchasing an SIEM, review the security of the SIEM service itself. Are the service and data-collection agents communicating in a secure manner with reasonable protections from eavesdropping, modification, and injection? Be sure to frequently update the data-collection agents and SIEM service to protect against newly discovered vulnerabilities.
time to determine exactly what type of information you want to collect, how long you need to maintain it, and so on, before starting an SIEM effort.
FIGURE 4-10 An SIEM collects logs from a variety of sources
CERTIFICATION OBJECTIVE 4.15
Database Access Monitor (DAM)
Database access monitors (DAMs), also referred to as database activity monitors, independently monitor the transactions and other activity of database services. DAMs are an important part of a defense-in-depth strategy. Common uses of DAMs include monitoring applications and users for unauthorized or fraudulent activity. Accountability and compliance auditing can also be aided by DAMs.
Before deploying and configuring DAMs, it is important to create a plan appropriate for your organization. Where are the databases in the organization and what data is stored there? What are the potential risks and weaknesses of the databases? Where should database connections be made from and in what manner? What privileged users should have access to the database?
Several different types of DAMs exist, each gathering data at different levels. Data may be gathered on the network, by libraries, by the operating system, or directly from memory. Sniffing database traffic at the network level provides better isolation, but requires the database connections to be unencrypted, which should be avoided if possible. DAMs that gather information directly from memory are a good choice because they require no changes to the current network and are able to intercept any means of access to the database service. If the blocking and prevention of suspected attacks is available, the cost and risk of a successful attack must be weighed against the cost and risk of blocking a legitimate request.
CERTIFICATION OBJECTIVE 4.16
Service Enabled
All unnecessary and unused network services should be turned off. Any insecure service protocol such as HTTP or SNMP should be used on top of secure protocols such as SSL. Unused or unnecessary features should be disabled as well. Make sure that the software or firmware of any network-connected devices is up to date. Any additional security features such as CAPTCHA and reCAPTCHA should be configured and enabled if possible. Remember, any network-connected device could be running insecure or unconfigured services and may introduce a security vulnerability.
CERTIFICATION OBJECTIVE 4.17
WS-Security
SOAP is a protocol that employs XML, allowing web services to send and receive structured information. SOAP by itself is very insecure. Web Services Security (WSSecurity) can provide authentication, integrity, confidentiality, and nonrepudiation for web services using SOAP. However, WS-Security is just a collection of security mechanisms for signing, encrypting, and authenticating SOAP messages. Merely using WS-Security does not guarantee security.
Authentication is critical and should be performed in almost all circumstances. Simple authentication can be achieved with usernames and password tokens. Passwords and usernames should always be encrypted. Furthermore, always use PasswordDigest in favor of PasswordText to avoid clear-text passwords. Authentication of one or both parties can be achieved by using X.509 certificates. Authentication is accomplished by including an X.509 certificate and a piece of information signed with the certificate’s private key.
WS-Security is very flexible and allows the encryption and signing of the underlying XML document or only parts of it. This is useful because it allows the generation of a single message with different portions readable by different parties. If possible, always sign and encrypt the entire underlying XML document. Encryption should not be applied without a signature, if possible, because encrypted information can still be modified or replayed. The order of signing and encrypting is also important. Generally, the best protection is achieved by signing the message and then encrypting the message and the signature. Stronger encryption algorithms such as AES should be used instead of older algorithms such as 3DES. Do not transmit symmetric keys over the network, if possible. If transmission of symmetric keys is required, always encrypt the symmetric key with the recipient’s public key and be sure to sign the message.
CERTIFICATION SUMMARY
In this chapter, we covered the concepts of advanced network design, the implications of complex network security solutions, and secure data flows. We also addressed secure DNS, secure directory services, and items to consider when designing a network such as multitier data designs. We covered logical and physical deployment diagrams, secure infrastructure designs, storage integration, and advanced configuration of networking devices (routers, switches, and so on). Advanced concepts such as ESB, SOA, and SIEM were addressed. We discussed database access monitors, purging unnecessary services that may be enabled, and WS-Security.
Two-Minute Drill
Advanced Network Design
- A good network design can help you in your efforts to secure and defend your organization.
- Remote access traffic must be segmented and never treated as “trusted” traffic until you are sure it is malware free and verified.
- Where you place security devices such as firewalls and IDS/IPS devices will have a large impact on the amount and type of traffic you see.
- Network-enabled SCADA devices should be separated from “normal” network traffic and shielded from public traffic.
- Availability is critical for VoIP traffic, and you must ensure your design allows for security, quality of service, and availability.
- IPv6 has a number of security enhancements such as IPSec, limiting packet fragmentation to hosts, and better support for QoS.
Complex Network Security Solutions for Data Flow
- The proper application of proxy servers and careful monitoring can help prevent data leakage.
- Monitoring encrypted web traffic can be difficult, but can be done with specialized proxies.
Secure Data Flows
- Always encrypt sensitive data in transit and at rest.
- Use tested and validated encryption algorithms and avoid “proprietary” solutions.
- Isolate sensitive data traffic using VLANs.
Secure DNS
- A number of techniques can be used for maintaining a secure DNS server, such as ensuring software is up to date, separating internal/external DNS, using TSIG for transaction authentication, restricting zone transfers, and implementing DNSSEC.
- Domain Name System Security Extensions (DNSSEC) is a set of extensions to the DNS service that provide origin authentication, integrity, and backward compatibility
Secure Directory Services
- General best practices for securing LDAP include using SASL over simple bind, disabling old accounts, eliminating password sharing, separating public and private LDAP functions, and limiting the size of search results
- General best practices for securing AD include disabling all network transport protocols except TCP/IP, removing or disabling all unnecessary services such as IIS, and disabling anonymous access.
- Federated Identity allows an organization, or service provider, to securely identify users by delegating the authentication of users to another trusted organization called the identity provider.
- Single Sign On (SSO) allows users to perform a single authentication and use the granted authorization for multiple applications within a single domain.
Network Design Consideration
- Designing a secure network begins in the planning phase.
- Consider your network security needs during the building layout and design if possible.
- Managing the physical implementation of the network is vital to ensuring a secure network.
Multitier Networking Data Design Considerations
- A multitier network design can provide different security “zones” that allow better monitoring and control of network traffic.
- Although most organizations employ a single DMZ between the Internet and the organization, it is important to consider additional security zones— separating the server farm from regular user traffic, for example.
Logical and Physical Deployment Diagrams
- A logical deployment diagram describes network resources and the desired network topology in a logical manner, with a focus on showing connections between devices in a readable manner.
- Physical deployment diagrams specify the exact position and placement of network servers, routers, links, and other resources.
Secure Infrastructure Design
- Before designing a secure infrastructure, you must consider the components in your network, access paths, connections, sensitivity of data being stored/ transmitted, and so on.
- Placement of security devices (such as firewalls and IDS) is critical.
- Consider using network taps instead of SPAN ports.
Storage Integration
- Network storage devices often run common network file services such as SMB/CIFS and AFP. Disable any file services and protocols you don’t need.
- Separate storage traffic from other network traffic when possible.
- Zoning can be used to help control access to storage devices.
Advanced Configuration of Routers, Switches, and Other
Network Devices
- Remember to secure management interfaces and protocols on network devices.
- A few tips for securing network devices include disabling anonymous access, changing default usernames and passwords, disabling unnecessary services, enforcing the use of secure protocols, and limiting access to management interfaces and capabilities.
- Disable dynamic trunking capabilities and switchport negotiation to deter VLAN-hopping attacks.
ESB
- Enterprise Service Bus (ESB) is a type of architecture for facilitating communications between applications or web services in a Service Oriented Architecture (SOA).
- Use mutual authentication for ESB connections.
- Limiting message rates can help mitigate the effects of flooding attacks.
SOA
- Service Oriented Architecture (SOA) is a set of requirements and principles to facilitate the development of interoperable software services.
- SOA calls for authentication to be performed at the software service level with centrally managed identity credentials.
- There is no silver bullet to ensure a secure SOA. Every project has different requirements and requires careful planning, review, and development.
SIEM
- Security Information and Event Management (SIEM) utilities analyze and correlate logs and events from multiple sources and provide real-time alerting features.
- Carefully consider the amount, type, and level of log information you are collecting in your SIEM solution. Too much data becomes overwhelming, and too little data does not provide you with a complete picture.
Database Access Monitor (DAM)
- A DAM monitors database transactions for things such as errors, patterns of suspicious or malicious activity, and fraud.
- A DAM that gathers data from memory rather than log files or network traffic is able to provide the best monitoring of database access.
Service Enabled
- Always turn off any unnecessary or unused network services.
WS-Security
- Web Services Security (WS-Security) can provide authentication, integrity, confidentiality, and nonrepudiation for web services using SOAP.
- WS-Security is a collection of security mechanisms for signing, encrypting, and authenticating SOAP messages. Using WS-Security does not guarantee security.
SELF TEST
The following questions will help you measure your understanding of the material presented in this chapter. Read all the choices carefully because there might be more than one correct answer. Choose all correct answers for each question.
- Segmenting remote access traffic allows you to do which of the following?
A. Treat remote access traffic as potentially hostile.
B. Filter traffic through a firewall and IDS/IPS.
C. Verify the patch and antivirus status of remote users before allowing them to connect to the organizational network.
D. All of the above. - If you’re looking to get maximum visibility into attacks launched at your organization from hostile Internet sources, where would you place an IDS/IPS?
A. Right behind the main firewall between your organization and the Internet
B. Between your server farm and user base
C. In front of the main firewall between your organization and the Internet
D. In the DMZ, preferably next to a web server - Which of the following is not a best practice when securing SCADA networks?
A. Replace default passwords.
B. Filter traffic based on MAC address.
C. Place SCADA devices on VLANs with other Internet-visible traffic.
D. Perform regular auditing of devices. - Which of the following is an advantage of IPv6 over IPv4?
A. Smaller address space
B. Widely used by most organizations
C. Support for IPSec and better QoS capabilities
D. Protocol and Type of Service fields in header - Which of the following is an advantage transparent proxies have over traditional proxies?
A. No special configuration is needed for clients.
B. Can monitor traffic flows for sensitive data.
C. Web caching capabilities save bandwidth.
D. Able to filter allowed connections. - TSIG is used for:
A. Sharing public keys between DNS servers
B. Authenticating updates to a dynamic DNS database
C. Validating requests for DNS resolution
D. Using a one-way hashing function to timestamp packets - DNS zone transfers:
A. Should be granted to any requesting client
B. Provide full and complete data records to all clients
C. Should require a TSIG signature where possible
D. Should flow from secondary to primary DNS servers only - Which if the following is the most effective approach for securing Active Directory?
A. Using separate LDAP servers for publicly accessible information
B. Limiting the size of search results
C. Replicating domain controllers to a separate physical location
D. Careful delegation of administration - What is the best time to consider the security impact of the physical implementation of your network?
A. During the building layout design process
B. When facility construction begins
C. After electrical wiring and HVAC installation are complete
D. Right before moving tenants into the building - Which of the following is not a method for implementing personnel access control?
A. Setting security alarms for restricted areas
B. Locking racks or the individual devices in racks
C. Employing patrols and implementing inspections of critical infrastructure
D. Using VLANs to control personnel access - A common multitier network architecture might consist of which of the following layers?
A. DMZ, SAN, and VLAN tier
B. DMZ, application tier, and data tier
C. NAS, DMZ, and data tier
D. Public tier, private tier, and FMZ - What is the first step in secure infrastructure design?
A. Determine the placement of firewalls and other perimeter devices.
B. Identify network components and their security needs.
C. Identify supported protocols.
D. Catalog applications that will be used within the network. - Which of the following is not a common network file system service that is typically supported by NAS devices?
A. SMB/CIFS
B. AFP
C. SFTP
D. LanMan - In zoning discussions, what does pWWN stand for?
A. Process World Wide Name
B. Port World Wide Name
C. Physical World Wide Name
D. Packet World Wide Name - Which of the following guidelines should be used when configuring routers and switches?
A. Do not enable DHCP or BOOTP for edge routers.
B. Use Telnet for access to management interfaces.
C. Disable MAC filtering on internal switches.
D. Configure ACLs to only monitor traffic originating from outside your network. - What are the two common types of VLAN-hopping attacks?
A. Switch spoofing and double tagging
B. MAC switching and reverse tagging
C. Route poisoning and DDoS
D. ARP spoofing and reverse VLAN injection - Where is the Open Shortest Path First (OSPF) routing protocol most commonly used?
A. As an internal routing protocol
B. Between gateway routers
C. Between DMZs and external firewalls
D. For dynamic routing updates given to remote access users - An ESB consists of which two main components?
A. VLANs and a SAN
B. Connectors and a routing engine
C. Authentication servers and application servers
D. Protocol translators and central management - Which of the following is not an example of a standardized SOA framework?
A. SOAP
B. CORBA
C. WCF
D. LDAP - Web Services Security (WS-Security) can provide which of the following for web services?
A. Nonrepudiation
B. Authentication
C. Confidentiality
D. All of the above
LAB QUESTION
Your organization is in the design stage of a new office building. The architects have asked you to provide a list of your concerns and recommendations for network cabling and communication closets. Create a list of recommendations and best practices the architects can fold into their building design.
Self Test Answers
- D. Segmenting network traffic allows you to treat remote access traffic as potentially hostile, filter traffic through a firewall and IDS/IPS, and verify the patch and antivirus status
of remote users before allowing them to connect to the organizational network.
A, B, and C on their own would not be correct. - C. The best place to view and analyze attacks originating from Internet sources is on your main network link between your firewall and your Internet connection.
A, B, and D do not provide adequate visibility into Internet-based attacks and are therefore incorrect. - C. You specifically want to avoid placing SCADA devices in situations where they are exposed to Internet-visible traffic such as a DMZ.
A, B, and D are all best practices for securing SCADA networks and are therefore incorrect answers. - C. IPv6 has support for IPSec and better QoS capabilities than IPv4.
A, B, and D are all incorrect. (A) and (B) are just not true, and (D) although true, is not related to the question. - A. Transparent proxies are “invisible” to clients and require no special configuration for use.
B, C, and D are all incorrect. Although they are true, they are not related to answering the question. - B. TSIG is used primarily for authenticating updates to a dynamic DNS database.
A, C, and D are all incorrect. Although these are valid DNS events, they are not related directly to TSIG. - C. TSIG can help authenticate zone transfers and should be used whenever possible.
A, B, and D are all incorrect. Zone transfers should never be granted to “any” requesting client. Not all clients should be given full and complete records, and transfers can flow from primary to secondary servers. - D. Careful delegation of administration is one of the most important tasks for setting up and maintaining a secure Active Directory implementation.
A, B, and C are all incorrect. Although all of these can improve security, it is still necessary to perform (D) making (D) the better answer. - A. During the building layout design process is the best time to consider the security impact of the physical implementation of your network.
B, C, and D are all incorrect because waiting that long in the construction process may cause you to miss opportunities to design and implement a secure physical infrastructure. - D. Using VLANs is not a method for implementing personal access control.
A, B, and C are all incorrect because they are all possible methods for implementing personal access control. - B. A common multitier architecture might consist of a DMZ, application tier, and data tier.
A, C, and D are all incorrect. SAN (A) and NAS (C) are not tiers, and FMZ (D) is a pure distractor with no meaning. - B. Identifying network components and their security needs is the first step in secure infrastructure design.
A, C, and D are all incorrect. Although these are all steps, (B) is the first step among these options. - D. LanMan is the hash used by Windows to store passwords in versions prior to NT.
A, B, and C are all incorrect because they are all common network file system services that are typically supporting by NAS devices. - B. pWWN stands for port World Wide Name.
A, C, and D are all incorrect. They are all distractors created from terms associated with the material, but not correct for this acronym. - A. DHCP and BOOTP should not be enabled on edge routers.
B, C, and D are all incorrect because they are all insecure practices. - A. The two main types of VLAN-hopping attacks are switch spoofing and double tagging.
B, C, and D are all incorrect. - A. Open Shortest Path First (OSPF) routing protocol is most commonly used as an internal routing protocol.
B, C, and D are all incorrect as those are not typically areas where OSPF is used. - B. An ESB consists of connectors and a routing engine.
A, C, and D are all incorrect. These are common term distractors associated with the material, but not with this usage. - D. Lightweight Directory Access Protocol (LDAP) is an application protocol for querying and modifying data of directory services—it is not an example of a standardized SOA framework.
A, B, and C are incorrect because they are all examples of a standardized SOA framework. Self Test Answers 179 - D. Web Services Security (WS-Security) can provide nonrepudiation, authentication, and confidentiality for web services.
A, B, and C are incorrect as each is correct, making all the above a better answer.
LAB ANSWER
Although answers may vary, they should be based around a network diagram, an analysis of traffic levels and equipment placement. Other elements, such as cable run length, and cooling for the communication closet need to be included.
Excerpted from CASP CompTIA Advanced Security Practitioner Certification Study Guide by Wm. Arthur Conklin, et al (McGraw-Hill; 2012) with permission from McGraw-Hill.
In this Series
- Book Excerpt: Advanced Network Design, Chapter 4: Infrastructure
- Free Valentine's Day cybersecurity cards: Keep your love secure!
- How to design effective cybersecurity policies
- What is attack surface management and how it makes the enterprise more secure
- Is a cybersecurity boot camp worth it?
- The aftermath: An analysis of recent security breaches
- Understanding cybersecurity breaches: Types, common causes and potential risks
- Breaking the Silo: Integrating Email Security with XDR
- What is Security Service Edge (SSE)?
- Cybersecurity in Biden’s era
- Password security: Using Active Directory password policy
- Inside a DDoS attack against a bank: What happened and how it was stopped
- Inside Capital One’s game-changing breach: What happened and key lessons
- A DevSecOps process for ransomware prevention
- What is Digital Risk Protection (DRP)?
- How to choose and harden your VPN: Best practices from NSA & CISA
- Will immersive technology evolve or solve cybercrime?
- Twitch and YouTube abuse: How to stop online harassment
- Can your personality indicate how you’ll react to a cyberthreat?
- The 5 biggest cryptocurrency heists of all time
- Pay GDPR? No thanks, we’d rather pay cybercriminals
- Customer data protection: A comprehensive cybersecurity guide for companies
- Online certification opportunities: 4 vendors who offer online certification exams [updated 2021]
- FLoC delayed: what does this mean for security and privacy?
- Stolen company credentials used within hours, study says
- Don’t use CAPTCHA? Here are 9 CAPTCHA alternatives
- 10 ways to build a cybersecurity team that sticks
- Verizon DBIR 2021 summary: 7 things you should know
- 2021 cybersecurity executive order: Everything you need to know
- Kali Linux: Top 5 tools for stress testing
- Android security: 7 tips and tricks to secure you and your workforce [updated 2021]
- Mobile emulator farms: What are they and how they work
- 3 tracking technologies and their impact on privacy
- In-game currency & money laundering schemes: Fortnite, World of Warcraft & more
- Quantitative risk analysis [updated 2021]
- Understanding DNS sinkholes - A weapon against malware [updated 2021]
- Python for network penetration testing: An overview
- Python for exploit development: Common vulnerabilities and exploits
- Python for exploit development: All about buffer overflows
- Python language basics: understanding exception handling
- Python for pentesting: Programming, exploits and attacks
- Increasing security by hardening the CI/CD build infrastructure
- Pros and cons of public vs internal container image repositories
- CI/CD container security considerations
- Vulnerability scanning inside and outside the container
- How Docker primitives secure container environments
- Top 4 Zapier security risks
- Common container misconfigurations and how to prevent them
- Building container images using Dockerfile best practices
- Securing containers using Docker isolation
- Introduction to container security
Get certified and advance your career
- Exam Pass Guarantee
- Live instruction
- CompTIA, ISACA, ISC2, Cisco, Microsoft and more!
General security
Free Valentine's Day cybersecurity cards: Keep your love secure!
General security
General security