Home > Articles > Security > Network Security

Turning Security Policy into Security

The following section illustrates taking a simplistic set of security policies, formulating it into a security architecture, and then explaining what that means in terms of ruleset implementation.

Security Policy

For this example, the simplest useful policy is used. You can be completely secure by allowing nothing to pass and dropping all inbound traffic, but then there wouldn't be much sense in connecting to the Internet:

  • Provide internal users with unrestricted access to Internet resources.

  • Allow access to the Company-hosted Web Server, DNS server, and email server.

  • Deny everything else.

Notice how this doesn't imply anything about the architecture of the Internet connection. Selecting a working architecture will be discussed shortly.

Default Stance

The default stance is your policy on what action is taken for a packet that doesn't match any of the previously defined rules. Normally, for securing a site, the default policy will be to DROP the packet.

Security Architecture

Defining a security architecture is the process of converting security policies into technical implementation. The security architecture is where you decide the following:

  • Whether you are hosting your servers on one or many demilitarized zone (DMZ) LANs or being dangerous and hosting them on your internal network

  • Whether you are using just a packet-filtering router or a firewall in conjunction with the router, and so on

The first part of the security policy is to allow any internal network traffic outbound to the Internet. This really doesn't impact any security architecture you might choose.

Hosting Web, DNS, and email services on-site will provide intruders a handhold to access your internal network resources. To protect both your servers and your internal resources, choose to host them on a DMZ. The security gateway, whether it is a packet-filtering router or a firewall, will then be the first line of defense against intruders attacking your servers.

Next, a dedicated firewall system is deployed that connects the internal network to the unprotected network on the router. Additionally, there is a single DMZ segment on which the Web server, DNS server, and mail server will reside. The DMZ is a protected network segment that allows access from both the Internet and the internal network. However, because Internet users will be accessing those servers, the servers can't be trusted. Making the assumption that the servers could be compromised at any time helps define another policy: Any connections initiated from those servers to the internal network will be refused.

Because DNS provides host, server, resource, and internal organizational information, you should use a split DNS. The split DNS provides a minimal subset of the necessary information for external users to contact and interact with the DMZ-protected servers. An internal DNS server on the internal network will carry the full zone information. This qualifies as security through obscurity, but there is no real need to give intruders a map of your network to focus their attacks on.

The mail server will be configured as a queuing mail-hub. This allows internal hosts to relay mail out to the Internet, and it allows the internal mail server to periodically poll the DMZ mail server for queued email. The mail server will not allow unauthorized relaying, the act of forwarding email destined for another domain through your server. This is not only courteous, but helps reduce spam and email abuse. Speaking of which, the mail-hub will also be configured to reject email coming from sites in the Mail Abuse Prevention System (MAPS) Realtime Blackhole List (RBL). The MAPS RBL contains sites that have been used to relay spam, and have refused to take any action against preventing the spammers from relaying through their sites.

Administration of all the boxes will be provided by Secure Shell. As previously discussed, SSH provides both secure terminal emulation and secure file transfer capabilities replacing rsh, rlogin, telnet, and ftp. There's no point in passing your account and passwords in the clear (see Figure 1).

Figure 1. Internet connection with packet filter router, firewall, and DMZ hosted servers.

Security Architecture to Rulebase

The next step is to take our modified security policy and security architecture, and convert them into rulesets that make up our firewall rulebase. This step is generally firewall-agnostic and doesn't depend on any special features such as stateful inspection or built-in support for specific application services such as FTP. The actual implementation of these generic rules for a specific firewall is where the details of such joy will fall out.

Start Free and Clear

First and foremost, flush all existing rules, and reset all existing firewall properties. This ensures that there are no existing holes, gaps, misconfigurations, or surprises that you weren't expecting.

Remember simplicity: It is better for your firewall to err conservatively and block needed traffic than it is to allow unwanted traffic. Starting with a clean slate by blocking all traffic assures that you at least start out secure with the goal of remaining that way.

Allow Internal Network Traffic Outbound to the Internet

Allow all internal network traffic outbound to the Internet. This rule becomes more complex the more non-contiguous internal networks you need to represent. Because the point of having a DMZ is to host servers that are not trusted, you must ensure that the internal users are not normally accessing the DMZ servers directly. To accomplish this, allow all internal network traffic to any destination except the DMZ. Most all firewalls have the negation operator that allows you to express this rule easily.

Protect the Firewall

Drop all traffic destined for the firewall itself. You don't want people succeeding in sending traffic to the firewall proper. This won't hide the firewall from intruders, but it will generally deny packets and responses directly accessing the firewall. There is a way to hide the firewall, but it's specific to a firewall implementation. Here is where rule order starts to become important because this rule must go prior to the Allow Outbound rule. If the order were to be reversed, internal hosts could access the firewall.

Allow Only Internal Admin Access to the Firewall

Although the firewall needs to be managed, it should be managed only by the firewall administrators. Administrative access should be restricted to which machines the administrators use and types of network traffic required to access and to manage the firewall. For example, UNIX-based firewalls should allow access only by encrypted SSH sessions. Commercial firewalls such as Checkpoint's FireWall-1 have specific firewall administrative ports (256, 257, and 258) that are accessed via encrypted sessions through their management console. This rule must go prior to the drop everything destined for the firewall rule, or even administrative traffic will be dropped.

Default Policy of Drop Everything

The default stance of that which is not explicitly allowed should be denied needs to be implemented. In addition to dropping all other packets, a useful diagnostic method enables logging of the dropped packets. This provides you with the means to troubleshoot firewall issues, and to audit the attempted intrusions. This rule generally goes last.

Drop Traffic You Do Not Want Logged

Broadcasts, Multicasts, and other traffic your firewall sees but you do not want logged should have a rule defined that drops or rejects the traffic, but does not log. This prevents excessive, unnecessary logging that would otherwise clutter up your logfiles. Reviewing your logfiles will be difficult enough without having to wade through page after page of NetBIOS, RIP, OSPF, or DHCP requests. This rule needs to be ordered prior to the protect the firewall rule.

Services Provided to the Internet

You need to allow Internet users access to the servers and services that you are providing to the Internet. This includes DNS name lookups, Web (HTTP/HTTPS), and mail (SMTP):

  • Allow DNS name lookups (UDP/53) from any network, but allow the internal networks to the DMZ name server only. The internal users should be using the internal DNS servers. If your ISP is acting as a secondary for your external DNS name server, you would need to add an additional rule allowing DNS zone transfers (TCP/53) between the ISP's name server and the DMZ name server.

  • HTTP (TCP/80), and HTTPS (TCP/443) if necessary, access from anywhere to the DMZ Web server will be allowed. To enable HTTP/HTTPS access from the internal network, this rule must be before the allow-outbound-to-everywhere-but-the-DMZ rule.

  • SMTP (TCP/25) access from anywhere to the DMZ mail server will be allowed. To enable SMTP access from the internal mail server, this rule must also be before the allow-outbound-to-everywhere-but-the-DMZ rule.

Drop DMZ-Initiated Traffic

The servers on the DMZ should never initiate a connection to the internal network. If this occurs, there is a good chance that one of your servers has been compromised. The rule that governs this activity should deny and log the occurrence. If you have the ability to trigger an alert, that certainly is timely and valuable information to have.

Additional Rules

If you want to block additional services, such as ICQ or AOL's Instant Messenger, rather than block the ports, block the destination hosts. AIM can use Telnet, HTTP, SMTP, or HTTP Proxies to access the AIM servers:

  • Block all TCP traffic to login.oscar.aol.com

  • Block all TCP traffic to toc.oscar.aol.com

Change Management

Comments in a comments field or in the firewall startup script are necessary forms of documentation that allows organizations to better manage and maintain the integrity of their firewall rulebases. The following information, at a minimum, should be logged with a rulebase change:

  • Name of admin modifying the rule

  • Date/time change implemented

  • Reason for the rule change

Be sure to log your changes; this advice can't be stressed enough. You will appreciate it when there are problems, which there will be. Even better, have your firewall rulebase or script under revision control. This could be something as simple as a backup copy of the file with the date in the filename to Revision Control System (RCS)- or Source Code Control System (SCCS)-enabled archives.

Harden All Your Servers

Hardening is about minimizing risk and increasing robustness. Hardening refers to the process of disabling unnecessary services, ensuring that all security patches have been applied, and paying careful attention to file system permissions. Hardening a server that is Internet accessible includes, but is not necessarily limited to, the following tasks:

  • Reducing the number of network services that are running and accessible to the Internet.

  • Removing unnecessary software and features, which reduces the overall complexity of the system. This includes removing additional protocols such as IPX, AppleTalk, NetBIOS, DLC, LAT, and DecNET.

  • Removing software that allows access to internal system information, such as SNMP.

  • Removing insecure remote control software, such as X Window or the ADMIN$ share for remote Windows NT administration.

  • Applying all known security updates and service packs. Oftentimes, security exploits in necessary software, such as DNS, are resolved in a simple configuration change or security patch.

  • Enabling traffic filters, if available. Windows NT and most UNIX systems have built-in or freely available software that allows more control of the kinds and sources of IP traffic that are accepted.

  • Removing unnecessary accounts on the system. Rename existing administrative or root accounts to something unique and hard to guess.

  • Removing unnecessary and overly generous file permissions for both accounts and the file system.

The details of such tasks are operating system-specific, not only to vendor, but also to version. An overall guide to hardening several flavors of operating systems can be found at the following URL: http://advice.networkice.com/Advice/OS/default.htm

Microsoft Windows NT and 2000 operating systems have a well-known source of information to help you harden your servers. Although these documents are IIS-specific, many of the steps to harden your server that do not include IIS are extremely useful. Visit http://www.microsoft.com/technet/security/iischk.asp for Windows NT 4.0 information, and visit http://www.microsoft.com/technet/security/iis5chk.asp for Windows 2000 information.

Drop Source Routed Traffic

Normally, an IP packet leaves the client with only the source and destination addresses. All routing decisions are made by routers on the way. There is an IP option that allows you to specify what routes to take, which are specified from the sending machine. Thus, it is source routed rather than router routed.

You might ask yourself why the sending node would want to specify routing information rather than let the network routers make those decisions. Well, it's useful for performing network diagnostics. Traceroute can be used to specify source-routed traffic, and traceroute is useful. Unfortunately, source-routed traffic can also be used to override packet filter routers and firewall rulebases.

There are actually two forms of source-routed traffic: Strict Source Routed and Loose Source Routed. The differences aren't that important, because all source-routed traffic needs to be dropped. Dropping source-routed traffic should be done on the edge routers and any capable security gateways.

Drop Directed Broadcast Traffic

IP networks normally have two reserved IP addresses: the network address, which is the host portion of the IP address filled with all zeros; and the broadcast address, which is the host portion of the IP address filled with all ones.

If an ICMP echo reply, easily generated by a ping, is sent to either the network or broadcast address, each node on that network would respond. This originally was used to determine the status of network nodes; however, more recently, this is used to create denial of service attacks.

A simple denial of service attack is to send an ICMP echo request to the broadcast address of a network of hosts with a spoofed address. All the hosts on that subnet respond with an echo reply to the spoofed address. Each ping is multiplied by the number of hosts on the subnet, which generates instant traffic.

Now, imagine a user on a 56Kbps dial-up modem sending spoofed ICMP echo requests to a subnet of 100 hosts. Those 100 hosts generate 100 ICMP echo replies that are sent to the IP address in the spoofed packets. That is 53Kbps x 100, or 5,300Kbps. That is three times the size of a T1, all generated from a dial-up user.

This type of attack and others like it can be defeated by disabling directed broadcasts on the edge routers and servers exposed to the Internet. Further information can be found in RFC 2267, Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing.

Lock Down Your DNS Servers

DNS servers are often the focus of root-compromise exploits. To reduce the probability that you will be a target, there are some simple configuration options to consider for your DNS server:

  • Run the newest stable release of the name server. All prior versions of both BIND and Microsoft's DNS server have vulnerabilities. If you are using the Internet Software Consortium's version of BIND, which is used on almost every installation of UNIX, make sure that you are using 8.2.2pl5 or newer. For Microsoft Windows NT, make sure that your DNS server is running at least Service Pack 4. Service Pack 6a is now available.

  • Restrict zone transfers to known secondary servers. This reduces additional information that can be gathered by potential intruders. The important thing to keep in mind here is to not allow zone transfers from the secondary servers. There is no point locking down the primary servers if the intruders can just do a zone transfer from a secondary server.

  • Do not use dynamic updates on external DNS servers. None of your Internet-accessible servers should be using dynamic IP addresses. Therefore, there is no need for dynamic updates. It should be obvious why it is a security risk to allow intruders to send dynamic updates to your DNS server.

  • If possible, restrict the queries that the DNS server will do recursive queries for. There is no reason why your DNS servers should do recursive DNS queries for anyone other than your internal network hosts. Create an access control list (ACL) to restrict queries to internal hosts.

Disable Relaying and Other Information Features on Your SMTP Server

As previously discussed, it is bad netiquette to allow email relaying through your mail server. Many mail servers have built-in support to reject email coming from sites in the Mail Abuse Prevention System (MAPS) Realtime Blackhole List (RBL) or similar lists. To prevent abuse of your mail server and other people's resources, block mail relaying and spam.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020