Section 2.9 Firewalls and the Corporate Moat

   


2.9 Firewalls and the Corporate Moat

graphics/fivedangerlevel.gif

The popular practice now is to have one point of access from the corporate (or agency) network to the Internet with a carefully configured firewall at that point. Setting up a firewall on Linux using IP Chains is discussed in "Firewalls with IP Chains and DMZ" on page 514. Inside the firewall are dozens, hundreds, or thousands of insecure systems safe from total disaster only if three things remain true:

  1. The firewall blocks absolutely every dangerous packet from coming in from the Internet. There are many covert ways to get through most firewalls.

  2. There is absolutely no other path besides the firewall between the Internet and the corporate network. There are almost always one or more PCs or laptops with modems on the network. What about SSH connections, telnet connections, and VPNs?

  3. There are no attacks from insiders, such as disgruntled and fired employees and suppliers with access. There will be such attacks.

These things rarely remain true. This section is intended to explain the danger of betting one's company on these assumptions. It offers solutions to protect against these assumptions being false, and how to determine if these assumptions are false.

The presence of a firewall is not a cure-all and should not be an excuse to allow insecure systems behind it.


2.9.1 Stopping End Runs Around Firewalls

graphics/fivedangerlevel.gif

The best way into an organization's network might not be the front door, but via a modem into some desktop PC, according to the Winter 1999 CSI/FBI Computer Crime and Security and Survey quoted by SecureLogix. I call this an end run around firewalls, from the U.S. football term for moving the ball around the main body of players. It also might be called a back door.

The term firewall, as used in computer security, means a system that separates a trusted network, such as the organization's network, from an untrusted network, such as the Internet. It determines which systems (IP addresses and host names) on the untrusted network are allowed to connect to which systems on the trusted network using which services (such as http, ssh, e-mail, telnet, etc.). Some firewalls have additional capabilities.


When a system is protected by a firewall, the intent is that all interaction with the outside world occurs through that special machine. It can block access to certain internal ports, redirect known ports to protected ports, filter incoming data to check for viruses, and do other important and vital functions. You know all this.

However, this carefully set-up defense can be compromised by some knucklehead with an unsecured laptop and a phone line. If you have mobile users, take care to harden their systems as well. Enable TCP Wrappers, disable unneeded services including telnet and FTP, install SSH, and follow the suggestions in this book which are appropriate for securing a mobile computer.

It has been suggested that it would be easy to put an entry in /etc/ppp/if-up to turn off the eth0 interface, and an entry in if-down to turn it back on. Some say, "This way, there is not a route between the modem and the corporate Ethernet." Although that will stop some crackers, a clever one still could plant a Trojan horse in the laptop that waits for eth0 to come back on or turn it on itself. Remember, it only takes one crack in the dam to start a flood. If a Trojan horse gets installed on a mobile computer, and that computer then gets connected to your in-house network, your whole network has been compromised.

Regarding access points behind the firewall, a bit of common sense is needed. If you have modems on machines inside the firewall, they are a primary point for attack. Instead, modems should be in the DMZ, as discussed in "Firewalls with IP Chains and DMZ" on page 514. Virtual Private Network (VPN) software associated with those dial-in lines could assist in keeping your network secure. The VPN then would be between a laptop and your internal network. There are VPN packages available for Linux. Some of these are examined in "Virtual Private Networks (VPNs)" on page 422.

Another possibility is for those company systems with the modems that offer dial-in access to be configured as firewalls themselves. Typically, the only accounts on the system (besides root) that would allow logging in would have pppd, the PPP daemon, for their login shells. For additional protection, place these systems in your Demilitarized Zone (DMZ) so that there is a separate firewall between these modem-hosting systems and your internal network. For additional details on DMZ configuration see "Firewalls with IP Chains and DMZ" on page 514.

The firewall rules then would allow only traffic to ports such as SSH and other encrypted secure protocols like https, imaps (SSL-wrapped IMAP) and pop3s (SSL-wrapped POP3). (See "POP and IMAP Servers" on page 204.) These systems also would need to allow UDP port 53 (DNS requests) to originate from the PPP interfaces for your dial-in users (laptops and home systems).

Dial-out phone lines behind a firewall also are a security weakness. Networking is a two-way pipe. If data can get out, it can also get back in. (But you do not want your confidential data to get out either.)

There are some very helpful tools for using a modem to do automatic dialing and so forth, especially in telemarketing instances. However, normally you cannot control on a moment-by-moment basis what your users will do. It will not be long before someone figures out how to dial his local Internet provider and circumvent all the security you have so carefully configured. One possibility would be to ensure that the modem devices are owned by root and mode 600 with tightly controlled software to access them. Typically this would be a set-UID to root C program or Perl script that would allow dialing only to approved phone numbers.

For nonmobile computers, consider removing all modems and floppy drives and the pppd, diald, cu, and tip programs, and any other software supporting modems from the machine. (Remove the equivalent software on non-Linux platforms.) Consider removing the modem devices (typically /dev/cua* and /dev/ttyS*) and disabling them in the CMOS (BIOS). The later is discussed in "CMOS Reconfiguration" on page 126.


Besides someone "illegally" bridging around the firewall with their own modem or even their own T1, there are a variety of ways to tunnel through the firewall to evade your protection of company assets. These techniques use a port that the firewall does allow, such as 23 (telnet) or 80 (www) by running a program other than the standard telnet or browser on top of it. The pppd program works well for this; it simply establishes a new "network" device that they route all of their traffic through, immune from your protection. There is even a helpful Linux HOWTO on this at:

www.linuxdoc.org/HOWTO/mini/Firewall-Piercing.html

A number of Microsoft products now communicate through port 80 (www) using something called SOAP. Microsoft's official opinion, quoted[19] from

[19] This URL is no longer available.

http://msdn.microsoft.com/library/periodic/period00/soap.htm

is

Since [sic] SOAP relies on HTTP as the transport mechanism, and most firewalls allow HTTP to pass through, you'll have no problem invoking SOAP endpoints from either side of a firewall. Don't forget that SOAP makes it possible for system administrators to configure firewalls to selectively block out SOAP requests using SOAP-specific HTTP headers.

In his CRYPTO-GRAM on June 15, 2000, Bruce Schneier comments on this paragraph thusly:

That's right. Those pesky firewalls prevent applications from sending commands to each other, so SOAP lets vendors hide those commands as HTTP so the firewall won't notice.

Despite Microsoft's assurances that this is okay because the system administrators can block SOAP requests, the reality is that this requires a content filtering firewall specifically configured to block this; many SysAdmins are not aware of the need to block this vulnerability. An experienced administrator with the knowledge and responsibility for protecting the entity's assets is far better equipped to determine what is safe to let in and out of the organization's network than an end user or programmer. Stateful firewalls and similar software are discussed in "Stateful Firewalls" on page 510; this is "must reading," as is "What IP Tables Cannot Do" on page 492.

Certainly, there should be some written policy designed to forbid people from unintentionally setting up bridges around (or through) firewalls, under penalty of dismissal, to avoid these end runs. Having employees, contractors, and affected vendors sign an agreement to follow the policy and dismissal for violators will be appropriate in some environments as these violations can cause serious harm to the organization. This is discussed in "Network Topology Policy" on page 349.

This would reduce the likelihood of such problems as the bonehead at the large Southern U.S. bank who was not happy with the slowness of the corporate Internet feed, so he had a T1 line installed in his branch office. This defeated the carefully configured corporate firewall and opened the bank up to theft. This same bank regularly dials every phone number on the company exchange searching for unauthorized modems on those numbers. This technique will not find those modems that do not have auto-answer enabled, nor those in systems which green-minded people turn off when they go home.

Still, it is worth the effort, and every month they find a number of these modems endangering the corporate network. Since 1999 a company called SecureLogix Corp. has made a product called TeleWall that monitors your company's phone lines for these unauthorized modems, starting at $29,000. This unit is wired into the company switching system.

I know of other companies creating similar products. They work by recognizing the electronic signal patterns of almost all modem protocols, and for medium to large companies, they are well worth the investment to prevent these end runs.

2.9.2 Tunneling Through Firewalls

graphics/threedangerlevel.gif

The inspiration for this section is the quantum mechanical concept where an electron sometimes can get through a barrier that conventional physics theory cannot explain. You have carefully configured your firewall to allow only requests from the Internet to a few ports and machines such as SSH, DNS requests to your "outside" DNS server, and your mail and Web server. Are you safe from outsiders probing your network? Probably not. The problem is that most policies are designed for people who mostly play by the rules, in this case the specifications for the underlying protocols.

These include TCP, UDP ICMP, and ARP. ARP worries about routing and such. Most firewalls are configured to keep evil packets from coming into the organization while allowing company people to send any reasonable packets out. Crackers are some of the most knowledgeable people regarding protocols. They figured out that although most firewalls are configured to block inappropriate request packets, those same firewalls assume that reply packets are, in fact, replies to legitimate requests originating from systems inside their networks. Thus, the crackers simply generate packets that look like they are replies to requests and they are let right through the firewall. Can they do this? Yes. How?

It is easy. One simply requests a socket with the "raw" IP protocol rather than the TCP or UDP protocol. Because the crackers doing this know what packets look like, they simply "build" the packets, byte by byte, and send them out. You might have studied this in a networking class. This is where the lecturer droned on about so many bytes for the source and destination addresses, so many bytes for flags, the checksum, etc.

One of the techniques is for a cracker to send ICMP echo replies. These are the packets that are generated in response to a ping command, used to test the connectivity and communications quality between two systems. Because most firewalls will assume that this is in response to a ping request, it will be passed on to the system specified as the destination address in the packet. This is how a cracker communicates with a TFN2000 Trojan horse. TFN2000 is discussed in more detail in "Stealth Trojan Horses" on page 400. The same technique may be used with different types of reply packets for successful probing. For some types of packets, this response will vary, depending on whether there is a process listening on that port. Thus, even with a firewall a cracker can map most networks! To watch for these and other packets on your network, scan "Using tcpdump" on page 634.

Here are the types of TCP packets used for these probes.[20] The different names in all capital letters are the names of the various status bits that may be set in a TCP packet. The use of the "|" character, used in C to indicate bitwise OR, will be used here the same way. Thus, "RST|ACK" means a packet with both the RST (reset) and ACK (acknowledge) bits set.

[20] Thanks to Ofir Arkin (ofir@sys-security.com) for providing this information and allowing its use here.

The meanings of the various bits are listed in Table 2.2.

Table 2.2. Meaning of TCP Status Bits

Abbreviation

Meaning

ACK

Acknowledgment

RST

Reset (protocol error)

SYN

Synchronize

FIN

Finish

URG

Urgent (out of band) data

PUSH

Push


A cracker can do the following kinds of analysis (probes) of your network with custom TCP packets sent from a raw socket.

  1. Host detection (detect whether host on that IP)

    Any status bit combination with the ACK bit, except with an RST, will elicit an RST response from a probed machine whether a cracker probed an opened port or a closed one. This is because the system is receiving an ACK message when it has not sent a request that deserves an acknowledgment.

    SYN|FIN|URG will elicit an RST|ACK back whether they probed an opened port or a closed one.

  2. Host and port detection (see whether host present and whether port open)

    SYN, SYN|FIN, SYN|PUSH, SYN|URG, SYN|FIN|PUSH, SYN|URG|PUSH, and FIN|URG|PUSH|SYN all will elicit an RST|ACK from a closed port and a SYN|ACK from an opened port.

  3. Distinguishing the operating system

    FIN, FIN|URG|PUSH, URG, URG|PUSH, URG|FIN, PUSH, PUSH|FIN and no flags all will elicit an RST|ACK on a closed port. Linux and UNIX machines will not respond when probed for an opened port; Windows machines will reply with RST|ACK.

  4. Detecting filtering (firewall)

    If they use one of the host detection combinations and do not get a reply, a filtering device is present and is preventing the probe from going inside the protected zone, or preventing the reply from getting out.

  5. Weak filtering device

    If the firewall is just a simple packet filter that blocks incoming SYN packets, some of the listed combinations will elicit a reply. If the firewall is stateful (and is doing its job), all of these attempts will be detected as a violation of the TCP protocol, and the packets can be dropped without a response being generated.

Thus, armed with a map of your site he can try a variety of exploits:

  • TCP sequence number prediction.

    The Linux kernel has prevented this since 2.0.30 (but you will want at least 2.0.36 for another TCP problem discussed in "Defeating TCP Sequence Spoofing" on page 246). Some closed source operating systems have been slower to close this serious security hole, and mixed shops probably have some vulnerable systems.

  • Seeing if your firewall is smart enough to reject packets showing a source address that should come only from a machine inside your firewall.

    Most modern firewalls, when properly configured, will disallow this. Those that do not certainly open up your systems to UDP spoofing, and attempts at TCP sequence number spoofing.

  • DoS attacks against individual machines.

Another tunneling technique would be for a cracker to break into an employee's home system that is granted access to the organization's network. This access might be via SSH or TCP Wrappers. High-security installations will deny this access, except to employees whose home systems pass a security audit as strict as that of any organization-owned system.

Older FTP servers can be used to tunnel through firewalls too. This problem is addressed in "FTP Proxy Dangers" on page 197.


What can be done about tunneling through firewalls? The best solution is to make use of the Linux IP Masquerading capability to establish a private network with private IP addresses. Network Address Translation (NAT) is another name for IP Masquerading that is more common outside the Linux world. Have your firewall map these to temporary addresses when your internal machines want to initiate communications with the outside world. Because your internal addresses would not correspond with your allocated Internet addresses, the crackers "cannot get here from there."

The other alternative is a "stateful firewall." Unlike a standard firewall (referred to now as a stateless firewall) a stateful firewall knows the TCP protocol. Thus, if it sees that a "reply" packet comes in from the Internet, without an appropriate "request" packet having been sent out recently to that machine's port number, it will know that it either is spoofed or an error. This stateful firewall then will drop the packet on the floor and possibly alert the SysAdmin. For the details, see "Stateful Firewalls" on page 540.

2.9.3 Kernel Protocol Switches

graphics/threedangerlevel.gif

Starting with the 2.2 kernel, you can tailor its handling of various problems caused by attackers. These special files are under

 
 /proc/sys/net/ipv4 

All the files may be viewed with less or cat. (The implementation of some pseudo-files under /proc has a severe bug where a read() will return more characters than requested, causing more to core dump. I assume that as of the 2.4 kernel, this is a thing of the past.) Many of these pseudo-files may be written to, to alter the settings in the running kernel. Because /proc is not an on-disk file system these settings will revert back to the defaults when the system is rebooted. On Red Hat, Mandrake, and Slackware, you can place the respective commands to set these values in

 
 /etc/rc.d/rc.local 

The most important setting to enable is having your system not reply to broadcast ICMP broadcasts. By setting this, you will block the use of your system in a very popular DDoS (Distributed Denial of Service) attack that will be explained in detail in "Packet Storms, Smurf Attacks, and Fraggles" on page 246.

A DDoS attack is where a cracker or group of crackers mount an attack from multiple systems, often dozens, hundreds, or even thousands. Usually, these systems are compromised systems and their owners are not aware that they have been compromised because the cracker did not do anything other than install the "Zombie" that will attack a third party on demand.

In February of 2000 a Distributed Denial of Service attack (DDoS attack) occurred against a company on the day it went public. See "Detecting Deleted Executables" on page 655 for the details on how a DDoS attack is launched.


To block this exploit issue the following command:

 
 echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 

Note that this just blocks it for this system.

To cause your system to ignore all ICMP echo requests issue the following command:

 
 echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all 

There are many other useful configuration files in this directory for limiting various exploits and DoS attacks.

2.9.4 Egress Filtering

graphics/threedangerlevel.gif

Most SysAdmins are so worried about protecting their users from the Internet that they do not worry about protecting the Internet from attacks that originate from inside their sites. The most important thing to do is what is called egress filtering. This means adding some rules to your firewall (or router) to filter packets egressing (going out to the Internet). Specifically, the source IP address shown in each outbound packet should be examined to verify that it is valid. "Valid" is defined as the IP being in a range of addresses assigned to your organization. Typically, this would be an address within the Class B or Class C (or even Class A) allocated to you.

This will prevent someone on the inside of your network from launching an attack from your site with a fraudulent address that is untraceable. The more sites that take this "good Internet citizen" approach, the less DoS attacks and other attacks will be launched, and when they are launched, they will be stopped sooner because they will have valid source addresses. Besides improving the Internet, egress filtering will enable faster detection when your systems are compromised, either by an outside cracker or someone within your organization.

Egress filtering rules are included in the step-by-step sample firewall discussed at length in "Basic IP Chains Firewall Usage" on page 527.

2.9.5 LANd Mines

graphics/fivedangerlevel.gif

Breached LANs (local area networks) require special consideration. If just one of the systems on a LAN is breached, it may be used as a launching point for attacks against other systems on the LAN that are not defended against an internal attack (coming from inside the firewall). Most SysAdmins ignore this risk. See "Intracompany Firewalls to Contain Fires" on page 84 and "Stopping End Runs Around Firewalls" on page 74.

For example, the Network Administrator has a firewall protecting internal systems from the outside, generally letting only e-mail in (TCP port 25) so a system administrator "only" has to worry about her sendmail being secure.

Most of the Linux systems, Macs, and Windows systems get mail via the POP or IMAP protocol from a Linux server, so they are not even vulnerable to an attack on port 25. One person, however, will always insist that she be allowed to telnet[21] in from her home system that has a dynamic IP assigned by her ISP at the start of each session.

[21] An excellent alternative to telnet is stelnet, which is telnet over SSL.

Because she is running an old version of Linux (or Windows or MacOS for that matter) and will not install SSH,[22] she talks the Network Administrator into allowing the firewall to pass telnet requests just to her Linux workstation "at the office." SysAdmins beware. Pizza, beer or sodas, and trips to Fry's are all common bribes. Resist at all costs.

[22] SSH is available for Linux, UNIX, Windows, MacOS, VMS, and Java. I ported SSH2 to an ancient Linux 1.2 kernel in two hours.

A cracker then determines her work system's IP by network scanning for systems (or simply trying all IP addresses on the network), and cracks her box with a known old vulnerability because she was too busy to harden her system as we discussed. (She had promised the Network Administrator last year that she would harden her system "real soon now.") Recall that the firewall allows telnet to her work box. Now that the cracker is into her box, the cracker can start penetrating the other boxes because they are not guarding against an attack from inside the firewall.

This type of attack, a very serious one that many, many organizations are vulnerable to, can be protected against in several ways. The obvious one is to be strict about firewall policy, regardless of the inconvenience to users. I hate unnecessarily severe measures so let us consider some other techniques.

The user could be required to use SSH. The Administrator might help her set SSH up. Frequently, a user's unwillingness to migrate is that she does not know how, and fears that it will take a long time. A few minutes of your time helping out may be well spent. A bribe may work in your favor here.

She could be required to start each session by using telnet to access a known secure system that is outside your firewall and that has had its telnet upgraded to a secure one. Note that good hard-to-break passwords are necessary here. I discuss password selection in "Avoiding Weak and Default Passwords" on page 42. Note that her session from her home system to the secure system will still be vulnerable to sniffing; anyone sniffing then would be able to break into her work system by seeing what password she supplies to SSH.

Her work system could possibly be separated from other systems by a different firewall, although this still would leave her system vulnerable. Thus, if her system is cracked, the intruder cannot then travel to the other systems (assuming that other than her system, good security measures have been taken). Clearly this is the least desirable solution because her system is vulnerable.

If her system contains your proprietary source code, engineering documents, manufacturing procedures, patent applications, client lists, marketing plans, the company directory (that headhunters could use for raiding and crackers could use for social engineering), negotiating strategies, or a host of other important files, a cracker breaking into her system could be disastrous.

She could arrange for a reverse DNS service to map whatever dynamic IP she gets back from her home system's ISP into a fully qualified host name, that then gets placed in her work system's /etc/hosts.allow file, used by TCP Wrappers on her work system.

Starting in late 1999, a significant number of crackers have started obtaining very confidential company information and then trying to extort money from companies not to publish the data, frequently asking for hundreds of thousands or millions of dollars. I suspect those that are not this greedy simply get paid quietly.


There are a number of sites on the Internet that offer a Dynamic IP to host name mapping for free. I cannot vouch for the quality of any of them, but have a go at it. You simply register with them, and then arrange for your ip-up script (usually in /etc/ppp) to invoke their program to notify them of your new IP address.

By default your host will be off their domain but they also allow you to register any domain of your own and tie it to your Dynamic IP (remember that to register a domain of your choice, you merely have to list two DNS servers that will serve requests for the IP associated with your host name):

www.justlinux.com/

www.Webattack.com/shareware/network/swip.shtml

www.dynip.com/

By using one of these reverse DNS services, she then can use TCP Wrappers around telnet access so that only her home system will be allowed access to telnet. I must point out that it is theoretically possible for a cracker to spoof her message to one of these public reverse DNS services and then have access to crack her telnet. Realistically, how would the cracker know who to spoof?

Perhaps the public service could be cracked and the reverse DNS requests detected. Perhaps if her home system is connected via a cable modem the cracker could sniff passwords but, of course, you will learn all about the dangers of cable modems from "Cable Modems" on page 131.

Some ISPs offer this feature of a reverse DNS service automatically. MindSpring (now EarthLink) is one that does. If your login account, when you connect, is foo (your e-mail address is foo@mindspring.com), while you are connected, your home system's host name will be foo.users.mindspring.com. Well, it works about 80 percent of the time.

Another solution is the use of a dial-back. This is where a user dials into the system. A program prompts her for her modem's phone number. If it is on the approved list, the system hangs up and then dials the user's modem. This restricts access to those authorized and no password guessing is possible without tapping phones.

A final alternative would be for your organization to offer a PPP dial-in to her. Then she simply could drop her connection to her ISP, and establish a PPP connection to your server. Naturally, this connection is as secure as the phone lines. Keep in mind that if a sophisticated Trojan horse had been planted on her system via a compromised or cracker Web site that she previously had accessed, your agency network still could become compromised. This domino effect is very hard to stop. Another route for compromise would be if while connected into your network via PPP she also has an active connection to an ISP via DSL or cable modem.

2.9.6 Intracompany Firewalls to Contain Fires

graphics/threedangerlevel.gif

Most organizations have a single simple firewall, which is between their network and the Internet. They hope that attackers never get through or around it. Also, they hope that an attack never originates from within their organization. Hope has no place in system administration; it can be a recognition of a weakness that needs to be addressed. In all but the smallest organizations, it is an excellent idea to have intracompany firewalls to confine any security breach to part of the organization and protect the more sensitive areas. Hardware is so inexpensive and the software is free, so it is hard to justify not doing this.

Some people refer to intracompany firewalls as internal firewalls or distributed firewalls.


Obviously, the firewall topology will depend on individual needs. A common topology would be a star arrangement, where each department or type of network leads back to a firewall system via its own cable. This firewall system would have lots of Ethernet cards, and would allow most services to be routed only between a given department and the main firewall. Thus, if someone in Q Branch violates policy and connects a modem to his desktop system, dials-in to his personal ISP, and gets broken into, the rest of the company is at less risk. The network should be divided up based more on the vulnerability of systems and the criticality of their data than on department name.

For example, many companies have a single R&D department, but it might make sense to have the systems relating to their "next generation product" be on a separate network with an separate connection to the intracompany firewall, rather than with the systems relating to ongoing support for existing products. The "next generation product" systems have very confidential data, that if disclosed, could cost the company millions of dollars by giving away its secrets. On the other hand, the systems supporting existing products probably will receive a lot of customer code for reproducing problems. Some of that code may have Trojan horses. Additionally, these people may need to dial-in to customer sites, creating a path for security problems to come into the company or to leave it. A typical topology is shown in Figure 2.3.

Figure 2.3. Intracompany firewalls.

graphics/02fig03.gif

As you can see in Figure 2.3, multiple firewalls were used to prevent a security breach from spreading throughout the company. Although it is possible to combine the functionality of the corporate firewall and the intracompany firewall #1 in a single Linux box, separating them makes for simpler and less error-prone rules, though with the effort of maintaining multiple systems. Additionally, it puts the intracompany load on one box, and the load between the Internet and the External Demilitarized Zone systems on the other box. Many organizations have systems that are considered obsolete for desktop use that have more than enough power for firewall use. A Demilitarized Zone (DMZ) is a network segment where publicly accessible systems are placed, such as the Web server, externally available FTP server, and DNS server, available to external systems. You want a firewall to protect your internal systems from a possible compromise of these systems, but you also want firewall protection of these DMZ systems against unauthorized access from the Internet.

Thus, the DMZ is neither inside nor outside but there is protection all around. The term Demilitarized Zone has caught on. Setting this up is discussed in "Firewalls with IP Chains and DMZ" on page 514. There are a number of interesting features shown in Figure 2.3. There is a second intracompany firewall between the gen R&D net and the test lab. This is to protect R&D from possible bogus packets created on the test lab segment. Intracompany firewall #3 protects the mainframe from everyone, because it was designed to only operate in a very protected environment.

The mail server is inside the corporate firewall. By not having it on the DMZ segment, intracompany e-mail stays off the DMZ segment. This will prevent an otherwise successful compromise of the Web server or CGI execution system from allowing sniffing intracompany confidential e-mail. The corporate firewall will only allow SMTP and SSH services to it from the Internet. There is an internal DNS system that knows of all of the internal systems, but is available only to internal systems. The external DNS system may be queried from the Internet, but it only knows about the public systems such as the mail server and those on the DMZ.

Web pages, CGI execution, FTP services, and DNS each have a separate dedicated box. This gives additional protection because if any one of these services is compromised (due to a currently unknown security bug) the other services will not be compromised. In a small shop some of these services could be combined into fewer boxes but the risk goes up.

Many crackers compromise systems to be noticed, both by their peers and by the media. Defacing Web pages is very popular but a properly configured Apache server is very secure. Thus, a cracker frequently will try to compromise a system and get root access via buggy CGIs, ftpd, or even named.


In this configuration (having a DMZ and separate systems for separate services), a cracker could become root on the CGI and ftpd systems and still will not be able to deface the Web pages.

The final fact to note is that the e-commerce database is on a separate system. Again, we do not trust CGIs. The CGIs merely send the request to a process on the database system. The listening process on the database system should be carefully written to be free from buffer overflow and similar problems. Additionally, running with limited privileges will further contain any breach. Thus, if the CGI system is compromised major damage will not happen to the database. The e-commerce database system communicates with the separate One-Way Credit Card Server (OWCCS) for the handling of customer credit cards. This OWCCS never even tells the e-commerce database system any of the credit card numbers.

Rather, when a purchase is to be made, the OWCCS is told the amount of the purchase, and the customer name and number. It generates a transaction and sends it to the credit card clearing company via separate hardware. It never transmits credit card numbers back to the e-commerce database. Never. It does not even have a request to ask for this data. See "One-Way Credit Card Data Path for Top Security" on page 302 for more details.

Some companies might have a network connection to outside vendors or customers. Examples include credit card processors and various data feeds. A brokerage house, for example, might have a data feed supplying current stock prices. (There was a very serious security breach discovered in a major data feed in the summer of 2000 so this certainly is a real problem.) Banks will have private network connections for processing Electronic Funds Transfer (EFT) requests.

These connections definitely should be separated from the rest of the company with a firewall. This both protects your entity from a breach of these services and protects those entities from a problem originating at your organization. This adds to the "Rings of Security." An organization's branch offices should be treated similarly.


       
    Top


    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    ISBN: N/A
    EAN: N/A
    Year: 2002
    Pages: 260

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net