Case Studies. (linksys router cisco vpn)
|
Case StudiesPresented next are four security designs to address four different business situations. Each was chosen to illustrate the need to vary your designs based on the specific business needs of an organization. Case Study 1: Telecommuter Who Is Using a Broadband ConnectionThe situation presented in Figure 18.1 shows an increasingly common way for users to access private corporate network resources. The user has subscribed to a cable company's broadband Internet service and is using this connection to work from home. These types of connections are becoming increasingly popular and represent a significantly different security problem from the slow dial-up connections they are replacing. Figure 18.1. In this design, a telecommuting user relies on a Virtual Private Network (VPN) to tunnel across the Internet to reach the corporate network.
Previously, home computer users had limited exposure to Internet attacks because they were only accessible while they were dialed-in to the Internet. A potential attacker would need to time his attack to coincide with the time the user was using the Internet. This is not true with broadband services, such as cable and DSL. These types of connections, much like typical office Internet connections, are always on, making it much easier for the attacker to access the home computer. Because of this problem, combined with the low security awareness of the typical home computer user, broadband-connected home computers have become a frequent target of computer attackers, which has resulted in many home user systems becoming compromised. These systems have then been used to commit other acts of cyberattack, including participating in denial of service (DoS) attacks. The problem of home computer security has become important to companies as they begin to allow their employees to access private network resources from home. If home computers become compromised, the attacker can use them to circumvent the network's perimeter security. The user's companyin this case, Big Company, Inc.is concerned about these security problems but wants to allow the employee the flexibility of working from home on a high-speed connection. The company has asked us to create a secure home network design for the user. The following is the design criteria the company provided to us:
The company is also specifically worried about the following issues:
To address these concerns, this design uses several perimeter security techniques to secure the home network. To start, a cable modem/DSL router has been placed between the home computer and the cable modem. These devices have become popular because they allow multiple home computers to share a broadband account, but most also include basic firewall functionality. For this case study, a Linksys Etherfast cable/DSL router has been chosen. Note that this device does not include wireless LAN capability. This was intentional because the company did not want to take on the additional risk of wireless networks at its employees' homes. Because this home network is only used to access the Internet and does not host public network services, no externally initiated connections are needed. This enables us to use the default configuration of the cable/DSL router, which only allows connections initiated from the internal network to proceed. This defense measure prevents a broad range of attacks from proceeding. Some employees, though, may be tempted to modify this configuration to support peer-to-peer file sharing programs, which require an open port to work efficiently. Employees who use this service will need to be specifically cautioned against it because it would significantly weaken the security of the solution. In addition to the cable/DSL router, the design also calls for a personal firewall product to be installed on the user's home computer. Personal firewalls such as BlackICE (http://www.iss.net), ZoneAlarm (http://www.zonelabs.com), and Tiny (http://www.tinysoftware.com) enable you to specify which applications are allowed to send and receive information over the network. For instance, we can tell the personal firewall to only allow connections destined to hosts on port 80 from Internet Explorer or Netscape Communicator. To enable the home user to securely access private corporate resources, the Check Point SecuRemote client is installed on the user's home computer and is configured to establish an AES-based IPSec VPN connection to the corporate firewall whenever a packet needs to be sent to the corporate network. Basic username/password authentication is used whenever the VPN is established. The SecuRemote client supports stronger, certificate-based authentication but requires a Public Key Infrastructure (PKI). The last element of this security architecture is the installation of an antivirus product such as Symantec Norton AntiVirus on the home computer. With the cable/DSL router and personal firewall products preventing most forms of direct attack, the next most likely way of gaining access to the home computer is the introduction of some form of malicious code. If the user downloads a program from the Internet that contains a Trojan horse or receives an email with a virus attached, the computer can still become compromised. To help prevent this, the AntiVirus tool has been configured to scan each downloaded file and each received email message for known malicious code patterns. Because these types of products are only as good as the content of their malicious code signature database, the antivirus tool has also been configured to check for new malicious code signatures on a daily basis. As you can see from this description, even with small networks, you still need to consider all the design criteria when building the security perimeter. Understanding what you need to protect, how it might be attacked, and how much effort you should spend to secure it are fundamental issues that affect every design you create. In this network, what we needed to protect was narrow and consisted of a single workstation. We were specifically concerned with a direct attack from the Internet, plus the indirect attack from malicious code. Because our budget was small, we had to limit ourselves to inexpensive measures. Given these constraints, we were still able to come up with a design that should be highly effective at protecting the user's home computer while allowing secure access to the corporate network. Case Study 2: A Small Business That Has a Basic Internet PresenceIn this case study, a small sales company wants to set up an Internet connection but does not intend to sell products directly over the Internet. The owner of the business has read several horror stories about companies being taken over by attackers and has specifically asked for as secure a design as possible, but he does not have a large budget. Following are the specific design requirements and business needs the company has established:
Note Burstable T1 lines allow the full 1.544Mbps of a T1 line to be used some of the time, but the ISP only guarantees the continuous bandwidth level that has been agreed upon. The resulting design is shown in Figure 18.2. The IT resources of the company are limited to a dozen PCs running Windows, two Windows servers acting as primary and backup domain controllers, and a network printer. The following features have been added to the network to meet the design requirements:
Figure 18.2. In this design, a small business outsources the hosting of Internet-accessible services to a third party. The first line of defense for the network is the Nokia IP350, which runs a version of the Check Point Next Generation (NG) FireWall software. We have installed a T1 card in the Nokia to allow it to act as both the border router and the external firewall. Of course, if the Nokia were to become compromised, the entire network would be exposed to the Internet. This is a design compromise that has been made to reduce cost; the money that would have been spent on the router can now be spent on a more sophisticated firewall. Other security measures, such as the IDS, will be counted on to provide the defense in depth necessary to back up the Nokia. The rulebase for the Nokia is shown in Table 18.1.
This rulebase has three main features. First, there are no rules with the Internet as a source, which prevents external attackers from initiating a connection to the company's internal computers. Second, all web and FTP connections from the LAN must be proxied through the web cache server before they can reach the Internet, which allows us to configure the web cache server to restrict which websites the employees can visit and provides the additional security benefit of terminating the external website connection at the web cache server instead of a workstation's browser, thereby preventing some malicious website attacks. Last, the rulebase makes no allowance for remote management or monitoring for any of the security devices. This network is sufficiently small, so a decision has been made to administer and monitor each system from its respective console. The next device that needs to be discussed is the web cache server. To keep the cost down, this server has been implemented entirely from open source products. A PC that is running a hardened version of Red Hat Linux server hosts the open source Squid Web Cache Proxy software (http://www.squid-cache.org). This process is the only one running on the server that is listening to network ports. Squid supports proxying of HTTP, HTTPS, and FTP connections and can limit by IP address the computers that are able to make use of its services. In this case, the proxy has been configured to allow hosts in the IP range of the workstations to connect to it. Squid also can limit which web and FTP sites users can visit. Currently, this company's users are allowed to surf to any site, but the company has reserved the right to block access to any sites it deems inappropriate or unsafe. In addition to the workstations, the IDS has been allowed to use the web cache server, but Squid has been configured to allow it to connect to only the Snort website (http://www.snort.org) and the company's website. The last specific security device to talk about is the IDS. Like the web cache server, the IDS is implemented using only open source software. Red Hat Linux is again used as the operating system to host the Snort IDS software. Snort is a highly capable IDS, especially when its signature database is kept up to date. Luckily, the Snort community is active, and it continually updates the Snort signatures. It is not uncommon for a new Snort signature to be available for a new attack before any of the commercial providers has been able to update its signature databases. The reason the web cache has been configured to allow the IDS to connect to the Snort website is to allow the latest Snort signatures to be conveniently downloaded. You might notice that no web, mail, or DNS servers are on the network. All these services have been outsourced to NTT/Verio, a web hosting company. For a small monthly fee, NTT/Verio provides space on one of its web servers to host the company's website. Administration of the website is performed using Microsoft FrontPage. In addition to the website, NTT/Verio provides WebMail, a web-based email system, which allows employees to send and receive email using their web browsers. By outsourcing these services, the design eliminates the need to handle externally originated connections, reducing the risk of network compromise substantially. However, it does require that the company trust NTT/Verio to secure the web and email services. To provide one additional level of protection, a small shell script has been placed on the IDS sensor that checks whether the home page of the website has been modified. If it has, the shell script generates an alert, providing a limited amount of protection should the NTT/Verio-maintained website become corrupted. This case study shows some of the compromises you might have to make due to the business needs of the organization. Not every site requires three layers of firewalls with a full-time security administrator. In this case, it made more sense to outsource the harder elements to secure. It is unlikely that this company would dedicate the effort to properly administer the security of its public services. Outsourcing these services to a firm that provides them full time was a more secure solution. Always remember that each design must be attentive to the needs of the situation. Case Study 3: A Small E-Commerce SiteIn this case study, a small organization has decided that it could dramatically boost sales by accepting orders over the Internet. At the same time, it is concerned with some of the news reports about cybercrime and the possibility that private customer data might be stolen, opening up the potential for lawsuits. The company has asked us to create a design that allows it to sell products over the Internet while protecting customer data. It has provided a reasonable but not overly large budget for the design. These are the design guidelines the company has established for the assignment:
The resulting design is shown in Figure 18.3 and shows a fairly classic network security design, although certain security design features are not visible from the diagram. Figure 18.3. In this design, a small e-commerce site uses several defensive measures to protect customer data.
Here is a quick description of the major features of the design:
Traffic that is entering the network must first pass through the border router; therefore, it is the first device we can use to enforce access control for the network. A thorough discussion of how to securely configure routers is included in Chapter 6, "The Role of a Router," so we will not go into depth about how this router should be configured. However, it is worth mentioning that ingress filters have been installed on the router to block packets that have illegal addresses. In addition to the ingress filters, an egress filter has been put in place to block outbound packets if they do not have a valid source IP address. The purpose of this egress filter is to make it harder for the site to be used to attack other sites should one of the servers be compromised. The primary security device for this network is the Juniper NetScreen-204 firewall appliance. The NetScreen-204 comes with four Fast Ethernet interfaces, which we have used to create four security zones for this network:
The rulebase on the firewall controls what traffic can flow between each of these zones. Table 18.2 shows the rules we are using to secure the network.
A lot is going on in this rulebase, so let's go over it step by step. The first three rules are designed to allow the public to access the public servers. The fourth rule allows the order server to retrieve customer transactions from the website. The company has built a custom e-commerce application that takes the following steps to protect customer information. When the web server accepts a customer transaction, it writes the details of the transaction to a file, which it then places in a special directory. This directory is only accessible to two accounts on the web server: the account that the web software is running as, and an account created for the order server. The web server is running a Secure Shell (SSH) daemon to allow the order server to periodically log in and retrieve the customer transaction files. In this way, the customer details are swept off the more exposed web server to the order server where they can be better protected. Using this arrangement, even if an attacker did gain control of the web server, he would only be able to capture a few customer transactions. The fifth rule on the firewall allows the internal email server to retrieve inbound mail messages from the mail relay server. Normally, a mail relay server would use Simple Mail Transfer Protocol (SMTP) to transfer inbound messages to an internal mail server, but a security decision was made not to allow traffic to originate from the Public Services network to the internal network, which should block an attacker from accessing the internal network, even if she manages to compromise one of the public servers. Still, we need to allow the network's users to receive mail. To accomplish this, the internal email server periodically retrieves queued messages from the mail relay server using the same method that the order server uses to retrieve information from the web server. It logs on to the mail relay server using the SSH protocol and downloads the queued messages. To enable outbound email, the sixth rule allows the internal mail server to send SMTP information to the Internet. In some situations, this might open up the internal mail server to attack from a malicious mail server. However, in this case, the risk is minimized due to our choice of firewall. The NetScreen-204 includes advanced packet inspection techniques such as malformed packet protection and protocol anomaly detection. These features should limit (though not eliminate) the ability for an attacker to compromise the mail server. The seventh rule allows the internal DNS server to resolve DNS requests for external sites. Just like with SMTP, the NetScreen-204's packet inspection techniques will be needed to protect this network conversation. The eighth rule allows the workstations to access web and FTP services on the Internet. Again, the NetScreen-204's packet inspection capabilities will provide the protection necessary to protect the workstations as they go out on the Internet. The ninth rule allows any device on the network to send Syslog traffic to the log server. This rule allows all security log entries to be consolidated on a single server and is especially important for consolidating the log entries for the multiple IDS sensors deployed on the network. Consolidating the logs simplifies their analysis and makes it easier to defend against log modification. When an attacker gains control of a server, one of the first things he will do is modify the log files to erase evidence of his attack. Moving the log entries to the log server prevents this from happening. It also makes it easier to detect malicious activity. By centralizing all the log entries, it becomes possible to look for attack behavior across systems. A special process runs on the log server to look at the incoming log entries for these signs of attack. The log server has a modem attached to allow it to dial a beeper service to notify administrators when an attack has been detected. The tenth rule allows the management console to log in to all the security devices on the network, including the IDS systems and the border router using the SSH protocol; this, in turn, allows each of these systems to be remotely administered. The firewall can also be remotely administered using SSH. The last rule is the standard "deny all" rule. If none of the other rules match, this rule denies and logs the traffic. This rule enforces the design concept of least privilege. The firewall and router do a good job of limiting access to the network, but they cannot prevent access to the public services on the network. Public services such as web, mail, and DNS must be provided to allow customers to place their Internet orders. This also allows attackers to communicate with these services. In acknowledgment of the additional risk that the public servers are exposed to, two additional security controls have been established for this zone. First, an aggressive patch management program has been instituted for all publicly accessible servers. Whenever a patch is released to correct a serious vulnerability in any software running on these servers, it is expeditiously tested and then deployed as soon as possible. If testing determines that the patch does not work properly though, other mitigating controls will need to be developed on a case-by-case basis. The second control is the installation of Cisco's Security Agent, a host-based intrusion prevention system, on each of the public servers. As we discussed in Chapter 11, "Intrusion Prevention Systems," host-based IPS systems can often detect and prevent attacks that are imperceptible to firewalls and network-based IDS tools. Although they can be expensive, both to purchase and to maintain, their use here on the servers most likely to come under direct attack is justified. The public zone is not the only area of the network that we must protect. To provide additional security to the entire network, each network segment has an IDS installed on it. As with the previous case study, we have opted to use Snort as our IDS. This is the purpose for the rule just before the deny all rule. The management console needs to be able to download the latest signatures for the Snort sensors on a regular basis. In addition to the standard signatures, we are also adding a few custom signatures to detect traffic that is specifically unusual to our network, instead of relying purely on the default signatures. To understand how this might be useful, let's look at the sensor located on the management network. Only a limited amount of traffic should be traveling across this network segment. By deciding which traffic is allowed, we can set up signatures to look for traffic that is abnormal. If we limit our discussion to TCP traffic, the following packets should be allowed:
Any traffic that does not match one of these conditions is invalid and might indicate that an attacker has gotten past our other defense measures. To detect this, we can add custom signatures to our Management network Snort sensor. For example, to detect invalid TCP packets leaving the Management network, we add the following rules to the sensor (assume that the Management network has been allocated the IP range 192.168.10.0/24):
The combination of these five signatures triggers if any TCP packet is sent out of the management network that is not destined to an HTTP, HTTPS, or SSH server. Additional rules would need to be added to alert on unauthorized UDP and ICMP traffic. These types of signatures would produce many false positives if placed on a typical network. However, in the special case of the Management network, if any of these rules were to trigger, it would be possible that an attacker had gotten past the firewall. This idea can be extended to any network segment where it is convenient to enumerate legitimate traffic. Unlike our previous case study, this organization made the decision to rely heavily on e-business. Breaches in security could easily put the company out of business, which justified a larger investment in security but still did not free us up to spend money on security indiscriminately. We had to address the need to protect the network resources (especially the customer data) while keeping the need for security in balance with the other business requirements. The design that resulted provides defense in depth for the critical elements while keeping the overall expense of the design to a minimum. Case Study 4: A Complex E-Commerce SiteIn this last case study, we review the design produced by Rita Will as part of the requirements for her GCFW certification. As part of a practical assignment, GCFW students were asked to create a secure network architecture for a fictitious entity named GIAC Enterprises (GIACE), which is in the business of selling fortune cookie sayings. The requirements for the assignment included the following details:
Reading a bit into the assignment, we can extract the following design criteria:
The design that Rita submitted to meet these requirements was awarded honors by the GCFW Advisory Board and is shown in Figure 18.4. It can be downloaded at http://www.giac.org/practical/Rita_Will_GCFW.zip. It is a good design for securing the proposed network, but it is by no means the only way the network could have been secured. You need only look at the hundreds of student practicals posted at http://www.giac.org/GCFW.php to see just how many different ways this problem can be approached. Figure 18.4. Rita Will's GCFW design uses several security zones to enforce security across the network. Rita's design uses two firewalls to break the network into five major security zones. These are the Internet, the DMZ, the proxy layer, the security network, and the internal network. As a way of organizing this discussion, we describe the security features of each zone security separately. The InternetThis zone is unlabeled on the diagram, but it is the network formed between the border routers and the external firewall. Access to the Internet is provided by a pair of Cisco routers, which are using the Hot Standby Routing Protocol (HSRP) to allow one of the routers to take over for the other, should one of them fail. This is the first example of the redundancy features that have been included to make sure availability of the network is high. The routers are also being used to provide some packet filtering, including ingress and egress filters similar to the ones described in the previous case study. Located just in front of the routers are the border firewalls and two Cisco VPN concentrators. The concentrators allow suppliers, vendors, and employees to establish secure VPN connections to the network from the Internet and have been set up to fail over to each other should one stop working. The concentrators can use hardware accelerator cards to provide high performance and support several authentications systems. For this design, the token-based RSA SecurID system is being used to authenticate users prior to granting access. The border firewalls are a pair of Nokia firewall appliances that are also set up to fail over to each other. Like the Nokia appliance chosen in our second case study, these appliances run Check Point FireWall-1. The firewalls provide the first major access restrictions for the network. The size of the rulebase is largely due to the complexity of the design, so we will not go over it in detail. Here are the highpoints:
Using this rulebase, the firewalls effectively block all but the bare essential traffic from entering the GIACE network. This is a good implementation of the design concept least privilege. The DMZStrictly speaking, this zone should be referred to as a screened subnet because it is a network segment protected by a firewall; however, it is not an insecure area located between two secure areas. As Chapter 1, "Perimeter Security Fundamentals," mentions, these two terms are often used interchangeably. The zone holds all the servers that are accessible to external users. This includes the cacheflow reverse proxies, the public web servers, the external DNS servers, the external mail server, and the FTP drop box server. Each of these servers plays a public role for the GIACE network. This zone is considered a high-risk network segment. Because of this, extra security precautions have been implemented. To start with, all servers have been hardened by removing all unnecessary services and making sure that all the remaining services are as up to date as possible. Also, although not specifically mentioned in Rita's practical, presumably good vulnerability scanning and patch management practices are being performed on all the servers in this zone. This is to ensure that exploitable vulnerabilities are detected and eliminated as quickly as possible to reduce the window of opportunity available to attackers if vulnerabilities are discovered in any publicly accessible services. Next, a Snort IDS sensor has been located in the zone to watch for suspicious activity. If an attacker manages to circumvent some of the security controls in place, it is hoped that this sensor will provide a sufficient warning for the onsite staff to respond appropriately. The most important servers in the zone are the web servers. The web servers provide the primary interface between GIACE customers and GIACE. All sales transactions are conducted on these systems and then recorded on the internal network database servers. To enable the web servers to keep up with the expected volume of traffic, all external web requests first pass through one of the cacheflow servers. Blue Coat cacheflow servers are being used as reverse proxies for all connections from the Internet to the public websites. Cacheflow servers are designed to protect web servers while accelerating SSL connections. Because of the reverse proxies, external users never directly access the public web servers. Because many attacks against web servers require a direct TCP connection to the web server, placing the proxy between the Internet and the web server provides a substantial security improvement. By using the cacheflow servers, this design maximizes the performance and availability of the GIACE public website. Other servers on the network include the DNS, mail, and FTP servers. Each has some specific security controls worth mentioning. The DNS servers provide name resolution for external users. This network uses the split DNS concept, so these servers only contain records for publicly accessible servers. The external mail server sends and receives email from the Internet. It is implemented using a Sun Solaris server running Sendmail. To prevent malicious code from entering the network via email, the server runs Trend InterScan's VirusWall software. This software scans each incoming or outgoing email message for viruses. Scanning incoming mail for viruses is a powerful way of protecting the network from malicious code. Keep in mind, though, that scanners are only as good as their signature databases. The last server on the DMZ is the FTP drop box server. Suppliers, partners, and employees use this system to exchange files. Due to the rules in place on the border firewalls, this server is only accessible to internal users or to users who have established VPNs through the Cisco VPN concentrator. In addition, username/password authentication is required, adding a second layer of defense to protect the server. The Proxy LayerThe proxy layer protects internal and security network systems while allowing these systems to access network services located on other networks. Because this layer is directly on the path to the rest of the GIACE network, another Snort IDS sensor has been placed in front of it to watch for suspicious traffic. This provides some extra defense should an attacker get by the border firewalls. The proxy layer uses four devices to form a kind of proxy firewall. These include a cacheflow server, the internal mail server, a SOCKS server, and a bypass router. Each device allows different types of communications. Probably the most used from a traffic volume point of view is the cacheflow server. Similar to the cacheflow server used on the DMZ, this server proxies web requests for the internal and security network zones. Any internal system that needs to communicate with a web server must pass the request through the cacheflow server, which allows GIACE to restrict the websites that employees can access while protecting the requesting system from malicious websites. The internal mail server passes email into and out of the internal networks. By allowing only this system to send and receive email from the external mail server, this design limits the server's exposure to attack. In addition to the web proxy that the cacheflow servers provide, two SOCKS servers have been used to provide proxy services for SOCKS-aware applications. SOCKS is a standards-based protocol that performs network layer proxies at the transport layer. It is used in this design to provide external access for some proxy-aware applications, such as RealAudio. The last device is a Cisco 3660 router that allows network traffic that SOCKS or cacheflow servers cannot proxy. Located just behind the proxy layer is the internal firewall, which creates the remaining two security zones. Following is a summary of the proxy layer's rulebase:
This rulebase puts in place the access restrictions that form the two remaining security zones: the internal network and the security network. The Internal NetworkThe internal network holds all the internal systems, including employee workstations and GIACE databases. This network contains a broad amount of information that is valuable to GIACE. This is why it has been protected with so many layers of defense. The Security NetworkThe security network contains the systems that manage and monitor the security of the network. Two servers on the network manage the GIACE security devices. These servers must be carefully protected because they would grant an attacker the ability to circumvent almost all security controls on the network if one of them were to be compromised. Another system on the security network is the RSA ACE server, which provides the authentication service for the SecurID tokens. The ACE server is accessed when users VPN in to the Cisco VPN concentrator. It is also used by the internal firewall to authenticate the website maintainers prior to allowing them to log in to the DMZ. Next, this network holds a system that analyzes the results from the Snort IDS sensors. All alerts that the sensors generate are forwarded to this system. When a critical alert is received, the security network alerts a security administrator. The last two servers on the security network centralize and protect all security log data generated on the network. As we mentioned in the third case study, attackers like nothing better than to erase the evidence of their attacks. By moving log data into a protected place, we can prevent attackers from erasing their footprints. This design is pretty involved, so it is somewhat difficult to get your hands around all its security features. To recap, let's summarize some of the design's better qualities:
|
Network";) alert tcp $MgmtNet any -> any 23:79 (msg: "Invalid TCP Packet destination on Management
|
EAN: 2147483647
Pages: 230
- Integration Strategies and Tactics for Information Technology Governance
- Assessing Business-IT Alignment Maturity
- Linking the IT Balanced Scorecard to the Business Objectives at a Major Canadian Financial Group
- Technical Issues Related to IT Governance Tactics: Product Metrics, Measurements and Process Control
- Governance Structures for IT in the Health Care Industry