Home > Articles > Security > Network Security

Implementing Security, Part II: Hardening Your UNIX/Linux Servers

Continuing with part 2 of this two-article series, Joseph Dries helps you continue to expand upon your list of basic security processes by looking at UNIX/Linux hardening, protecting your servers from network based TCP/IP attacks, and utilizing centralized logging servers.
This article was excerpted from The Concise Guide to Enterprise Internetworking and Security.
"A commercial, and in some respects a social, doubt has been started within the last year or two, whether or not it is right to discuss so openly the security or insecurity of locks. Many well-meaning persons suppose that the discussion respecting the means for baffling the supposed safety of locks offers a premium for dishonesty, by showing others how to be dishonest. This is a fallacy. Rogues are very keen in their profession, and already know much more than we can teach them respecting their several kinds of roguery. Rogues knew a good deal about lockpicking long before locksmiths discussed it among themselves, as they have lately done. If a lock—let it have been made in whatever country, or by whatever maker—is not so inviolable as it has hitherto been deemed to be, surely it is in the interest of honest persons to know this fact because the dishonest are tolerably certain to be the first to apply the knowledge practically; and the spread of knowledge is necessary to give fair play to those who might suffer by ignorance. It cannot be too earnestly urged, that an acquaintance with real facts will, in the end, be better for all parties."
—Charles Tomlinson's "Rudimentary Treatise on the Construction of Locks," published around 1850

UNIX/Linux Systems

It has been said that the wonderful thing about standards is there are so many to choose from. The same choice is available in the UNIX arena. There are two basic flavors, BSD-derived and AT&T System V-derived. BSD-derived UNIX systems include OpenBSD, FreeBSD, NetBSD, BSDi, MacOS X, and SunOS 4. System V-derived UNIX systems include HP-UX and Solaris (SunOS 5). Other UNIX systems, such as AIX, provide commands that will act BSD-ish or System V-ish, depending on how they were invoked. Linux is not derived from any UNIX, but depending on the distribution, borrows from both BSD and System V semantics. Actually, Linux itself is just the operating system kernel and supporting drivers. Most Linux distributions use the GNU system (http://www.gnu.org), thus they are called GNU/Linux distributions. There are hundreds of available GNU/Linux distributions, but even the "top 5" are different in their default commands, startup scripts, filesystem layout, included utilities, and packaging systems.

What does this mean to you? Unlike Windows NT, including Windows 2000, it is a far more complex process to describe how to harden a UNIX/Linux server. This next section provides some common procedures that can be applied across UNIX versions and GNU/Linux distributions. Following that are some pointers to living documents on the Internet, which track available data and releases, and go into a more detailed account of how to harden a server for a particular task.

Common Steps for Hardening UNIX/Linux Servers

The process of building a UNIX or GNU/Linux server for use as a firewall or DMZ server begins with installation. Eliminating points of attack, such as filling the filesystem, or removing unnecessary libraries and services, is equivalent to removing possible entry points for intruders.

Some common guidelines for configuring UNIX servers with a more secure default stance are available from CERT's Web site at ftp://info.cert.org/pub/tech_tips/UNIX_configuration_guidelines.

Partition for Protection

Besides having separate partitions for the obvious, such as SWAP and /tmp, you should protect against out-of-disk-space denial-of-service attacks. Intruders might try to create excessive generation of logging data or fill your file system with large files through FTP or mail spool. The best way to protect against this is to segment the filesystem hierarchy into separate physical partitions.

The root partition / can be small because it generally contains just the kernel—the necessary files, libraries, and configuration for booting in /bin, /sbin, /etc, and /lib. Access to the attached devices is provided through the /dev and /devices directories. Many GNU/Linux distributions store kernels and symbol data in the /boot directory, whereas kernel libraries are stored under /lib.

The /usr partition is normally where user-accessible applications are stored. Normally, /usr does not contain data or configuration files that change; therefore, an added security measure can be mounted as read-only.

The /var partition stores system logs and data services such as mail, Web, databases, printing, running services, package management, and so on. On a mail server, you might want to make /var/spool/mail, or /var/mail in Solaris, a separate partition, or—even better—a separate disk array. If you only create one separate partition from /, /var is the one you should separate.

The /usr/local directory structure, and in Solaris the /opt directory, often contains locally installed optional software, configuration files, and data. /usr/local is normally not affected by operating system upgrades. Depending on how you use those directories, they too can be mounted as read-only.

These are suggestions and guidelines only, and are different from recommended settings for a system that contains user accounts, usually in /home.

Disable Extraneous inetd Services

inetd is the UNIX "Internet Super Server." It is a daemon process that is invoked at boot time and reads in a flat file configuration database normally found at /etc/inetd.conf. inetd listens for incoming connections on the defined IP ports. When a connection is initiated on a defined port, it invokes the configured program to service the request. After the connection is finished, the process invoked to service that request terminates. This was originally designed to lighten the load and resources required for systems.

There are a number of services enabled through inetd, and almost all of them should be disabled for building firewalls and DMZ servers. Besides normally disabling FTP, TFTP, Telnet, and the Berkeley r* commands, disable the following:

  • in.named—BIND name services daemon. Except for your DNS servers, you should not be running DNS on your firewall or DMZ servers.

  • in.fingerd—Finger daemon that can be used to show user information and lists of users who are logged in. There is no reason to advertise that information to would-be intruders.

  • daytime—Connections to this service display the date and time on the system in a string format. Getting the date and time of a system is useful for an intruder trying to implement replay attacks.

  • time—Connections to this service return the time as a 32-bit value representing the number of seconds since midnight 1-Jan-1900. Do not provide intruders with your exact system time.

  • echo—This is a diagnostic service that echoes incoming data back to the connecting machine.

  • discard—This is a diagnostic service that does not echo (thus discarding) the incoming data stream back to the connecting machine.

  • chargen—This is a diagnostic service that automatically generates a stream of characters sent to the connecting machine.

  • systat—Connections to this service provide a list of all processes and their status.

  • netstat—Connections to this service provide a list of current network connections and their status.

Install and Configure tcp_wrappers

Install and configure Wietse Venema's tcp_wrappers on both your firewall and DMZ servers. tcp_wrappers allows you to define access control to various services, depending on a limited set of criteria, such as username, IP address, or DNS domain.

You might be asking why it's necessary to configure and install additional products when your firewall will be doing the same thing. And that's a valid question. The answer is to avoid single points of failure, and to provide security in layers. If one layer is pierced and bypassed, other layers will be standing guard behind the breach.

tcp_wrappers are lightweight and extremely useful on internal servers; not just on firewalls and DMZ servers. Keep in mind that most information security breaches, intentional or accidental, happen internally. It's only the external defacements, massive distributed denial of service (DDoS) attacks, virus-du-jour, and stolen credit card databases that grab the press. That, and misplaced hard drives with highly sensitive nuclear information.

tcp_wrappers have two main files that allow access to the individually defined services. The following two files are checked for rules governing access to individual or wildcard services:

/etc/hosts.allow
/etc/hosts.deny

Like most firewalls, access is granted or denied on the first matching rule. The rules are checked in order, first in hosts.allow and then in hosts.deny.

Care should be taken when using the KNOWN or UNKNOWN wildcards. ALL will always match whatever criteria you are testing. Read the hosts_access manual page included with tcp_wrappers for further details on syntax and rules setup.

tcp_wrappers is installed and configured by default on most GNU/Linux distributions and BSD releases. For those UNIX systems that do not have tcp_wrappers installed by default, they can be found at ftp://ftp.porcupine.org/pub/security/index.html. Retrieve the source, compile, and install the binaries on the servers.

Lock Down Your DNS Server

The Berkeley Internet Name Daemon, or BIND, is the reference implementation of the name service providing DNS for the Internet. The Internet Software Consortium (ISC) is responsible for implementing and maintaining BIND. There are three basic versions of BIND: BIND 4, BIND 8, and (recently) BIND 9.

BIND 4 has been around forever, and has its share of exploits. Only very old versions of UNIX systems and GNU/Linux distributions came with BIND 4. Still, you'll be surprised how many installations still have the older BIND 4 running. You should upgrade to a newer version of BIND. The unfortunate thing is that the file format defining the zones served by the server has changed. There are conversion scripts, but there is sure to be some hand editing.

BIND 8 is the current stable release, and offers many more features and better control and granularity in access control. The settings described later are discussed with BIND 8 in mind.

BIND 9 was released late in 2000. It offers many new features, such as IPv6 support, DNSSEC, full Dynamic DNS, incremental zone transfers, multiple views (internal, external, and so on) from a single server, and scalability improvements. If any of those features are important to your configuration, you should investigate using BIND 9; otherwise, it's best left to the adventurous.

Although almost all UNIX systems and GNU/Linux distributions come with BIND as the name server, it is important you make sure you are at a recommended release. Before deploying a DNS server, internally or on the DMZ, make sure it is at least version 8.2.2-P5. Any version prior to that has serious exploits. This warning should not be ignored. The Internet Software Consortium themselves have issued a statement that if you are running any version of BIND prior to 8.2.2-P5, you should assume your server has already been compromised. Check your UNIX system or GNU/Linux distribution. If the version of BIND is not at least 8.2.2-P5, check with your vendor for upgrades. If an upgrade is not available, you can compile a version of BIND yourself on a workstation, and install the binaries on your server. The source code can be found at http://www.isc.org/products/BIND/.

First, restrict zone transfers to specific secondary servers in your primary zones. The acl command allows you to define an access control list composed of blocks of addresses to be used with a named identifier. Using ACLs provides a self-documenting method of administrating the named.conf configuration file. In the following example, we define two ACLs comprising our externally visible DNS servers and the secondary servers at our ISP:

acl your-company-dns {
 172.16.30.12;
 172.16.30.24;
};
acl your-ISP-dns {
 199.177.202.10;
 204.95.224.200;
};

The following allow-transfer option directive placed in your named.conf file will default all defined zones to only allow transfers for the defined hosts:

options {
 allow-transfer { 
  your-company-dns; 
  your-ISP-dns;
 };
};

You can override the allow-transfer statement in the options directive by placing the allow-transfer statement in the zone definition:

zone "yourdomain.com" {
 type master;
 file "db.yourdomain-com";
 allow-transfer { 172.16.30.12; 192.168.71.200; };
}

The default allow-transfer option will prevent zone transfers to hosts not specified in the ACLs. However, if you want to restrict all zone transfers on your secondary servers and any secondary zones on your primary servers, use predefined match list none. This can be accomplished with the following allow-transfer directive in your zone definitions:

zone "yourdomain.com" {
 type slave;
 file "db.yourdomain-com.s";
 masters { 192.168.71.1; };
 allow-transfer { none; };
};

Finally, because you will be allowing recursive queries through your servers, it's best to enable access control lists for your internal networks. Using a nested, named acl with the allow-query option in the zone definition, you can then restrict recursive queries to internal hosts only as seen in the following example:

acl internal-net {
 192.168.71.0/24; 
};

acl dmz-net {
 172.16.30.0/24; 
};

acl trusted-hosts {
 localhost;
 internal-net; 
 dmz-net;
};

zone "yourdomain.com" {
 type master;
 file "db.yourdomain-com"
 allow-query { trusted-hosts; };
};

Que's Concise Guide to DNS and BIND by Nicolai Langfeldt is a wonderful resource to further grok BIND configuration and maintenance.

Tighten Sendmail Default Options

Send mail comes with just about every UNIX/Linux installation as the default mail transfer agent (MTA). As a result of being so widely installed, it has been estimated that sendmail handles a majority of the email on the Internet. Because it runs as suid root, sendmail exploits affect millions of machines.

sendmail version 8.11.0 is available at the time of publication, and supports new features such as STARTTLS and SMTP AUTH encryption. Upgrade to the newest version available, if possible, but please make sure that you are running a version no later than version 8.9.3 because of security exploits.

To enable the Realtime Blackhole List feature, use the following in your sendmail.mc file:

FEATURE(rbl)dnl

Additionally, you might want to disable the SMTP VRFY and EXPN commands in sendmail. These commands are often used by intruders to gather information about your system:

define(´confPRIVACY_FLAGS', ´novrfy,noexpn')dnl

There are several additional flags you can set to make sendmail have a more secure stance:

  • authwarnings—Add X-Authentication-Warning header in messages on certain conditions that might indicate mail system spoof attempts.

  • needmailhelo—Require that the sending site uses the SMTP HELO command first when connecting to send email.

  • needexpnhelo—Require that the sending site uses the SMTP HELO command before allowing any EXPN usage.

  • needvrfyhelo—Require that the sending site uses the SMTP HELO command before allowing any VRFY usage.

  • noreceipts—Disable Delivery Status Notification (DSNs) of delivery and read receipts.

  • goaway—Set all flags except restrictmailq and restrictqrun.

  • restrictmailq—Prevent users from using the mailq command to view the contents of the mail queue.

  • restrictqrun—Stop users from processing the queue.

Better than sendmail: Making Postfix Your MTA

According to its Web page, Postfix's goals are "to be fast, easy to administer, and secure, while at the same time being sendmail compatible enough to not upset existing users."

Postfix was primarily written by Wietse Venema of tcp_wrappers fame. Postfix was designed to be modular, thus Postfix is not a single executable like sendmail; rather, Postfix comprises a collection of specialized programs that perform specific tasks. All the programs except for the master control process (oddly called master because it runs without root privilege) run as nonprivileged users, limiting the damage an attacker can inflict on your system. Because of the speed, ease of configuration (and thus less chance of misconfiguration), and security, it is recommended that you investigate replacing sendmail with Postfix. For those of you who do not dream in sendmail.cf syntax, Postfix will make email administration both easier and more secure.

Postfix is now distributed with most GNU/Linux and BSD releases, although it is not often installed by default. Usually, it is a simple matter of installing it via your package management system, or (in the BSD case) via the ports collection.

If you are using an operating system that does not distribute Postfix, despair not. You can download and compile the sources easily on a development workstation and then install the binaries on your mail server. The sources, FAQs, and documentation can be found at http://www.postfix.org/

Linux-Specific Tasks

There are many GNU/Linux distributions out there. Each vendor has its own installation process, which usually changes between new versions of the vendor's distribution. The "forerunners" of GNU/Linux distributions are Red Hat, SuSE, TurboLinux, Mandrake, Caldera, Slackware, and Debian. That does not mean specifically that you should use any one of them because the high number of distributions allows vendors to tailor their GNU/Linux distributions to specific tasks such as embedded systems, routers, and firewalls. Take the time to carefully investigate the available distributions, and determine which best fits your needs.

With that said, two of these general distributions stand out, but for different reasons. Red Hat, because it has had the most name recognition, and is usually the first to get any sort of corporate support in the way of commercial software or commercial technical service. Many vendors, such as Oracle, IBM, and Check Point, have released products for Red Hat-specific distributions. This does not mean that those software releases will not run on other GNU/Linux distributions, but if there is a problem, the vendor might not support your installation of its product on a non-Red Hat distribution.

Debian is the second distribution that deserves mention. First, not because it is entirely free, but because it is maintained by a nonprofit organization made up entirely of volunteers. These volunteers are highly motivated by quality and pride in their efforts to make Debian the most stable and completely 100% free distribution available. Debian has proven to be extremely stable and easy to manage and upgrade remotely. The upgrade process is by far the easiest of any of the GNU/Linux distributions. Debian installations can be upgraded without the need for reboots, replacing every installed package and running process excepting the kernel. Additionally, the Debian packaging system and its front ends allow extremely fine-grained control over which packages, utilities, libraries, and files exist on your system. Debian also is currently available on six different architectures, with more than 3,900 included software packages to select from when installing.

For both Debian and Red Hat installations, you should choose custom installations, and select the individual packages you want on your system. There should be no need to install development packages, any of the new KDE or GNOME desktops, and certainly not X Window. Unfortunately, neither distribution yet has a minimal secure server or firewall predefined install-set.

During the installation process, you should choose to enable shadow password file support; choose to use MD5 hashes for the passwords rather than the normal crypt function. If you miss these options during the install, you can change them after installation. In Red Hat, use the setup utility. In Debian, you can use the shadowconfig utility to enable or disable shadow passwords. To enable MD5 hashes, you have to edit the appropriate files under /etc/pam.d to include md5 on the password lines.

You should also enable ipchains support, even if this is an application server on the DMZ. ipchains provides additional layers of security, and allows you to protect the server from traffic should the firewall fail for some reason. A sample ipchains configuration is discussed later in the article.

You should additionally read and monitor the security and errata/updates lists from your distribution vendor. With Debian, it is extremely easy to automatically install security updates using the apt-get utility. For Red Hat installations starting with the 6.0 release, there is the up2date utility to retrieve updated packages for your release.

For those people who choose to install Red Hat Linux, there is a security-related project called Bastille Linux, whose aim is not just to harden your Linux installation, but to educate the administrators on how to harden the system. Bastille Linux supports Red Hat and Mandrake Linux distributions with project goals to become distribution, and UNIX flavor, agnostic. The Bastille Linux product is a set of scripts that asks a series of questions and then allows you to apply those modifications to your system. The questions describe what needs to be done, why it should be done, and why you might not want to do it. It is very educational, especially for those administrators just getting familiar with Linux. Bastille Linux can be found at http://www.bastille-linux.org/.

Another excellent source of information for administrators is the Linux Administrator's Security Guide. It covers an extremely wide array of topics related to Linux and security. You can find the Linux Administrator's Security Guide online at http://www.securityportal.com/lasg/.

Solaris-Specific Tasks

Solaris has four default install-sets: Core, End-User, Developer, and Entire Distribution. Installing any install-set higher than the Core installation will enable more services than are required for DMZ servers or firewalls. In reality, you can often remove a significant percentage of the default Core install-set, depending on your server's application requirements.

For Solaris-based servers, there are several excellent documents from Sun in its Blueprints Online archive at http://www.sun.com/software/solutions/blueprints/online.html. The following three papers are excellent starting points for building secure Solaris servers:

  • "Solaris Operating Environment Minimization for Security: A Simple, Reproducible and Secure Application Installation Methodology" by Alex Noordergraaf and Keith Watson. Although this paper specifically covers the iPlanet Web server requirements, similar requirements are necessary for using Apache or other Web servers.

  • "Solaris Operating Environment Security" by Alex Noordergraaf and Keith Watson. An overview of general security options on a Solaris server. This paper includes some specifics for the SPARC architecture; however, most of the material is applicable to Intel architectures as well.

  • "Solaris Operating Environment Network Settings for Security" by Alex Noordergraaf and Keith Watson is another excellent paper on kernel tuning and application parameters that affect network security.

As a matter of fact, Sun's Blueprints Online is a wealth of whitepapers outlining Best Practices regarding Solaris Operating Environments, whether it is a DMZ Web server, firewall, or internal highly available database cluster.

Lance Spitzner also has an excellent Solaris hardening document that details the hardening process for building a Check Point FireWall-1 firewall on several recent versions of Solaris (through version 8) for the Intel and SPARC platforms. The living document resides at http://www.enteract.com/~lspitz/armoring.html.

Finally, there is an equivalent to the Bastille-Linux hardening scripts for Solaris called TITAN. The TITAN project and documentation can be found at http://www.fish.com/titan/.

OpenBSD-Specific Tasks

This section concentrates on OpenBSD 2.7, which is one of the three more famous BSD variants; the others being NetBSD and FreeBSD. Each variant has focused on a different problem: NetBSD is the most portable, FreeBSD has the best performance, and OpenBSD is the most secure.

One of the great strengths of OpenBSD is the highly secure default stance of a default install of OpenBSD. The OpenBSD Web site claims "three years without a remote hole in the default install, only one localhost hole in two years in the default install." Almost all services are disabled until the administrator has enough experience to properly configure them.

Two additional changes necessary for an OpenBSD box to become a firewall are to disable sendmail and enable IP filter support. Both changes are made to the same file, /etc/rc.conf. To disable sendmail, change

sendmail_flags="-q30m"

to

sendmail_flags=NO

To enable IP filter support, you must change

ipfilter=NO

to

ipfilter=YES

Additionally, if you will be doing Network Address Translation (NAT), providing transparent proxying, or providing support for FTP, you must enable the ipnat option by setting ipnat=YES. Syntax for IP filters will be covered briefly later in the chapter.

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.

Overview


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.

Surveys

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.

Newsletters

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.

Security


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

Children


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

Marketing


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.

Choice/Opt-out


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.

Links


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