|
|
  |
As I wrote in a book I co-authored with Ablan and Yanoff, by Sams.Net (Web Site Administrator’s Survival Guide), the first time I heard about firewalls was with my mechanic. Seriously! He was explaining to me that cars have this part that separates the engine block from the passenger compartment, and it’s called a firewall. If the car explodes, the firewall protects the passengers.
Similarly, a firewall in computer terms protects your network from untrusted networks. On one side you have a public network, without any kind of control over what is being done, how or where. On the other side you have the production network of a company with a corporate network that must be protected against any damaging action. Some even question: if we really need to protect a corporate network, so then why allow a network of public domain, such as the Internet, to access it.
The reason is simple: It’s a matter of survival! Companies rely more on the Internet to advertise their products and services. The Internet is growing tremendously, just like big market places and shopping malls, more people are coming to the Internet. The more that come, the more security is necessary to guarantee the integrity of products sold, as well as the safety of those participating in this market (a.k.a., electronic commerce). It has become necessary to protect data, transmissions and transactions from any incidents, regardless if the cause is unintentional or by malicious acts.
This chapter discusses the mechanisms used to protect your corporate network/Intranet and/or Web servers against unauthorized access coming from the Internet or even from inside a protected network. It also reviews what firewalls are after all and how important they are in providing a safe Internet connection. You will learn about the following:
There are several models and configurations of firewalls out there, but the basic idea behind it is always the same. You need to allow users from a protected network, such as your corporate network, to access a public network, such as the Internet, and at the same time, to make available to this public network the services and products of the company.
The problem is that when your company is connected to the Internet without proper security measurements in place, you become exposed to attacks from other servers on the Internet. Not only does your corporate network become vulnerable to unauthorized access, but also do all other servers in your corporate network.
Therefore, when you begin to plan out how you will protect your network from the many threats the Internet can bring you will start by thinking about firewalls. However, even before thinking about it, you must define how and which services and information you will make available to the Internet. Evidently, and first of all, you will want to make sure that your server is secure. You will have to be able to block unauthorized login access, file transfer access, and remote command execution, and perhaps even deny services such as Rlogin, telnet, (t)FTP, SMTP, NFS, and other RPC services. Once you start to use, or have access to these services, that’s when you will need to build a firewall. Figure 7.1 gives you a basic idea of a firewall and its purpose.
But what is a firewall anyway? Basically, a firewall separates a protected network from an unprotected one, the Internet. It screens and filters all connections coming from the Internet to the protected (corporate) network, and vice versa, through a single, concentrated security checkpoint. A firewall makes sure that you cannot reach the Internet from the internal network, nor vice versa, unless you pass through this checkpoint (also known as choke-hold firewall). Some systems even require you to telnet the firewall.
But even before you define what type of firewall best suites your needs you will need to analyze the topology of your network to determine if the various components of your network, such as hubs, switches, routers and cabling are suitable for an specific firewall model. Chapter 10, "Putting It Together: Firewall Design and Implementation," provides information on what to look fort in a firewall, according to your corporate environment and security needs. Also, chapter 14, "Types of Firewalls," provides an extensive list of the main firewall products and in-depth information about their technology, security and management features.
To better understand a firewall and its purpose you should have a more detailed understanding of what a firewall and this protection barrier is. You need look at your corporate network based on the layers of its International Standards Organization (ISO) model. There you find the repeaters and hubs acting at the first layer, switches and bridges acting at the second layer and routers at the third layer. A firewall passes through all these layers as it acts at the sixth and seventh level, the layers responsible for the session establishment controls and applications. Thus, with a firewall we can control the flow of information throughout the establishment of sessions or even by determining which operations will or not be allowed.
However, as you will see, a firewall does more than protect you against the electronic version of airbrushing someone else’s wall or breaking glass windows on the digital street. It will help you manage a variety of aspects on your gate to the Web by keeping the jerks out while enabling you to concentrate on your job.
Say you have just acquired a car. It’s blue with four doors. Is an alarm enough to secure it? In case the car disappears, its color and the fact it has four doors won’t make much difference. I’m sure you wouldn’t be so casual about it. You probably would have insurance for it and would list its vehicle identification number, any accessories it has, plate numbers, and so on. But believe it or not, many companies treat the security of their network assets especially data communication and internetworking assets very lightly. Often there will be no policies, or any sort of record keeping, where the security of their systems are treated with much less information than you would with your car.
That’s where firewalls come in, but you must realize that a firewall alone will not secure your network. It is only part of a broader area in protecting your web site and networking in general.
In order to secure your corporate network, you must define your idea of a network perimeter. You need to determine what things must be protected, develop a security policy, and establish mechanisms to enforce the policy and methods you are going to employ. Of course, there are mechanisms besides the firewall that you can add to tremendously increase your level of security.
These mechanisms must come after your security policy is developed, not before. This should be the main idea you should retain for this section: to define a security mechanism that will protect your corporate site , in specific firewalls, and to provide you with the prerequisites to implement it. Policies and procedures are one indispensable prerequisite. The methods you are going to employ and your analysis of the results are another.
Many companies and data centers are guided by computing security policies, particularly those organizations in the public sector that are likely to be a target, such as the Department of Defense (DoD) and other government agencies. Procedures are established that must be adhered to. Curiously, it rarely happens with the private sector, especially when it comes to connecting to the Internet. You would be surprised to learn that many private companies very often neglect the development of a security policy, and therefore their security mechanisms are weak if not faulty.
Security policies vary from organization to organization, of course, but one issue that will set these policies aside will be the platform for what they are being developed. I firewall can be implemented on UNIX, NT, DOS or a proprietary platform. You must look closely at the platform you will be choosing, as it will definitely define all future projects, level of security and consequently the security policy being developed. That’s why a security policy must come first to guarantee the success of the mechanisms that will be implemented.
As a LAN or Web administrator, you already know that the hardest part of connecting your corporation to the Internet is not justifying the expense or effort, but convincing management that it is safe to do so, especially at a large companies. A firewall not only adds real security, but also plays an important role as a security blanket for management.
Furthermore, have you ever thought about the functions of a United States Embassy in other countries? A firewall can act just like one. As your corporate ambassador to the Internet, a firewall can control and document the foreign affairs of your organization.
| Note: If you want more information on firewalls, a great site to visit is URL ftp://ftp.greatcircle.com/ub/firewalls. A firewall toolkit and papers are available at ftp://ftp.tis.com/ub/firewalls. |
A firewall greatly improves network security and reduces risks to servers on your network by filtering inherently insecure services. As a result, your network environment is exposed to fewer risks because only selected protocols are able to pass through the firewall.
For example, a firewall could prohibit certain vulnerable services such as NFS from entering or leaving a protected network. This provides the benefit of preventing the services from being exploited by outside attackers, but at the same time permits the use of these services with greatly reduced risk of exploitation. Services such as NIS or NFS that are particularly useful on a Local Area Network basis can thus be enjoyed and used to reduce the server management burden.
Firewalls can also provide protection from routing-based attacks, such as source routing and attempts to redirect routing paths to compromised sites through ICMP redirects. It could reject all source-routed packets and ICMP redirects and then inform administrators of the incidents.
The problem with firewalls, though, is that they limit access to and from the Internet. In some configurations, you may decide to use a proxy server, which is explored in more detail later to filter the inbound and outbound access your policy has determined to be safe
A firewall can provide access control to site systems. For instance, some servers can be made reachable from outside networks, whereas others can be effectively sealed off from unwanted access. Depending on the level of risk you are willing to take in your corporate network, watch for outside access to the internal network servers, except for special cases such as mail servers or RAS services.
Also, watch for viruses being downloaded by users via e-mail and spread throughout the protected network. Another threat are that so called applets (mainly Java, JavaScript and ActiveX), that could initiate remote process on a workstation that could affect a server or even disable a firewall.
| Tip: Read more about ActiveX and Java vulnerabilities and security holes on chapter 5, "Firewalling Challenges: The Advanced Web," under the section "Code in the Web." |
This brings us to one of the main purposes an access policy is particularly adept at enforcing: Never provide access to servers or services that do not require access as they could be exploited by hackers since the access is not necessary or required.
A firewall can actually be less expensive for an organization in that all (or most) modified software and additional security software can be located on the firewall system than if distributed on each server or machines. In particular, one-time-password systems and other add-on authentication software can be located at the firewall rather than be on each system that needs to be accessed from the Internet.
Also, don’t neglect internal security. Very often too much emphasis is giving to the firewall, but if a hacker cracks in, unless you have some internal security policy in place, your network will be exposed. That’s why many times it might be a good idea to place the server to be available to the Internet outside of the firewall. The services on this server will very likely become exposed to the Internet threats, but you could easily have a replica of the server inside the firewall and available for quick recovery. You could also keep all the systems configuration of the external server in a CD-ROM, making it secure against modifications.
Other solutions to your corporate network security could involve modifications at each server system. Although many techniques are worthy of consideration for their advantages and are probably more appropriate than firewalls in certain situations, firewalls tend to be simpler to implement, because only the firewall needs to run specialized software, unless if you have a package filtering firewall or require your users to Telnet it. In this case, you either will need a router filtering the packages or a dedicated machine.
Privacy should be of great concern for every corporate network because what normally would be considered innocuous information might actually contain clues that would be useful to a hacker. By using a firewall, your site can block access from services such as Finger and Domain Name Service, for example. Finger, to refresh, displays information about users such as their last login time, whether they’ve read mail, and other items. But Finger can also reveal information to hackers about how often a system is used, whether the system has active users connected, and whether the system could be attacked without attracting the attention of administrators and other monitoring systems.
Another advantage of using a firewall at your site is that by having all access to and from the Internet passing through a firewall, you can log accesses and provide valuable statistics about network usage.
Besides logins and statistics, there are many other advantages to using firewalls. Despite these advantages, you should be aware that there are also a number of disadvantages: things that firewalls cannot protect against, such as access restrictions, back-doors treats (modem and/or RAS servers by-passing the firewall), and vulnerability to inside hackers, to name a few. Chapter 10, "Putting it Together: Firewall Design and Implementation" provides a summary of the pros and cons of the different types of firewalls available.
Obviously, a firewall will very likely block certain services that users want, such as Telnet, FTP, X Window, NFS, and so on. These disadvantages are not unique to firewalls alone, however network access could be restricted at the server level as well, depending on a site’s security policy. A well-planned security policy that balances security requirements with user needs can help greatly to alleviate problems with reduced access to services.
Nonetheless, some sites might lend themselves to a firewall due to their topology, or maybe due to services such as NFS, which could require a major restructuring of network use. For instance, you might depend on using NFS and NIS across major gateways. In this case, your relative costs of adding a firewall would need to be compared against the cost of exposure from not using a firewall.
By now, you have figured that existing back doors in your corporate network are not protected by firewalls. Therefore, if you have any unrestricted modem access, it is still an open door for hackers who could effectively use the access to bypass the firewall. Modems are now fast enough to make running SLIP (Serial Line IP) and PPP (Point-to-Point Protocol) feasible. A SLIP or PPP connection inside a protected subnet can also very easily become a potential back door. So if you are going to allow SLIP or PPP to exist without any kind of monitoring, why bother to have a firewall?
Generally, there is not much protection a firewall can provide against inside threats. Although a firewall might prevent outsiders from obtaining sensitive data, it does not prevent an insider from copying files or stealing information.
It is not safe to assume that a firewall provides protection from insider attacks. It would be unwise for you to invest resources in a firewall if you don’t close the door of your systems to insider attacks as well.
Despite these disadvantages, I strongly recommend that you protect your site with firewalls.
The basic components in building a firewall include:
The following topics give you a brief overview of each of these components and how they affect your site’s security and, consequently, the implementation of your firewall.
The decision to set up a firewall can be directly influenced by two levels of network policy:
The network-access policy that defines services that will be allowed or explicitly denied from the restricted network is the high-level policy. It also defines how these services will be used. The lower-level policy defines how the firewall will actually restrict access and filter the services defined in the higher-level policy. However, your policy must not become an isolated document sitting in a drawer or a shelf it would be useless. The policy needs to become part of your company’s security policy. Let’s take a brief look at different types of security policies.
If you are going to develop a policy to deal with Internet access, web administration, and electronic services in general, it must be flexible. Your policy must be flexible because:
When writing a service-access policy, you should concentrate on your companies’ user issues as well as dial-in policy, SLIP connections, and PPP connections. The policy should be an extension of your organizational policy regarding the protection of Information Systems (IS) resources in your company. Your service-access policy should be realistically complete. Make sure you have one drafted before implementing a firewall. The policy should provide a balance between protecting your network and providing user access to network resources.
A firewall design policy is specific to the firewall. It defines the service-access policy implementation rules. You cannot design this policy without understanding the firewall capabilities and limitations, as well as the threats and vulnerabilities associated with TCP/IP. As mentioned earlier, firewalls usually do one of the following:
A firewall that implements the first policy allows all services to pass into your site by default, except for those services that the service-access policy has determined should be disallowed. By the same token, if you decide to implement the second policy, your firewall will deny all services by default but then will permit those services that have been determined as allowed.
As you will surely agree, to have a policy that permits access to any service is not advisable because it exposes the site to more threats.
Notice the close relationship between the high-level service-access policy and the lower-level one. This relationship is necessary because the implementation of the service-access policy depends on the capabilities and limitations of the firewall systems you are installing as well as the inherent security problems that your Web services bring.
For example, some of the services you defined in your service-access policy might need to be restricted. The security problems they can present cannot be efficiently controlled by your lower-level policy. If your company relies on these services, which usually Web sites do, you probably will have to accept higher risks by allowing access to those services. This relationship between both service-access policies enables their interaction in defining both the higher-level and the lower-level policies in a consistent and efficient way.
The service-access policy is the most important component in setting up a firewall. The other three components are necessary to implement and enforce your policy. Remember: the efficiency of your firewall in protecting your site will depend on the type of firewall implementation you will use, as well as the use of proper procedures and the service-access policy.
As an Internet manager, or even LAN or web administrator, if you intend to provide information access to the public, you must develop a policy to determine the access to the server (probably a web server) and include it in your firewall design. Your server will already create security concerns on its own, but it should not compromise the security of other protected sites that access your server.
You should be able to differentiate between an external user who accesses the server in search for information and a user who will utilize the e-mail feature, if you are incorporating one, for example, to communicate with users on the other side of the firewall. You should treat these two types of traffic differently and keep the server isolated from other sites in the system.
Remote-access systems add useful features to authenticated users when they are not on-site or cannot access certain services or information through the company’s web site. However, users must be aware of the threat of unauthorized access that a dial-in capability can generate.
You must be able to demonstrate the vulnerabilities that this feature will create if users are not cautious when accessing the internal network through a modem. A user’s dial-out capability might become an intruder dial-in threat.
Therefore, you must consider dial-in and dial-out capabilities in your policy when designing your firewall. You must force outside users to pass through the advanced authentication of the firewall. This should be stressed in your policy, as well as the prohibition against unauthorized modems attached to any host or client that were not approved by MIS (Management of Information Systems) or are not passing through the firewall. Your goal is to develop a policy strong enough to limit the number of unauthorized modems throughout the company. By combining such a policy with an efficient pool of modems, you will be able to reduce the danger of hacker attacks on your company using modems as well as limiting your vulnerability.
Another factor you should consider involves web servers. Worse than having a modem line that enables dial-in and dial-out capabilities is the use of serial line IP (SLIP) or Point-to-Point Protocol (PPP) through the Web server or any other means of access to the company network. By far, it is a more dangerous back door to your system than modems could ever be, unless, of course, you pass it through the firewall.
Despite all of the time and effort writing up policies and implementing firewalls, many incidents result from the use of weak or unchanged passwords.
Passwords on the Internet can be cracked in many ways. The best password mechanism will also be worthless if you have users thinking that their login name backwards or a series of Xs are good passwords!
The problem with passwords is that once an algorithm for creating them is specified, it merely becomes a matter of analyzing the algorithm in order to find every password on the system. Unless the algorithm is very subtle, a cracker can try out every possible combination of the password generator on every user on the network. Also, a cracker can analyze the output of the password program and determine the algorithm being used. Than, he just need to apply the algorithm to other users so that their passwords can be determined.
Furthermore, there are programs freely available on the Internet to crack user’s passwords. Crack, for example, is a program written with the sole purpose of cracking insecure passwords. It is probably the most efficient and friendly password cracker available at no cost. It even includes the ability to let the user specify how to form the words to use as guesses at user’s passwords. Also, it has a built-in networking capability, which allows the load of cracking to be spread over as many machines as are available on the network.
Also, you should be aware that some TCP or UDP services authenticate only to the level of server addresses and not to specific users. An NFS server, for example, cannot authenticate a specific user on a server it must grant access to the entire server. As an administrator, you might trust a specific user on a server and want to grant access to that user, but the problem is that you have no control over other users on that serve, and will be forced to grant access to all users. It’s all or nothing!
The risk you take is that a hacker could change the server’s IP address to match that of the trusted client (the user you trust). The hacker could then construct a source route to the server specifying the direct path that IP packets should take to your web server and from the server back to the hacker’s server all this using the trusted client as the last hop in the route to your server. The hacker sends a client request to the web server using the source route. Your server accepts the client request as if it came directly from the trusted client, and returns a reply to the trusted client. The trusted client, using the source route, forwards the packet on to the hacker’s server. This process is called IP spoofing.
Figure 7.2 shows a basic example of a spoofed source IP address attack. Even though most routers can block source-routed packets, it’s still possible to route packets through filtering-router firewalls if they are not configured to filter incoming packets whose source address is in the local domain. This attack is possible even if no reply packets can reach the attacker.
The following are examples of configurations that are potentially vulnerable to those attacks:
Please note that in the figure 7.2 the attack shown won’t work if you have a properly configured router. Before about couple year ago, it would have worked, but after Kevin Mitnick, all the router vendors came out with fixes and told their customers to implement them. Most have, but the illustration is still valid though as many UNIX servers will still accept source-routed packets and pass them on as the source route indicates. Routers will accept source-routed packets as well, although most routers can block source-routed packets.
Couple years ago, the Internet Computer Emergency Response Team (CERT) sent out a security alert describing how hackers were using IP spoofing to break into many Internet sites. More than 23 million university, businesses, government facilities, and home computers connected to the Internet are exposed to the threat of having information stolen, systems time-bombed, and data corrupted through worms, Trojan horses, and viruses. All this, most of the time, for fun.
These kinds of attacks are usually aimed at applications that use authentication on source IP addresses. When the hacker can pass the packet, access to unauthorized data will be totally available. Keep in mind that the hacker doesn’t have to get a reply packet back this break-in is possible even without it. Moreover, some network administrators tend to believe that disabling source routing at the router would prevent it. Not so! It cannot protect the internal network from itself.
If you have a router to external networks that supports multiple internal interfaces, you should consider a firewall because you are potentially exposed to hacker spoofing attacks. The same is true for routers with two interfaces supporting subnets on the internal network, as well as proxy firewalls if the proxy applications use the source IP address for authentication.
Usually, what the hackers want is to access the root directory of your UNIX box. Once inside, they can dynamically replace telnetd and/or login, which enable them to capture existing terminal and login connections from any user on the system. This enables them to bypass the authentication schemes.
According to CERT, there are two steps you can take in order to prevent this kind of attack:
Figure 7.3 describes the CERT’s recommendation for preventing IP spoofing. In this model, any external incoming packets must go through an additional router installed between the external interface (A) and the outside connection (B). This new intermediary router should be configured to block packets that have internal source address (C) on the outgoing interface connected to the original router.
If lack of security is risky, excessive complexity in configuration and controls is also. Use common sense, use the KISS (keep it simple... err steward) method. Server-access controls can be complex to configure and test.
One of the first things you should probably tell your Internet users is to choose passwords that are difficult to guess. You also tell them not to share their passwords with anyone. However, most users don’t follow this advice, and even if they did, hackers can monitor passwords that are transmitted. One of the most effective alternatives to fight the hacker is to adopt advanced authentication measures.
Smartcards, such as credit card-like ID cards and other magnetic encoded cards, and software-based mechanisms are alternatives to cope with the weaknesses of traditional passwords. If you adopt one of these advanced authentication devices, hackers will not be able to reuse a password that was monitored during a connection. If you consider all of the inherent problems with passwords on the Internet, an Internet-accessible firewall that does not include some kind of advanced authentication system does not make much sense. The few mistakes and threats discussed previously give you an idea of what you are facing when announcing your new web site.
Some of the more popular advanced authentication devices in use today are called one-time password systems. A smartcard, for example, generates a response as an authenticator instead of a traditional password. It works in conjunction with software or hardware. Even if monitored, it can be used only once. The firewall’s advanced authentication system should be located in the firewall because it centralizes and controls access to the site. You could install it on another server, but loading it on a firewall makes it more practical and manageable to centralize the measures.
Figure 7.4 illustrates what happens when advanced authentication is present. All connections and requests for sessions such as Telnet or FTP originating from the Internet to site systems must pass the advanced authentication before permission is granted. Passwords might still be required, but before permitting access, these passwords would be protected even if they were monitored.
Usually, IP packet filtering is done using a router set up for filtering packets as they pass between the router’s interfaces. These routers can filter IP packets based on the following fields:
Although not all packet-filtering routers can filter the source TCP/UDP port, most of them already have this capability. Some routers examine which of the routers network interfaces a packet arrived at, and this is used as an extra criterion. Unfortunately, most UNIX servers do not provide packet-filtering capability.
In order to block connections from or to specific web servers or networks, filtering can be applied in many ways, including the blocking of connections to specific ports. For instance, you might decide to block connections from addresses or sites that you consider being untrustworthy, or you might decide to block connections from all addresses external to your site all this can be accomplished by filtering. You can add a lot of flexibility simply by adding TCP or UDP port filtering to IP address filtering.
Servers such as the Telnet daemon usually reside at specific ports. If you enable your firewall to block TCP or UDP connections to or from specific ports, you will be able to implement policies to target certain types of connections made to specific servers but not others.
You could, for example, block all incoming connections to your web servers except for those connected to a firewall. At those systems, you might want to allow only specific services, such as SMTP for one system and Telnet or FTP connections to another system. Filtering on TCP or UDP ports can help you implement a policy through a packet-filtering router or even by a server with packet-filtering capability. Figure 7.5 illustrates packet-filtering routers on such services.
You can set up a ruleset to help you outline the permissions. Figure 7.6 shows a very basic, example ruleset of packet filtering. Actual rules permit more complex filtering and greater flexibility.
The first rule allows TCP packets from any source address and port greater than 1023 on the Internet to enter the destination address of 123.4.5.6 and port of 23 at the site. Port 23 is the port associated with the Telnet server, and all Telnet clients should have unprivileged source ports of 1024 or higher.
The second and third rules work in a similar way, except that packets to destination addresses 123.4.5.7 and 123.4.5.8, and port 25 for SMTP, are permitted.
The fourth rule permits packets to the site’s NNTP server, but only from source address 129.6.48.254 to destination address 123.4.5.9 and port 119 (129.6.48.254 is the only NNTP server that the site should receive news from; therefore, access to the site for NNTP is restricted to that system only).
The fifth rule permits NTP traffic, which uses UDP as opposed to TCP, from any source to any destination address at the site.
Finally, the sixth rule denies all other packets. If this rule wasn’t present, the router might not deny all subsequent packets.
Although packet filtering can effectively block connections from or to specific hosts, which increases your level of security substantially, packet-filtering routers have a number of weaknesses. Their rules are complex to specify and tough to test, because you either have to employ exhaustive testing by hand or find a facility where you can test the correctness of their rules. Logging capability is not found in all routers. If the router doesn’t have this capability, you won’t know if dangerous packets are passing through until it is too late.
Besides, in order to allow certain types of access (that normally would be blocked) to go through, you might have to create an exception to your rules. Exceptions sometimes can make filtering rules very difficult, or even unmanageable. How? Lets suppose you specify a rule to block all inbound connections to port 23 (the Telnet server). Assuming that you made exceptions such as accepting Telnet connections directly, a rule for each system needs to be added, right? Well, sometimes this kind of addition can complicate the entire filtering scheme! Don’t forget: Testing complex sets of rules for correctness might be so difficult that you could never be able to set it right.
Another inconvenience to watch for is that some packet-filtering routers will not filter on the TCP/UDP source port. The filtering ruleset can become very complex because of it, and you can end up with flaws in the whole filtering scheme.
The RPC (Remote Procedure Call) services are very difficult to filter too. The associated servers listen at ports that are assigned randomly at system startup. The portmapper service maps initial calls to RPC services to the assigned service numbers. However, there is no such equivalent for a packet-filtering router. It becomes impossible to block these services completely because the router cannot be told on which ports the services reside (unless you block all UDP packets) because RPC services mostly use UDP. But if you block all UDP packets, you probably would block necessary services (DNS, for example). The question becomes to block or not to block RPCs.
You should get more information on packet filtering and associated problems. It’s not the scope of this chapter to exhaust the subject, but packet filtering is a vital and important tool. It is very important to understand the problems it can present and how they can be addressed.
After you’ve decided on the security policy, there are a number of issues to be considered in procuring a firewall. Standard steps to be taken are requirement definition, analysis, and design specification. The following sections describe some considerations, including minimal criteria for a firewall and whether to build or purchase a firewall.
When the decision is made to use firewall technology to implement your organization’s Web site security policy, the next step is to procure a firewall that provides the appropriate level of protection and cost-effectiveness. Ask these questions:
Of course, by now you can entirely answer these questions with specifics but it is easy to assert that firewalls have the following features or attributes for which you should always look for:
There are undoubtedly more issues and requirements, but many of them are specific to each site’s own needs. A thorough requirements definition and high-level risk assessment will identify most issues and requirements; however, it should be emphasized that the Internet is a constantly changing network. New vulnerabilities can arise, and new services and enhancements to other services might represent potential difficulties for any firewall installation. Therefore, flexibility to adapt to changing needs is an important consideration.
A number of organizations might have the capability to build a firewall for themselves. At the same time, there are a number of vendors offering a wide spectrum of services in firewall technology. Service can be as limited as providing the necessary hardware and software only, or as broad as providing services to develop security policy and risk assessments, security reviews, and security training.
Whether you buy or build your firewall, it must be restated that you should first develop a policy and related requirements before proceeding. If your organization is having difficulty developing a policy, you might need to contact a vendor who can assist you in this process.
If your organization has the in-house expertise to build a firewall, it might prove more cost-effective to do so. One of the advantages of building a firewall is that in-house personnel understand the specifics of the design and use of the firewall. This knowledge might not exist in-house with a vendor-supported firewall.
An in-house firewall can be expensive in terms of time required to build and document the firewall and the time required maintaining the firewall and adding features to it as required. These costs are sometimes not considered organizations sometimes make the mistake of counting only the costs for the equipment. If a true accounting is made for all costs associated with building a firewall, it could prove more economical to purchase a vendor firewall.
In deciding whether to purchase or build a firewall, answers to the following questions might help your organization decide whether it has the resources to build and operate a successful firewall:
Many vendors offer maintenance services along with firewall installation, so the organization should consider whether it has the internal resources needed.
If you decide to build your firewall, make sure you respond to all of the preceding questions and that you indeed will be able to handle all the details of setting the firewall. Most importantly, make sure that your organization’s upper management is 100-percent with you.
The following is an example of a firewall setup. Later on this chapter I give you an example of a firewall installation, should you decide to purchase one instead of setting it up yourself. Hardware requirements and configuration will vary, of course, but if you follow the outlined steps you should be able to avoid lots of frustration and time-consuming surprises.
Also, make sure you have your firewall policy written up, understood, and on hand. When that is complete, write the following outlined steps on a board or notepad. They will be your roadmap in putting your firewall together:
If your company is a medium size, I tried to complement the information to suit your needs with the following example of a company with 200 employees. Keep in mind: Far from being a sample firewall plan, this plan should be considered as a template to be modified as needed.
Let’s assume for example that I am setting up a firewall for my company, Vibes (Virtual Business Educational Services, in case you’re wondering). For comparison reasons (and comparison reasons only!), consider Vibes to be a medium-sized company with 200 employees where all users have access to the Web and other services such as Telnet, FTP, Gopher, and SMTP.
The computer I will be using for the firewall is a 90Mhz Pentium with 16MB of RAM, a 540MB Linux partition, and a PPP connection to an Internet provider over a 28,800bps modem. To make the Linux box a firewall, I added an Ethernet network interface card and connected it to the company’s LAN. All clients are running either Windows 95 (with SP1) or Windows NT Workstation 4.0 (with SP3 update).
Now I have to set up my Linux box. I have to recompile the Linux kernel. In order to do that, I will have to issue a make config, where I will:
When done, I need to recompile and reinstall the kernel. I will then reboot the machine and watch the interfaces showing up on the screen during my boot-up sequence (it should show up!). If not, I will need to review all of the above procedures, and even the machine itself if necessary. In doing so, I will watch for PCI and SCSI conflicts.
If everything works, it will be time to set up the system on the network.
This part is crucial! In setting up the computer’s network address, I need to keep in mind that I don’t want the Internet to have access to my internal network (have you figured what kind of policy I’m using?). I am planning to use a fake network address. If you want to follow me on this one, a good C class you can use is 192.168.2.xxx, a dummy test domain.
I need to assign a real IP address to the serial port I will be using for my PPP connection, and assign 192.168.2.1 to the Ethernet card on my new domain JAVALITO. I will then assign a number in that domain to all the other computers in the protected network. It will then be time to test it out!
In order to test network connectivity, I will try to ping the Internet from JAVALITO. I want to make sure to try to ping a few other places that are not connected to my LAN. If it doesn’t work, it will be an indication that I probably have set up my PPP incorrectly.
After I have a chance to ping out there, I will then try to ping a few hosts inside my own network. What I want to make sure here is that all of the computers on my internal network are able to ping each other. If not, it will not even be funny trying to continue with this setup until the problem is resolved, believe me!
As long as I determine that all of the computers are able to ping each other, they should also be able to ping JAVALITO. If not, I will have to go back to my previous step. One thing to remember is that I should try to ping 192.168.2.1, not the PPP address.
Lastly, I want to try to ping the PPP address of JAVALITO from inside my network. Of course, I should not be able to! If I can, this tells me that I have forgotten to turn off IP forwarding, and it will be time to recompile the kernel again. When I finish these tests, my basic firewall will be ready to go.
| Note: You probably are thinking, why bother reconfiguring it, because I assigned my protected network to a dummy domain that consequently cannot get any packets routed to it? The reason is that by doing this I take the control away from my PPP provider and keep it in my own hands. |
After I have my firewall set up, I will need to start "closing the doors," which at this point will still be quite open. Based on my policy, I will start turning off everything I don’t need. At the top of my "turning off" list will be netstat, systat, tftp, bootp, Finger and rlogin. Once I turn off all of the services on my list, I will try to Telnet the netstat port, which I shouldn’t be able to get any output from. If I can, something is wrong.
At this point, my firewall will be up and running, but a firewall that doesn’t allow anyone to come in or out is like a company that keeps its doors locked as part of a crime-prevention policy. It might be safe, but bad for business! By the same token, if a firewall is too restrictive, it can do as much harm as a wide-open firewall. With this in mind, applications, patches and software packages have been developed to make firewalls smarter and consequently more beneficial proxy servers, Socks, and so on.
Socks is one of several firewalling software packages out there, which is discussed in more details in the next section, discussing exclusively about proxies. TCP Wrapper is an application widely used as well, but as mentioned earlier in this chapter, it is not really a firewall utility so it is better to focus on Socks. Should you need additional information on TCP Wrapper, make sure to visit the FTP sites noted in that section.
Internet technology provides a cost effective global communications infrastructure that enables world-wide access for employees, customers, vendors, suppliers and key business partners. This is an important enhancement to collaborative information sharing, but it also exposes an organization's network to new risks and threats. How can an organization keep its resources and information protected from unauthorized network access, from both inside and outside the organization? Access control, a fundamental building block in any security policy, addresses this issue.
Access control protects an organization from security threats by specifying and enforcing what can go in and out of an organization's network. A key element of access control is an awareness of all underlying services and applications.
First generation packet filters were not aware of applications, nor could they handle UDP or dynamic protocols.
Second generation application proxies required a tremendous amount of CPU overhead, and were slow to provide support for new services appearing regularly on the Internet, such as multimedia services. Firewalls with stateful inspection technology, such as Check Point FireWall-1's, combined with a powerful object oriented approach, provide full application-layer awareness as well as quick and easy support of new Internet services. Firewall-1, for example, has over 160 pre-defined applications, services and protocols and the flexibility to specify and define custom services, providing a very comprehensive access control.
In addition to understanding the full state and context of a communication, FireWall-1 provides the ability for rules within a security policy to be enforced using a time parameter. This provides extensive granularity in access control allowing rules to be vaild for specific hours/days/months/years. For example, an organization may decide to limit HTML or web traffic to the Internet during working hours, allowing access only during lunch time, after normal working hours and on weekends.
Another example is to disallow access to critical servers while system backups are being performed.
Implementing access control parameters should be simple and straight forward with a well-defined graphical user interface such as that provided in most firewall products listed on chapter 14, "Types of Firewalls." In fact, all aspects of an organization's security policy are usually easy to be specified by using the GUI interfaces of these firewalls. Usually, all elements are specified using an object oriented approach. Once defined, these objects are used to define the security policy using a rules editor.
Although it varies from firewall to firewall product, each rule can be comprised of any combination of network objects, services, actions, and tracking mechanisms. In the example of Check Point’s Firewall-1, once a rule is defined, FireWall-1 provides the ability to define which network enforcement points it should be distributed to across the network.
Supported platforms include UNIX and NT servers, and internetworking equipment (routers, switches, edge devices) from Check Point's many OPSEC Alliance partners. A distinct advantage of Check Point FireWall-1 is the ability to define an enterprise security policy once, distribute it to multiple access points throughout the network, and manage it from a single centralized console. Figure 7.7 shows a screenshot of Firewall-1 security policy setup.
Figure 7.8 shows four separate components of the Graphical User Interface (GUI) for Firewall-1. These components are as follows:
Figure 7.9 shows the screen that will appear once you select the gateway.
Figure 7.10 shows the host properties screen of Firewall-1 and figure 7.11 shows the users management screen. These screenshots give you an idea of what to expect on a top-of-the-line firewall product. Keep it in mind when shopping for a firewall. Needless to say, Check Point’s product should be strongly considered.
Firewall administration is a critical job role and should be afforded as much time as possible. In small organizations, it might require less than a full-time position, but it should take precedence over other duties. The cost of a firewall should include the cost of administrating the firewall administration should never be shortchanged.
As described at the beginning of this chapter, there are many ways to break into a system through the Internet. Therefore, the need for highly trained, quality, full-time server system administrators is clear. But there are also indications that this need is not being met satisfactorily in a way that identifies, protects, and prevents such incidents from happening. Many system managers are part-time at best and do not upgrade systems with patches and bug fixes as they become available.
Firewall management expertise is a highly critical job role because a firewall can only be as effective as its administration. If the firewall is not maintained properly, it might become insecure and permit break-ins while providing the illusion that the site is still secure. A site’s security policy should clearly reflect the importance of strong firewall administration. Management should demonstrate its commitment to this importance in terms of full-time personnel, proper funding for procurement and maintenance, and other necessary resources.
A firewall is not an excuse to pay less attention to site system administration. It is, in fact, the opposite: If a firewall is penetrated, a poorly administered site could be wide open to intrusions and resultant damage. A firewall in no way reduces the need for highly skilled system administration.
At the same time, a firewall can permit a site to be proactive in its system administration as opposed to reactive. Because the firewall provides a barrier, sites can spend more time on system-administration duties and less time reacting to incidents and damage control. It is recommended that sites do the following:
For a company which relies greatly on outgoing access capabilities, such as educational companies, universities, etc , it is recommended that circuit-level gateways and packet filters be used. This assumes that the departments of this company trust their internal users. If the installation will restrict outsiders to accessing only a Web server, outside of the firewall, blocking any external connections from the internal and protected network, the department might not need anything more.
The same model will suit a mid-size company relying heavily on the Internet, such as ISPs, Web hosting, etc., but the policy will be contrary to the example above since more Internet users will be accessing the site them the site accessing the Internet. Wide access can be granted to the Web/Internet server outside of the firewall. Protected network users would have to Telnet to the Internet/Web server, from inside the company, just like everyone else outside of the firewall.
Larger companies or those where Internet users are offered access to specific services and shares inside the protected network will need to have a different setup. In this case, I would suggest firewall packages like CheckPoint, or at least an application gateway. It would be advisable to implement CERT’s recommendation of an additional router to filter and block all packets whose addresses are originated from inside the protected network. This two-router solution is not complicated to deploy, and is very cost-effective when you consider that a larger company would be exposed to spoofing by allowing all the many employees it has throughout the country to have access to its Web server and internal network.
When implementing two routers, you should purchase them from different companies (that is, choose two different brands). It might sound like nonsense, but if a hacker is able to break into one router due to a bug or a back door on the router’s code, the second router will not have the same codes. Even though the firewall will no longer be transparent, which will require users to log on to it, the site will be protected, monitored, and safe.
The typical firewall for such a company is illustrated on Figure 7.12. In this case, the two routers create a package-filtering firewall while the bastion gateway functions as an application-gateway firewall.
In the case of a smaller-sized company, the IP-level filtering might be the most appropriate versus other types of filtering. This model enables each type of client and service basically to be supported within the internal network. No modifications or special client software would be necessary.
The access through the IP-level filtering firewall will be totally transparent for the user and the application. The existing router can be utilized for the implementation of the IP-level filtering. There will be no need to buy an expensive UNIX host. However, small companies can reinforce its Internet server security by implementing similar solutions used by a larger company without a need for the application gateway.
