Internet Service Security Example

This example presents the fictitious simple Internet service of Mydomain.com, a new dot-com startup selling CDs and videos online. Mydomain.com employs the full range of servers covered throughout this chapter, including Web servers, FTP servers, Internet e-mail servers, DNS servers, and back-end servers.

This example includes before and after designs. The before design uses a standard public-facing model, and the after design implements security elements based around a Cisco Secure PIX Firewall. The example identifies the common attacks that can be carried out and the way that the proposed secure solution will deal with these attacks.

The network is hosted at an Internet service provider (ISP) and is connected straight into a hosting switch. The ISP provides no upstream security for hosted solutions. Security is the responsibility of the individual clients. The network diagram can be seen at Figure 11-2.

You can see in the network diagram in Figure 11-2 that the Mydomain.com solution consists of four servers. The Web and FTP services exist on the same server. Mydomain.com has been allocated 10 addresses in the 194.73.134.0/24 network that is registered to the ISP and is used for hosting solutions. The addresses allocated are 194.73.134.11/24 to 194.73.134.20/24.

This is a very common simple configuration for Web hosting from an ISP.

Initial Problems and Threats in the Internet Service Security Example

This solution is not ideal from a security point of view. As a general rule of thumb, the authors would never place an unprotected host on the public Internet. This solution places all four servers on the public Internet with public IP addresses. The IP address allocation is not within its own Layer 3 domain (VLAN/subnet); therefore, it is considered to be on the same broadcast domain as all of the other traffic within the 194.73.134.0/24 network. The following threats have been identified with this solution:

• Network threats— Because the servers are located on the public Internet, no security device is protecting the servers from a plethora of network threats. These threats include network intrusion attempts and DoS attacks. Without security devices protecting the solution, you are relying on the configuration of the actual server as the first and only line of defense.

• Operating systems vulnerabilities— Every operating system has known vulnerabilities. You have only to check the content of any security-focused web site to see the number of vulnerabilities that exist in every operating system. By placing these servers on the public Internet, you are making any security flaw in the operating system available for exploitation by potential hackers.

• Application vulnerabilities— Besides operating system vulnerabilities, there are application vulnerabilities. These vulnerabilities appertain to the applications running on the servers. Microsoft's Internet Information Server (IIS) is the standard Web server of choice for Windows NT and Windows 2000 servers. This application has numerous well-known vulnerabilities, and new patches are released frequently to protect against recently found vulnerabilities.

• Server-to-server communication— When the Web server communicates with the database server, this is classified as server-to-server communication. This traffic should never go across a public network. In the design in Figure 11-2, this traffic is going across the public network. Other machines that are not a part of the Mydomain.com network and within the same Layer 3 domain could easily capture this communication. This raises security issues.

• Access to back-end servers— Why make a server publicly accessible if only server-to-server communication is going to exist?

  Most back-end servers are not required to be accessed by outside hosts, because they might need only to communicate to other servers that are requesting their resources. The Mydomain.com service uses a Web server and a database server. The database server stores the stock details and is accessed by a Web page on the Web server. The public client is never required to access the server directly. In making it publicly accessible, you are also making every vulnerability on the server accessible.

Although there are obviously numerous threats to this solution, it is shocking to learn how many hosted solutions within the ISP environment are installed in this way. In security, there must always be a motive for attack. With low-risk and low-exposure sites, this motive might be so low as not to catch a hacker's attention.

Proposed Changes to the Internet Service Security Example

The most important change to implement in this solution is to place some sort of a firewall device in front of it. The term firewall can be defined as a device that simply protects internal networks from external threats. These devices normally carry out some sort of routing to route traffic from one interface to another and to perform packet or stateful inspection of traffic.

Now see what happens if you decide to implement a Cisco Secure PIX Firewall to protect the solution. You only need two interfaces—one internal and one external. The proposed network diagram can be seen in Figure 11-3.

You can see from the network diagram in Figure 11-3 that there is now a Cisco Secure PIX Firewall between the hosted switch and the Mydomain.com network. This PIX Firewall also carries out Network Address Translation (NAT) for the Mydomain.com network. The use of NAT means that the Mydomain.com network can now use RFC 1918-compliant private addressing. In this case, Mydomain.com has opted for the 192.168.0.0/24 network. This address space is not routed on the public Internet and can protect the identity and addressing of the Mydomain.com network.

NAT is a method where public IP addresses get translated into private IP addresses for address-hiding purposes. You can create a private network behind a NAT device, such as a router or a firewall, and create static translations between these private addresses and public addresses. This hides the private addresses of the network from the public Internet and provides a method where the private servers can communicate with each other over the private addresses. There are two types of NAT. These are one-to-one NAT and one-to-many NAT. One-to-many NAT is also known as Port Address Translation (PAT).

Access to the specific servers from the public Internet is permitted through what are called static translations. The PIX Firewall maintains static translations between the public and private addresses. These are manually configured on the PIX Firewall—one per translation. Because the database server is only involved in communication with the Web server, there is no need to provide a static translation for this server.

The static translations for this solution are displayed in Table 11-1.

In this case, a public client accessing www.mydomain.com receives the IP address of 194.73.134.10. The PIX Firewall intercepts this packet on the hosted switch, because the outside interface replies to Address Resolution Protocol (ARP) requests for its own interface and every other statically configured address. The PIX then redirects the packet to 192.168.0.10. This would be totally transparent to the public client.

You can further restrict access by configuring access lists on the PIX Firewall. On the PIX Firewall, these access lists are called conduits. You can allow specific traffic to specific servers and deny everything else. The PIX conduit command works in a similar way to the Router IOS access-list command. These conduits make up the basic firewall security policy for the solution. Table 11-2 shows the basic firewall security policy.

This policy allows only specific services to specific hosts. One point to mention is the last line in the policy in Table 11-2. This line allows Internet Control Message Protocol (ICMP) ping access from the address 195.92.1.250 to any host within the Mydomain.com hosted network. The address 195.92.1.250 is the egress point from the Mydomain.com offices, which are in a different physical location than the hosted network. This is so that the network staff at the office can ping the solution for monitoring purposes.

The configuration of the PIX Firewall is as follows:

PIX Version 5.1(2)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password 8Ry2YjIyt7RRXU24 encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
hostname pixfirewall
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol smtp 25
fixup protocol sqlnet 1521
names
pager lines 24
logging on
no logging timestamp
no logging standby
no logging console
no logging monitor
no logging buffered
no logging trap
no logging history
logging facility 20
logging queue 512
interface ethernet0 auto shutdown
interface ethernet1 auto
mtu outside 1500
mtu inside 1500
ip address outside 194.73.134.19 255.255.255.0
ip address inside 192.168.0.1 255.255.255.0
no failover
failover timeout 0:00:00
failover ip address outside 0.0.0.0
failover ip address inside 0.0.0.0
arp timeout 14400
static (inside,outside) 194.73.134.10 192.168.0.10 netmask 255.255.255.255 0 0
static (inside,outside) 194.73.134.11 192.168.0.11 netmask 255.255.255.255 0 0
static (inside,outside) 194.73.134.12 192.168.0.12 netmask 255.255.255.255 0 0
conduit permit tcp host 194.73.134.10 eq www any
conduit permit tcp host 194.73.134.10 eq ftp any
conduit permit tcp host 194.73.134.11 eq smtp any
conduit permit tcp host 194.73.134.11 eq pop3 any
conduit permit tcp host 194.73.134.12 eq domain any
conduit permit udp host 194.73.134.12 eq domain any
conduit permit icmp any host 195.92.1.250
timeout xlate 3:00:00 conn 1:00:00 half-closed 0:10:00 udp 0:02:00
timeout rpc 0:10:00 h323 0:05:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
isakmp identity hostname
telnet timeout 5
terminal width 80
Cryptochecksum:5884cc517ea6d0954099b857a8572c0c

If you are unsure about any of the configuration commands, refer to Chapter 4, “Cisco Secure PIX Firewall,” or visit the Cisco Secure PIX web site at www.cisco.com/go/pix.

Revised Problems and Threats in the Internet Service Security Example

With the introduction of the firewall between the public Internet and the Mydomain.com network, most of the network threats have been addressed. The following is a revision of the original list from the section “Initial Problems and Threats in the Internet Service Security Example,” now that the firewall has been added.

• Network threats— The servers are now located behind the firewall; therefore, they are not directly connected to the public Internet. Certain DoS attacks might still be possible, and the implementation of IDS technology will further protect the network. Ping access has been disallowed to all public addresses with the exception of the Mydomain.com offices. This is identified with the conduit permit icmp any host 195.92.1.250 command. This means that Internet clients are not able to ping the machines to check for their existence. Attackers running port scans have to force the port scan to check the addresses because the firewall blocks all ICMP Echo Request packets.

• Operating systems vulnerabilities— The servers are not on the public Internet, and access has been restricted to the specific ports on the specific servers. This means that any port-specific operating system vulnerability should now be protected.

• Application vulnerabilities— Application vulnerabilities might still exist. This is because the application vulnerability might be related to the specific port that is allowed through the firewall. For example, Microsoft's IIS is a TCP port 80 service. There have been vulnerabilities in the past related to certain URLs causing crashes on the server. These URLs would come over the allowed TCP port 80. The only way to keep up with application vulnerabilities is to ensure that the applications are kept up-to-date with the latest service packs and fixes, which are available from the application vendors' web sites.

• Server-to-server communication— All server-to-server communication is now over the private 192.168.0.0/24 network. No broadcasts or multicasts are propagated by the firewall. This alleviates the security threat.

• Access to back-end servers— The back-end server is no longer publicly accessible. The back-end server does not have a static translation associated with it, so communication can only occur with the back-end server from the Mydomain.com network. This removes the security threat to the back-end servers.

In this example, you have seen a very basic Web installation, identified the security threats posed to this network, and implemented a proposed solution. It is very easy to reduce 95 percent of all threats from the Internet and very hard to protect against the remaining 5 percent. By simply implementing a firewall, you can reduce many risks associated with Internet security.

The remaining sections in this chapter cover the individual Internet services and the threats posed to these specific services.