Linux Network Administration II, Network Security and Firewalls - Student Notebook (IBM Learning, 2003, Course Code LX24)

V3.
cover
Front cover
Linux Network
Administration II: Network
Security and Firewalls
(Course Code LX24)
Student Notebook
ERC 3.0
IBM Certified Course Material

Student Notebook
Trademarks
IBM® is a registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United
States, or other countries, or both:
AIX® DB2® Domino™
Lotus® MQSeries
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the
United States, other countries, or both.
Microsoft, Windows and Windows NT are trademarks of Microsoft Corporation in the
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Linux is a registered trademark of Linus Torvalds in the United States and other countries.
Other company, product and service names may be trademarks or service marks of others.
October 2003 Edition
The information contained in this document has not been submitted to any formal IBM test and is distributed on an “as is” basis without
any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer
responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. While
each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will
result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.
© Copyright International Business Machines Corporation 2000, 2003. All rights reserved.
This document may not be reproduced in whole or in part without the prior written permission of IBM.
Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions
set forth in GSA ADP Schedule Contract with IBM Corp.
V3.0
Student Notebook
TOC Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Course Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Certification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Unit 1. Introduction to Network Security and Firewalls . . . . . . . . . . . . . . . . . . . 1-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Physical Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Network Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Authentication and Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Hackers, Crackers and Script Kiddies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
Motivation of Hackers and Crackers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Types of Attack (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Types of Attack (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
What You Have to Lose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
Forms of Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
What is a Firewall? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20
Position of a Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
DMZ and Packet Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
NAT, Socks and Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
E-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25
Domain Name System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
The Company Webservers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27
Virtual Private Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
The Complete Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29
What a Firewall Does Not Protect Against . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Network Security Techniques Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-34
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35
Unit 2. Installing and Securing Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Installing Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Apply Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Kernel recompile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Hardening Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
BIOS Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Boot Loader Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
User Account Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Disable Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
© Copyright IBM Corp. 2000, 2003 Contents iii

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Student Notebook
Filesystem Hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-15

Disable Ctrl-Alt-Del . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-16
/etc/issue, /etc/issue.net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-17
/etc/motd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-18
$TMOUT Shell Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-19
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-20
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-21
Unit 3. The TCP/IP Protocol Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2
TCP/IP Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3
IP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4
IP Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5
IP Address Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6
IANA Address Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8
IP Address Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9
IP Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-11
Important IP Header Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13
The ICMP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15
ICMP Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-16
Important ICMP Message Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18
UDP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-19
UDP Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-20
Important UDP Header Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-21
TCP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-22
TCP Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23
TCP Connection Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-25
Important TCP Header Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27
Tracing Network Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-29
Tcpdump Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-30
Understanding tcpdump Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-31
Kernel Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-32
Kernel Configuration Options (ICMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-33
Kernel Configuration Options (IP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-34
Kernel Configuration Options (TCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-35
Kernel Configuration Options (Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-36
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-38
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-39
Unit 4. Packet Filtering and Network Address Translation . . . . . . . . . . . . . . . . 4-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2
Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3
Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
Chains (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
Chains (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7
Packet Filtering in Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8
The iptables Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9
iptables Basic Syntax (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10
iv Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
TOC iptables Basic Syntax (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12

Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
iptables Initial Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
Protect against Spoofed Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
Configure ICMP Echo Request/Reply Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
Configure other ICMP Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
Configure Outgoing TCP/UDP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
Identd Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
iptables Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
iptables Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
IP Masquerading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
Configuring IP Masquerading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Configuring NAT for Difficult Situations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
Saving and Restoring iptables Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30
Restoring iptables Rules on Startup (Red Hat) . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31
SuSEfirewall2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
FWBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
Other iptables Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-37
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-38
Unit 5. Secure Shell and Secure Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Telnet, ftp, rexec, rsh, rcp Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
SSH Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
SSH Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
ssh Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
scp Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
sshd Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
ssh/sshd Host Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
sshd User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
RSA Challenge-Response Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
DSA Challenge/Response Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Protecting Your Private Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
SSH X Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
SSH Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
SSH Firewall Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
Unit 6. Socks Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Socks Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Advantages and Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Linux Socks Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Dante Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Sample /etc/sockd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
Starting and Stopping sockd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
© Copyright IBM Corp. 2000, 2003 Contents v

Student Notebook
Socksifying Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-10

Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-12
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13
Unit 7. Proxy Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2
Proxy Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3
Advantages and Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4
Linux Proxy Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6
Configuring Apache for Proxy Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7
Installing, Configuring and Starting Squid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8
/etc/squid.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9
Summary Visual: NAT, Socks, Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-10
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-12
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-13
Unit 8. Securing DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2
DNS Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3
DNS Name Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5
DNS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-7
Scenario (DMZ Situation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9
Internet Primary DNS Server Config File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10
Internet Primary DNS Server Name Zone File . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-11
Internet Primary DNS Server IP Zone File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-12
Internet Secondary DNS Server Config File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-13
Intranet DNS Server Config File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14
Intranet DNS Server Name Zone File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-15
Intranet DNS Server IP Zone File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16
DNS Query Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-17
DNS Packet Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-18
DNS iptables Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-19
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-20
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-21
Unit 9. Securing E-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2
E-mail Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3
Mail Gateway and Mail Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
Mail Servers for Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
Configuring Sendmail as Mail Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
Configuring Postfix as Mail Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9
Configuring Sendmail as Mail Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10
Configuring Postfix as Mail Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12
Configuring DNS for Mail Relaying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-13
Limiting Message Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-14
Blocking Junk E-mail (Spam) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15
SpamAssassin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-16
vi Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
TOC Installing SpamAssassin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18

Real-Time Blacklisting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
Detecting Viruses in Attachments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21
Installing AMaViS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-23
SMTP Firewall Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-26
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-27
Unit 10. Virtual Private Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Virtual Private Networks Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Virtual Private Network Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
IPSec Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6
IPSec Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
Authentication Header Protocol (AH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
Encapsulating Security Payload (ESP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9
Internet Key Exchange (IKE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10
FreeS/WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11
Installing FreeS/WAN from Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-12
Installing FreeS/WAN (Red Hat/SuSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13
Activating FreeS/WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15
Session Key Exchange and Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16
/etc/ipsec.conf Global Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-18
/etc/ipsec.conf Manual Keyed Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20
Automatically Negotiated Session Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-22
Manual Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-23
RSA Public Key Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-24
Storing Public Keys in DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-25
Firewall-to-Firewall and Firewall-to-Subnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-27
Additional IPSec Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-28
Verifying Connections With tcpdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-30
Useful Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-31
IPSec iptables Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-32
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-33
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-34
Unit 11. Hackers’ Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Categories of Hackers’ Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
Sniffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Ethereal Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Ethereal Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
Fingerprinters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8
Port Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-9
Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10
Nmap Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11
Nmap Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12
Intrusion Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-13
© Copyright IBM Corp. 2000, 2003 Contents vii

Student Notebook
Nessus Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-14

Nessus Installation (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-15
Nessus Installation (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-16
Nessus Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-17
Nessus Output Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-18
Other Hackers’ Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-19
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-21
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-22
Unit 12. Detecting and Countering Firewall Intrusions . . . . . . . . . . . . . . . . . . 12-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-2
Detecting Attack Attempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3
Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-4
Do-It-Yourself Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-6
Filesystem Integrity Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-8
Tripwire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-10
Tripwire Installation and Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-12
Network Intrusion Detection Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-14
Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-15
Snort Sniffer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-16
Snort Packet Logging Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-17
Snort NIDS mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-18
Snort Rulesets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-19
Logfile Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-20
Swatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-21
Swatch Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-22
Swatch Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-23
Swatch Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-25
Swatch “tail -f” Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-26
Swatch Daemon Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-27
General Logging Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-28
Countering Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-29
Deception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-32
Checkpoint Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-34
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-35
Unit 13. Good Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-2
Computer Security is a Way of Life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-3
User Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-4
Administrator Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-5
Custom Programs and Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-6
Network and System Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-8
Day-to-Day Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-10
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-12
viii Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
TOC Appendix A. Introduction to Cryptography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Appendix B. Checkpoint Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1
Appendix C. Certification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
Bibliography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .X-1
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .X-3
© Copyright IBM Corp. 2000, 2003 Contents ix

Student Notebook
x Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
TMK Trademarks
The reader should recognize that the following terms, which appear in the content of this
training document, are official trademarks of IBM or other companies:
IBM® is a registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United
States, or other countries, or both:
AIX® DB2® Domino™
Lotus® MQSeries
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the
Microsoft, Windows and Windows NT are trademarks of Microsoft Corporation in the
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Linux is a registered trademark of Linus Torvalds in the United States and other countries.
Other company, product and service names may be trademarks or service marks of others.
© Copyright IBM Corp. 2000, 2003 Trademarks xi

Student Notebook
xii Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
Uempty Course Description

Linux Network Administration II: Network Security and Firewalls
Duration: 5 days
Purpose
This course is designed to teach the student how to implement a
Linux-based firewall.
Audience
This course is designed for experienced Linux and networking
professionals who are responsible for configuring and maintaining a
Linux-based firewall.
Prerequisites
• LX02: Linux Power User
• LX03: Linux System Administration I: Implementation
• LX41: Linux System Administration II: Host Security
• LX07: Linux Network Administration I: TCP/IP and TCP/IP services
Objectives
After completion of this course, students should be able to:
• Discuss network and system security, and the place of a firewall
therein
• Install and harden Linux
• Configure packet filtering and network address translation
• Configure socks and proxy services
• Configure DNS on a firewall
• Configure E-mail forwarding on a firewall
• Configure Virtual Private Networking
• Configure and use hackers’ tools
• Detect and counter firewall intrusions
Curriculum relationship
• LX02
• LX03
• LX41
• LX07
© Copyright IBM Corp. 2000, 2003 Course Description xiii

Student Notebook
xiv Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
Uempty Agenda
Day 1
Welcome
Unit 1 - Introduction to Network Security and Firewalls
Unit 2 - Installing and Securing Linux
Exercise 2 - Installing and Securing Linux
Unit 3 - The TCP/IP Protocol Suite
Exercise 3 - The TCP/IP Protocol Suite
Day 2
Unit 4 - Packet Filtering and Network Address Translation
Exercise 4 - Packet Filtering and Network Address Translation
Unit 5 - Secure Shell and Secure Copy
Exercise 5 - Secure Shell and Secure Copy
Day 3
Unit 6 - Socks Service
Exercise 6 - Socks Service
Unit 7 - Proxy Service
Exercise 7 - Proxy Service
Unit 8 - Securing DNS
Exercise 8 - Securing DNS
Day 4
Unit 9 - Securing E-mail
Exercise 9 - Securing E-mail
Unit 10 - Virtual Private Networks
Exercise 10 - Virtual Private Networks
Day 5
Unit 11 - Hackers' Tools
Exercise 11 - Hacker's Tools
Unit 12 - Detecting and Countering Firewall Intrusions
Exercise 12 - Detecting and Countering Firewall Intrusions
Unit 13 - Good Practices
© Copyright IBM Corp. 2000, 2003 Agenda xv

Student Notebook
xvi Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
Uempty Certification Information

Several professional certifications currently exist for Linux. This
course, combined with other Linux courses, will prepare you for all of
them. For more information, see appendix C.
This course, in combination with other courses, has been certified by
ProCert (http://www.procert.com) as appropriate course material for
preparing for LPI certification tests. The statement below reflects this.
Linux Professional Institute Statement

“This course is specifically designed to provide you with the skills,
knowledge and understanding required to become professionally
certified by LPI. To learn more about LPI certifications, or to register to
take an official LPI certification exam, visit www.lpi.org.”
© Copyright IBM Corp. 2000, 2003 Certification Information xvii

Student Notebook
xviii Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
Uempty Unit 1. Introduction to Network Security and

Firewalls
What This Unit Is About

This unit gives you an introduction to Network Security and Firewalls.
What You Should Be Able to Do

After completing this unit, you should be able to:
• Describe the purpose of a Security Policy
• Identify the role of a Firewall in a Security Policy
• Describe different types of Firewalls
• Describe different types of Attacks
How You Will Check Your Progress

Accountability:
• Checkpoint questions
© Copyright IBM Corp. 2000, 2003 Unit 1. Introduction to Network Security and Firewalls 1-1
Student Notebook
Objectives
Describe the purpose of a Security Policy
Identify the role of a Firewall in a Security Policy
Describe different types of Firewalls
Describe different types of Attacks
Figure 1-1. Objectives LX243.0
Notes:
1-2 Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
Uempty
Security Policy
Document describing the way computer equipment
may/may not be used
Preventing unauthorized use of computer equipment
Ensuring uninterrupted service to legitimate users
Should be decided by management
Should be implemented and enforced by
hardware/software setup
Different aspects:
Physical security
Network security
Authentication
Authorization
Evolves over time
Figure 1-2. Security Policy LX243.0
Notes:
Before you start implementing any security measures on any computer system, it is
important to ask yourself: What are you protecting? Why? Against whom? What for?
These are all legitimate questions. It is important to identify what equipment needs what
level of protection. It is important to define what acceptable and unacceptable usage of a
computer system is. And since the answers to these questions are usually directly or
indirectly related to money1, these questions should probably not be answered by the
system administrator, but by management.
It is the job of the manager to define the "Security Policy", the document which describes
the intended use of the computer equipment and with that the way computer equipment
may or may not be used.
It is then the job of the administrator to actually implement this policy on the computer
equipment.
There are several aspects to a security policy:
1
If a company defines downloading MP3 files from the Internet “acceptable use”, they need considerably more bandwidth than if they
don't consider it as such. Bandwidth costs money. And there are plenty more examples.
Student Notebook
• Physical security: Everything that has to do with the physical security of the computer.
This includes prevention of theft, fire, flooding and so forth.
• Network security. This includes every action that can be performed over a network,
without physically having to be near the computer.
• Authentication. This is the act of establishing that a user is really who he says he is.
• Authorization. This is the act of determining whether a user has permission to perform
certain actions.
Most security policies evolve over time. Consider the dramatic growth of the Internet for
instance. Three years ago, e-mail was not something commonly used in a lot of
companies. Today, e-mail has become indispensable. A security policy should be updated
to reflect this trend.

V3.0
Student Notebook
Uempty
Physical Security
Ensure that nobody can access computer hardware
Locks on doors
Access codes
Signing-in of staff
Physical protection of cabling
Physical environment
Uninterruptible Power Supply (UPS)
Fire suppression system
Air Conditioning (heat, moisture)
Physical breakdown of computer hardware
Spare components
Backups (consider off-site storage)
Figure 1-3. Physical Security LX243.0
Notes:
Physical security is everything that prevents unauthorized physical access to computer
equipment. This seems obvious, but I remember a story about a high school which had a
physical break-in. At first glance, nothing seemed to be stolen, but when people started to
boot their computers, none of them worked. As it turned out, the thieves had stolen the
CPUs from all of the computers.
Obviously this is an extreme situation. Nevertheless, physical protection of computer
equipment is important. You need to lock doors, you need to have a policy about who has
access to which server room, and you might need to consider a sign-in policy. In a large
server room, to which different groups of people have access, you might even consider
putting each server in it's own lock-protected box. Don't forget computer equipment outside
the server room, like printers. And don't forget to physically protect your cabling so that it is
impossible to make an illegal connection to the network.
Physical security is also about protecting your equipment from the bad things that happen
in the environment. You might need an Uninterruptible Power Supply (UPS) in case of a
power outage. Obviously fire is another thing you need to protect against. And last, your
Student Notebook
computer system might have fairly strict environmental parameters regarding heat and
moisture. You might need air conditioning to stay within these parameters.
The last aspect of physical security is being able to cope with the situation if something bad
happens. Basically it comes down to having spare parts for crucial components (or a good
contract with a parts supplier) and backups of your data (preferably off-site).

V3.0
Student Notebook
Uempty
Network Security
Ensure that no unauthorized user can access the system
over the network
Internet
Modem
other WAN
LAN
Needs to be done for every networked system
Figure 1-4. Network Security LX243.0
Notes:
Network security is basically the act of ensuring that no unauthorized user can access the
system over the network. This seems simple but is actually far harder to achieve than
physical security. Plus, it needs to be done for every individual networked system over and
over again, and for every potential network connection a computer system has.
Student Notebook
Authentication and Authorization

Authentication: Establishing who you are
Username/Password
Public key cryptography
Smartcards
Biometrics
Authorization: Determining what you may do
Usually dependent on group membership
Figure 1-5. Authentication and Authorization LX243.0
Notes:
Authentication is basically the act of establishing who you are. This is usually done with a
username/password combination, which is (supposedly) only known to you. However, a
number of other authentication techniques can be used too:
• Public key cryptography is sometimes used to establish your identity. This is for
instance used in PGP (Pretty Good Privacy), which can be used to encrypt e-mail, and
RSA, a cryptographic protocol which allows you to prove your identity in an SSH
connection. (This will be covered in unit 5.)
• Smartcards are usually credit-sized cards with a little microchip on it. They are inserted
in a special slot in a computer and are used for verifying your identity. This can be very
useful in environments where a lot of people might use the same terminal, each for a
very short period of time, such as a hospital, university or retail shop.
A variation on this is a smartcard which looks like a pocket calculator, but which
produces a one-time key which depends on the time of the day. This key is generated
by a secret algorithm (or public algorithm depending on a secret key). That same
algorithm is duplicated in a server and by typing in the correct code, you are

V3.0
Student Notebook
Uempty authenticated. (On the other hand, if you were to lose this card, the finder could use it to
authenticate himself as being you. Therefore these systems are usually password
protected as well.)
• The latest method of authentication is biometrics. In biometrics, a unique aspect of your
body (such as your fingerprint or retina pattern) is scanned and used to establish that it
is really you. Biometrics are an excellent way of authenticating people, but are not used
much because they interfere with a lot of privacy laws. (Most biometrics are actually
regarded as medical secrets.)
Once you are authenticated, you also need to be authorized. Authorization is the act of
establishing what you may do. In Unix, this is usually done by adding you to a special
group. All members of this group then are authorized to do a certain thing, because the
permissions on specific files and directories allow them to.
Student Notebook
Hackers, Crackers and Script Kiddies

A hacker is someone who wants to satisfy his curiosity
Means no harm
May cause harm accidentally
A cracker is someone who wants to gain something
Access to your system to use resources
Access to data (e.g. credit card numbers)
Publicity
Revenge
A Script Kiddie is someone who uses hackers tools
without understanding what they do
To a firewall administrator, there is no difference
All can cause harm
From the type of activity you cannot distinguish them
Figure 1-6. Hackers, Crackers and Script Kiddies LX243.0
Notes:
There are three types of people which you have to fear as a system or network
administrator: hackers, crackers and script kiddies.
A hacker is someone who is interested in technology and wants to satisfy his curiosity. He
(or she) wants to know how things work, how things are configured and whether things can
be improved. The most important aspect of a hacker is that he means no harm. But he
might cause harm by accident.
A cracker is someone whose intention it is to gain something. This might be access to your
system to use its resources (disk space, CPU time, network bandwidth), or access to your
data (credit card numbers or other confidential data). A cracker may also want to gain
publicity and some crackers even want revenge.
A script kiddie is someone who has virtually no knowledge about the systems and protocols
involved, but uses the tools that are typically written by hackers and/or crackers to break
into systems. The difference between a script kiddie and a cracker is sometimes slight: You
could say that a cracker is able to exploit a bug himself, while a script kiddie needs
somebody else to write the exploit tool.

V3.0
Student Notebook
Uempty To a system administrator, there is no difference in approach to hackers, crackers and

script kiddies. The reason is twofold: both can cause harm to your carefully configured
system, and from the type of activity you usually cannot distinguish between them.
Student Notebook
Motivation of Hackers and Crackers

Curiosity
Challenge
Prestige
Corporate, political espionage
Confidential information, intellectual property
Proprietary software
Access to resources
Disk space
CPU time
Monetary
Credit card numbers
Base of operation for attacks on other sites
DDoS
Untraceable junk mail
Figure 1-7. Motivation of Hackers and Crackers LX243.0
Notes:
There are various reasons why a hacker or cracker may want to try to break into your
systems. The visual above lists only a small number of possible reasons.
Curiosity is the most innocent form of hacking. Lots of hackers are interested in how you
built your system, how you configured things. By breaking into your system they can figure
that out.
Challenge is also a good reason for a hacker to break into your system. Especially if you
start bragging in the media about how good your system security actually is...
Corporate, political espionage is the modern variant of Watergate. It does not happen often
and when it happens these types of attacks rarely hit the media. But you can be sure that
there are people out there who would love to take a peek at (for instance) your financial
records, to decide whether to buy or sell shares in your company.
Access to resources can also be a reason for a break-in attempt. The most interesting
resource is disk space on a publicly accessible server, where hackers can then trade
"warez", usually illegal software.

V3.0
Student Notebook
Uempty A hacker can also have a monetary motivation. Think what would happen if a hacker
gained access to the credit card numbers of all the people that bought goods on your
website last month. He might not even use them, but blackmail you with it.
The last motivation of a hacker to break into your site is to use your site as a base of
operations for further attacks. There are two reasons for this: by hopping from site to site it
becomes very hard to trace the hacker. And by breaking into multiple sites and leaving a
small Denial-of-Service (DoS) program such as stacheldraht on the server, he can easily
initiate a Distributed Denial-of-Service attack (DDoS) on another server. This has no direct
consequences to the security of your site, but might cost resources and might cause you to
face liability damages.
Student Notebook
Types of Attack (1)

Scanning
Which services are enabled
Which software and version is used
Sniffing
Monitoring data (e.g. passwords) in transit
Break-in
Gain access to a computer, preferably as superuser
Brute Force
Try every possible combination until one works
Man-in-the-Middle
Act as the server to a client
Act as a client to the server
Figure 1-8. Types of Attack (1) LX243.0
Notes:
There are various types of attack which might be used by hackers. Most attacks are
actually used in combination with another type.
In a scanning attack a hacker tries to initiate a session with every known service that you
might provide on a certain host. He does this to establish which services are being offered,
and what software version you use to provide that service. This is then usually compared
with a list of known bugs in various software packages.
In a sniffing attack a hacker tries to capture data that is in transit over a network. This data
might contain all sorts of interesting things, one of which is the logon password of a certain
user. Hackers are known to have altered routing tables of routers in order to redirect traffic
along a sniffer which they installed somewhere.
A break-in attempt is usually the result of another type of attack, and usually means that a
hacker is trying to gain user or superuser privileges on a server.

V3.0
Student Notebook
Uempty A brute-force attack basically means that every combination is tried until a combination is
found which works. This is usually done off-line after a password file (/etc/passwd or
/etc/shadow) has been captured.
A man-in-the-middle attack is the situation where a hacker sets up a computer which acts
as the legitimate server to a client, and as a legitimate client to the server. This allows a
hacker to capture and possibly alter the data in transit.
Student Notebook
Types of Attack (2)

Virus
Malicious program that attaches itself to other programs
A macro virus resides in a macro which is typically
stored in a data file
Worm
Self-replicating malicious program
Trojan Horse
Apparently useful program with a malicious component
Denial of Service (DoS)
Prevent legitimate users from working
Usually done by crashing or overloading the system or
network
Distributed Denial of Service (DDoS)
DoS attack from many different sources simultaneously
Figure 1-9. Types of Attack (2) LX243.0
Notes:
A Virus is a malicious program which typically attaches itself to another program. This is
called "infection". When the other program is executed, the malicious program is executed
as well, allowing it to attach itself to even more programs. Macro virus are viruses which do
not use executable programs but use macros in data files (such as Microsoft Word
documents).
A Worm is a malicious program which is able to replicate itself; it does not need another
program to spread itself.
A Trojan horse is a program which does a useful thing but also carries a malicious content.
A Denial of Service attack is an attack aiming at interrupting the service to legitimate users,
usually by overloading or crashing the server. It is very hard to prevent DoS attacks since
they usually involve regular client connections. A DoS attack may also be used to break
into a system since certain programs do not behave well under large loads.
A Distributed Denial of Service attack is a DoS attack from multiple sites (tens or hundreds,
sometimes even thousands) at once.

V3.0
Student Notebook
Uempty
What You Have to Lose
Loss of resources
Disk space
Bandwidth
CPU time
Loss or alteration of data
Loss or impairment of service
Loss of reputation, goodwill, trust
Disclosure of personal, proprietary or confidential
information
Financial loss
Stolen credit card numbers
Legal, criminal action against you
Figure 1-10. What You Have to Lose LX243.0
Notes:
When your systems are under attack, there are certain things you may lose:
Loss of resources is one obvious thing. A hacker almost certainly uses your expensive
bandwidth. He might also consume a large portion of CPU time and/or disk space.
Loss or alteration of data is another obvious thing. Hackers have for instance changed the
content of websites. But the most important thing in this respect is that you cannot be sure
that your data has not been altered.
When a hacker breaks or overloads something, be it by accident or on purpose, legitimate
users cannot use the system anymore.
When a successful attack leaks out to the press, this might cause loss of reputation,
goodwill and/or trust.
Personal, proprietary or confidential data might be stolen from your website and disclosed.
Financial losses might also occur if for instance credit card numbers are stolen.
Student Notebook
And finally, you might face legal actions against you. If your site is being used as a basis of
attack on other sites and you fail to take adequate measures, you might be regarded as a
conspirator or negligent in the court of law.

V3.0
Student Notebook
Uempty
Forms of Protection
No internet connection
Safe but users will set up their own access
Choke point (firewall)
One device where all traffic passes through
Can log activity
Can limit activity
Needs careful setup
No central protection
Requires protection on every host
Gives virtually unlimited internet access
Figure 1-11. Forms of Protection LX243.0
Notes:
There are basically three approaches to protecting yourself from the dangers of the
Internet.
The first approach is obvious: don't connect to the Internet at all. This is a very safe
approach but might backfire on you: users in your company might consider Internet access
useful or essential for their work. If the company doesn't offer Internet access they might
bring their modems to work and set up Internet connections themselves. Your network is
then wide open to attacks and you will not even know it.
The second, most used form is to set up an Internet connection, but force all data to pass
one or a few choke points, commonly called firewalls. This device can then limit and log the
Internet activity.
The last option is to give everyone in the company unlimited Internet access. This is for
instance done at universities and Internet service providers (ISPs), where people need
unlimited Internet access. It does require you to protect every individual host though.
Student Notebook
What is a Firewall?
It is not a single device
It is not a proxy, socks or filter
It is a combination of components which implements
and enforces the security policy
Filtering Router
DMZ (DeMilitarized Zone) or screened subnet
Network Address Translation or IP Masquerading
Socks Server
Proxy Server
Mail Gateway
DNS Server
Tunneling Device
Always customized to local environment and needs
Figure 1-12. What is a Firewall? LX243.0
Notes:
The term "firewall" is one of the most misunderstood terms on the Internet today. When
talking about a firewall, most people think of a black box which is the cure-all end-all of
protection. And people who think they know something about it usually talk about a proxy
or a socks as if it were a firewall. All these people are wrong.
A firewall is a combination of components that implement and enforce the security policy.
And since the security policy of each company is different, each firewall will be different too.
The security policy dictates what the firewall will be like, and dictates the components that
are actually used in the firewall.
There are several components that can be used. They will be discussed in the next few
visuals.

V3.0
Student Notebook
Uempty
Position of a Firewall
Firewall
Filtering Router
DMZ/Screened Subnet
NAT/IP Masquerading
Socks Server The Internet
Proxy Server
Mail Gateway
DNS Server
Tunneling Device
Company Network
Figure 1-13. Position of a Firewall LX243.0
Notes:
The firewall usually sits between the company's network and the Internet.
Student Notebook
DMZ and Packet Filters

Traffic is only allowed from a host on the Company
Network to a host on the DMZ, and from a host on
the DMZ to a host on the Internet
(Filtering based on IP address)
Packet √ The Internet
DMZ X
Filtering
Router X
√
Packet
Filtering
Packet
Router
Filtering
Router DMZ
X
Company Network Company Network
Figure 1-14. DMZ and Packet Filters LX243.0
Notes:
The basis of a firewall is usually a Demilitarized Zone or DMZ2, sometimes also called a
screened subnet. It is connected to the Internet and to the Intranet with routers who are
able to filter the passing IP packets based on IP address, port number, protocol and
direction of connection setup.
The packet filtering routers are essentially configured so that it is only possible to set up a
connection from the Intranet to a device on the DMZ, and from a device on the DMZ to the
Internet. A connection directly from the Intranet to the Internet is not possible, and incoming
connections from the Internet are also prohibited.
The visual shows two different methods of connecting the DMZ:
• On the left hand side, two routers are used. One router sits between the Internet and
the DMZ, the other sits between the DMZ and the internal network. Each router has two
network connections.
2
This term originates from the war between North and South Korea. When the UN moved in to intervene, they created a corridor
between North and South Korea called the Demilitarized Zone. In this area every movement will be scrutinized and possibly shot at.

V3.0
Student Notebook
Uempty • On the right hand side, only one router is used to connect the internet, the DMZ and the
internal network together. This single router thus has three network interfaces.
This setup is less expensive but slightly less secure (instead of having to break into two
routers, a hacker only needs to break into one).
Student Notebook
NAT, Socks and Proxies
NAT Webserver
Socks
Proxy
Packet The Internet

Filtering
DMZ Router
Packet
Filtering
Router
A NAT, Socks or Proxy
accepts a client connection,
Client verifies it and sets up a
second connection to the
Internet to retrieve the data
Company Network
Figure 1-15. NAT, Socks and Proxies LX243.0
Notes:
Three very common devices on the DMZ are Network Address Translators, Socks servers
and Proxy servers. They are used to retrieve information from the Internet, for instance
using the World Wide Web or FTP.
While different in implementation, they basically do the same thing: they accept a client
connection (from the Intranet), verifies that the connection is allowed and then set up a
second connection to the Internet to retrieve the requested data.

V3.0
Student Notebook
Uempty
E-mail
Packet The Internet

Filtering
DMZ Router
Mail
Packet
Gateway
Filtering All email to and from the
Router Internet should pass through
the Mail Gateway.
Mail All connections through the
Client
Server SMTP it are SMTP connections.
Filtering based on IP address
POP/IMAP
and port number (SMTP=25).
Company Network
POP and IMAP are only used
on the Company Network.
Figure 1-16. E-mail LX243.0
Notes:
Another function that needs to be supported by the firewall is the sending and receiving of
e-mail. This is generally done by placing a mail gateway or mail relay3 on the DMZ. This
system then relays the e-mail between the Intranet and the Internet.
Note: All mail clients talk to the mail server on the Intranet, not to the mail relay. Also note
that this requires the packet filtering routers to allow incoming connections. This can be
made more secure by only allowing incoming connections to the IP address of the mail
relay, port number 25.
3 Technically, the term “mail gateway” refers to a device which handles a protocol conversion, in this case, for instance, between internet
mail (SMTP) and Lotus Notes. A “mail relay” does not do a protocol conversion. In common speak however, the two terms are
interchangeable.
Student Notebook
Domain Name System
DNS Packet The Internet

Server Filtering
DMZ Router
Packet The DNS server in the DMZ

Filtering
resolves queries on the DMZ
Router
and on the Internet.
The internal DNS resolves
queries for the Company
Network, and forwards all
other queries to the DNS
Company Network server on the DMZ.
DNS
Server Filtering based on IP address
and port number (DNS=53)
Figure 1-17. Domain Name System LX243.0
Notes:
For various reasons, Intranet clients may need to resolve hostnames on the Internet, and
Internet clients may need to resolve hostnames on the DMZ. Both things are usually
configured by adding two DNS servers:
The first DNS server is placed on the Intranet. It resolves all queries for the Intranet, and
forwards all other queries to the DNS server on the DMZ.
The second DNS server is placed on the DMZ. It resolves all queries for the DMZ
(regardless of their origin, Intranet or Internet) and forwards all other queries to the root
DNS servers of the Internet. It never forwards queries to the Intranet DNS servers however,
effectively shielding the internal network from Internet requests.
Again, the packet filters need to be configured to allow certain types of incoming requests.
This is done too using the IP address of the DNS server and the well-known port number
for DNS (53).

V3.0
Student Notebook
Uempty
The Company Webservers
Company
Webserver
Packet The Internet

Filtering
DMZ Router
Packet
Filtering An internal client can
Router
access both the Intranet
server and the Internet
server. An external client
Client
can only access the
Internet Server.
Intranet
Company Network Filtering based on IP address
Server and port number (HTTP=80)
Figure 1-18. The Company Webservers LX243.0
Notes:
The company may also decide to offer information to the Internet and/or the Intranet, for
instance using a web server.
The Internet web server is usually placed on the DMZ, where it can be made accessible for
both Intranet and Internet users. The Intranet web server is then placed inside the Intranet,
where only Intranet clients can connect.
Again, the packet filtering routers need to be configured to allow incoming requests, this
time for port 80.
Student Notebook
Virtual Private Networking

With VPN, traffic between one network
and another is sent encrypted over
the Internet, creating one Virtual Network
Packet The Internet
Filtering
DMZ Router
Packet Tunneling
Filtering Device
Router Firewall
with
Client
Tunneling
Company Network Customer Network

Intranet
Server
Figure 1-19. Virtual Private Networking LX243.0
Notes:
Virtual Private Networking is a fairly new application on a firewall. It is used to communicate
securely and transparently with another location of the same company, or with another
company, using the Internet as communications medium.
Such communication was usually done using leased lines, which are very expensive. With
the speed of the Internet increasing and now that nearly every company has Internet
access, replacing those leased lines with Internet connections saves a lot of money. There
is one big drawback however, and that is that you might want to keep your data
confidential.
This confidentiality is guaranteed by using strong encryption techniques. When a client on
a customer network wants to retrieve some data from your Intranet server for instance, he
sends the request to the firewall which incorporates a tunneling device. This device
encrypts the requests and sends it to the tunneling device on the other firewall. The request
is then decrypted and passed on to the server. Data on the way back to the client is
encrypted as well.
The encryption/decryption is completely transparent to the client and the server

V3.0
Student Notebook
Uempty
The Complete Picture
Firewall
NAT Company Webserver
Socks Webserver
Proxy
DNS Packet The Internet

Server Filtering
DMZ Router
Mail
Gateway Packet Tunneling
Filtering Device
Router Firewall
with
Client
Tunneling
Mail
Server Client
Intranet Company Network Customer Network

DNS
Server Server
Figure 1-20. The Complete Picture LX243.0
Notes:
Here is the complete picture. What you can see is that the firewall is not a single device per
se. It contains a number of components. That does not mean that a firewall cannot be a
single device: it is perfectly possible to combine all these components into a single host. In
fact, that's what we'll be doing during this course.
Student Notebook
What a Firewall Does Not Protect Against

Misuse of allowed connections
Malicious users (employees, contractors) behind the
firewall
Data in transit on the internet
Connections that bypass the firewall
Modem connections
Software/Data brought in/out on physical media
Connections to systems outside the firewall
Company web server
Physical theft, break-in attempts, bribery, fire, ...
Figure 1-21. What a Firewall Does Not Protect Against LX243.0
Notes:
A firewall is not the be-all and end-all. There are certain things it cannot protect against.
• A firewall cannot protect against misuse of allowed connections. For instance, suppose
a firewall allows outgoing HTTP connections. This can then be used to transfer IP
packets to and from an outside system. Since the firewall usually has no way to verify
the contents of the HTTP connection, this goes undetected. Fortunately, misuse of
allowed connections is usually only possible with help on the inside.
• A firewall only protects you from bad things happening on the Internet. Any malicious
user on the Intranet will not be stopped by the firewall, since he can access the internal
systems directly.
• Data in transit on the Internet can also not be protected. Anyone on the Internet can
sniff the data and possibly even alter the data.
• All connections that bypass the firewall obviously are not under the firewall's control.
This includes modem connections to/from systems on the internal network, but also

V3.0
Student Notebook
Uempty includes software and/or data which is brought into and out of the company on physical
media (floppies, tape, CD-ROMs).
• The same is true for all connections to systems outside the firewall.
• Lastly, a firewall cannot protect against physical hazards such as theft, break-in
attempts, bribery and so forth.
Student Notebook
Network Security Techniques Usage
Technique Intranet Server Internet Server Firewall

Physical security yes yes yes
Packet Filtering maybe yes yes
Encrypted maybe yes yes
communications
NAT N/A N/A yes
Socks N/A N/A yes
Proxies N/A N/A yes
Individual service maybe yes yes if fw runs
security services
Split DNS N/A N/A yes
Virus scanning maybe yes yes
VPN solutions N/A N/A maybe
Hackers' tools maybe yes yes
IDS tools maybe yes yes
Figure 1-22. Network Security Techniques Usage LX243.0
Notes:
In this unit we are going to present a large number of security techniques. In your own
environment, you may or may not want to apply each and every individual technique. This
depends of course on your security policy, but also on the system concerned. As an
example, an intranet server typically needs less protection than an exposed internet
webserver or firewall. And even then: a webserver of a highly controversial company, or
with highly controversial content will probably draw more attacks than your own private
webserver displaying some vacation photos - unless of course these photos are offensive
to someone.
If you look at the list of topics, you will see that almost every technique we’re going to
discuss is applicable to a firewall. That’s why this course is centered around building a
firewall. Remember though, that most techniques can also be used to secure other network
servers.
There is one generic technique which we don’t cover in this course: individual service
security. With this technique we mean the network security services that are built into a
particular network service. As an example, Apache allows you to limit client access to

V3.0
Student Notebook
Uempty content based on IP address, and based on a username/password combination. This

needs to be configured in the httpd.conf file. Samba has the same features, but another
implementation: in this case, the smb.conf file is used. And yet other services use
/etc/hosts.allow and /etc/hosts.deny. Because of this, this technique cannot be covered in a
generic way.
Student Notebook
Checkpoint Questions
1. What is the difference between a Hacker and a
Cracker?
2. Does it really matter?
3. What is a firewall?
4. What components can a firewall have?
5. Against what does a firewall offer no protection?
Figure 1-23. Checkpoint LX243.0
Notes:
Write down your answers here:
1.
2.
3.
4.
5.

V3.0
Student Notebook
Uempty
Summary
Various people on the internet may try to access your
systems
A common way of protecting is a firewall
A firewall consists of a number of components: DMZ,
filtering routers, NAT, Socks, Proxies, VPN.
A firewall cannot protect you from everything
Figure 1-24. Summary LX243.0
Notes:
Student Notebook

V3.0
Student Notebook
Uempty Unit 2. Installing and Securing Linux

This unit discusses the installation of Linux in such a manner that the
installed system is secure enough and has enough features so that it
can be configured as a firewall.

• Install Linux
• Apply Patches
• Harden Linux

Accountability:
• Machine exercises
© Copyright IBM Corp. 2000, 2003 Unit 2. Installing and Securing Linux 2-1
Student Notebook

Notes:

V3.0
Student Notebook
Uempty

!
"""
# $
%
&
Figure 2-2. Installing Linux LX243.0
Notes:
Installing Linux on a firewall is done just like any other Linux server, through a CD-ROM or
network install.
It is a very good idea to make separate partitions for each of the different filesystems on
your firewall. This will help contain the effects of a potential break-in attempt.
Obviously when installing a firewall, you will want to install as few services as possible. The
reason is simple: for a firewall administrator, paranoia is a way of life. Every service you
install might contain a security hole. The fewer programs that are installed, the smaller the
chance that things go wrong.
The last consideration is to install a good root password. Obviously this is true for every
machine in your organization, and we all know that most system administrators relax this
guideline a bit. Are your root passwords on all your machines the same or do they look
alike? The firewall is the excellent place to break this habit. This machine has to be just
about the securest in your organization. A very good root password is just the basis of your
security.
Student Notebook

'

!
!
'

* +'6779

;"##$"#%&**+.0

;"#$#$"#
+3!4
Figure 2-3. Apply Patches LX243.0
Notes:
After the installation of Linux, go to the website of the manufacturer of your distribution and
download and install all patches that have been released since your distribution version
was released. Be sure to only download patches that have been released by the
distribution manufacturer itself, and not any patches that may come from other sources, as
they may contain Trojan horses.
Patches are generally distributed in the form of RPMs. To install them, use the -F option of
the rpm command. The only exception to this is the Linux kernel itself: this kernel should
be installed with the -i option. After installing a new kernel, reboot, test your own kernel and
remove the old kernel with the -e option.
If you are downloading packages from the Internet, be it from the site of the manufacturer
of the distribution, a mirror site or something else, it is a good idea to verify the MD5
checksum and GPG signature of an RPM package. This is a two-step process:
• Mount the original CD-ROM from the manufacturer and add the GPG public key on that
CD-ROM to your keyring. This is for instance done on a Red Hat system with the

V3.0
Student Notebook
Uempty command rpm --import /mnt/cdrom/RPM-GPG-KEY. On a SuSE system you’ll need

to run gpg --import /media/cdrom/pubring.gpg
• Verify the checksum and signature with the command rpm -K <package>
Student Notebook
+ %"
+ 9
'

< >
< >

'

@ 9

J

$&9
9

9
+ 9
#

Figure 2-4. Kernel recompile LX243.0
Notes:
After the installation of Linux, you might want or need to recompile the kernel. There can be
various reasons for this:
• You might want to disable support for hardware that is not available on your system.
This not only wastes hard disk space and memory, but might even be used in a DoS or
intrusion attack if a bug is found in that specific piece of code.
• Not all distributions ship with a kernel that is optimized for your processor. Recompiling
your kernel optimized for your processor may give you a significant performance
increase.
• An obscure question somewhere in the kernel configuration questions is "Optimize as
router not host?". The default answer is no, but setting this to yes allows IP packets to
take another route through the kernel code which improves performance for packets
that need to be routed, but decreases performance for packets that have this host as
destination.

V3.0
Student Notebook
Uempty If you are building a network address translating firewall, this is something you might
want to play with.
• If you recompile your kernel you might want to keep it so small that you don't need
loadable modules at all, and you can disable module support. This improves
performance somewhat, but the biggest advantage is that a hacker will not be able to
load a custom module which might contain some malicious code.
• You also might want to recompile the kernel to add some security features that have not
(yet) made it into the mainstream kernel. There exist for instance some patches that
allow the kernel to detect port scans. This code is not integrated in the mainstream
kernel, but might be useful on a firewall.
• And to follow up on the previous bullet, some code just can't be added to the
mainstream kernel at all. An example of this is the FreeS/WAN code which will be
covered in unit 10. This code contains strong encryption which may not be exported
outside the US. (Although it is developed outside the US!)
• Another reason might be that security problems have been found in the current kernel,
but a new kernel has not (yet) been released. You might then need to apply the kernel
patch yourself and recompile the kernel.
• And the last reason might be that you need support for special hardware on your
firewall (for instance for a WAN adapter for which support is not compiled into the
default kernel).
Student Notebook
5$
Q<#
Q
X

'

' YY'

"

#[\+<X\
] 9

Figure 2-5. Hardening Linux LX243.0
Notes:
By hardening Linux we mean changing various settings so that the system is as secure as
it can get. This involves a number of steps:
• Hardening the BIOS
• Hardening the Boot Loader
• Add/change/delete user accounts
• Disabling unneeded services
• Disabling Ctrl-Alt-Delete
• Changing /etc/issue and /etc/issue.net
• Changing /etc/motd
• Setting the $TMOUT variable
• Recompile the kernel
• Harden the filesystem

V3.0
Student Notebook
Uempty
6
78" $"
9

^Q<#

' +
#Q<#
_^Q<# 9
Q +<#
Q
Q<#9
_^% """
Figure 2-6. BIOS Considerations LX243.0
Notes:
Hardening the BIOS basically means changing the BIOS settings so that a hacker who
happens to be on-site cannot easily break into your system, or disable it. The BIOS
supports this in a number of ways:
• First, every BIOS allows you to specify the order of boot devices. Make sure you only
boot from the hard disk, as booting from floppy or CD-ROM first might give a hacker the
chance to boot the system into rescue mode or something.
• Some BIOSes support virus protection. Virus protection basically means that you get a
warning when the Master Boot Record has changed. As this is something that normally
does not happen, except when installing Linux or upgrading the kernel, it is a good thing
to enable.
• Disabling APM is a good idea too. As firewalls are servers which are required to be
operational 24 hours each day, APM is not a useful feature here, except maybe for
monitor blanking.
• The last thing you might want to do is set a BIOS password, at your option for the BIOS
administrator only or for the whole system boot. Note however that these BIOS
passwords can be cracked with BIOS crack programs or by shorting the CMOS battery.
Student Notebook
6"""$ 9"$

<7]XQ

]

_Y
$""
&`

<^{ {{ { "
7]XQ^{ {

"
Y

!

"!#$#%&'($#)(*+,-)./012

3

$

#$#%&'($#)(*+,-)./012

Figure 2-7. Boot Loader Password LX243.0
Notes:
The Boot Loader is the next step in the boot process and has to be duly secured too.
Fortunately, the two most common boot loaders for Linux allow this.
Both LILO and GRUB allow you to specify a password in their configuration file. This
password is not required when a regular boot is performed, but is required before the user
is allowed to pass any options to the kernel, such as those required to boot into single user
mode.
With LILO, this is done by specifying a boot password and the "restricted" keyword in
/etc/lilo.conf and then running the lilo command again.
Since the password is listed in plain text in the /etc/lilo.conf file, you should not use your
root password here, and you should set the permissions on this file to 600.
With GRUB, you need to specify the password in /boot/grub/menu.lst. GRUB allows you to
encrypt your passwords with MD5 before storing them in /boot/grub/menu.lst. This can be
achieved with the md5crypt command in grub. Nevertheless, it is wise to set the
permissions on the /boot/grub/menu.lst file to 600.

V3.0
Student Notebook
Uempty
: "8" $"
!

|
X

$ """&
'

\
_

X

{{
Figure 2-8. User Account Considerations LX243.0
Notes:
Every user account is a potential security problem, because every user account that is in
use requires a password which might just be guessed. It is therefore a good idea to have
as few user accounts on your firewall as possible. Some people even go through the
trouble of deleting all the "default" user accounts, like bin, adm and so forth off their system,
leaving only the root user account. This increases security somewhat, but not much since
these accounts are disabled by default in Linux anyway.
It is important to look at regular user accounts though. You will want to have as few as
possible on your system, and you will want to disable or delete them as soon as they are
not in use anymore. You can even consider disabling user accounts temporarily while that
user is on holiday.
But do you need user accounts on your firewall at all? The only users on your firewall are
system administrators who will probably su to root as soon as they are logged in anyway.
The Linux world is undecided about this question. Some people argue that you might as
well let these administrators log in as root directly. This saves you from creating a user
account for each administrator, which is a potential security problem if one of the
Student Notebook
administrators is lax in maintaining his password. Other people claim that setting up
accounts for administrators and let them su to root is a good thing, since it requires that a
hacker guesses two passwords instead of one. Another argument is that this leaves a log
trace of who did the su in the logfiles. But the root user can easily alter the logfile, so that is
not really. a valid argument1.
Another trick you might consider is changing the root account to a different name, or setting
up multiple root accounts, one for each administrator. This can be done because the root
user receives his privileges not because his name is "root", but because his userid is zero.
Any user account with userid zero has root privileges, whether that account is called "root"
or not.
This leads to interesting possibilities. You can for instance create an account for each
administrator, but all with userid zero. This way every administrator can log in with his own
name and password, and have root privileges immediately. The root account itself is not
needed anymore, but this account can for instance be set up as a regular user account,
with all the bells and whistles attached so that a warning is sent out immediately if someone
gains access to that account.
1
Unless, of course, if you log through syslog and send all entries to a remote, more secure system.

V3.0
Student Notebook
Uempty
; 7
#
$
' ^
X

" "
"}"

\ ^ ! !"<"
#
$^
' ##$"<##$$#
!"<
$
\
^
$ &
$ &
Figure 2-9. Disable Services LX243.0
Notes:
A regular distribution starts a large number of services by default after installation. Most of
these services are not needed on a firewall and therefore need to be disabled.
Services can be started in one of the following two ways:
• Services that are not used often (certainly not more than once every few seconds) are
usually started through the xinetd super daemon. To disable these services, edit the
/etc/xinetd.conf file and disable all the unneeded services listed here. Your distribution
might also be configured to include all files in the /etc/xinetd.d directory in the xinetd
configuration. In this case, you need to go into each individual file in /etc/xinetd.d and
disable each service in it. To make this easier, the chkconfig tools is altered to allow
you to enable/disable services that run from xinetd as well. When all xinetd services
have been disabled, restart xinetd.
• Services that may be used several times per second or services that need to have their
own daemon running at all times are usually started on the port directly. These services
may be disabled by removing the startup link in /etc/rc.d/rc3.d or /etc/rc.d/rc5.d. This
can be done again using chkconfig.
Student Notebook
To verify which services are running, you can use the commands ps -aux, which shows the
list of running processes, and netstat -a, which shows the open ports.
If you see an open port but are not able to figure out which service opened that port, you
can use the fuser -n tcp <port> command to determine which process ID has that port in
use.

V3.0
Student Notebook
Uempty
5$
+
^
^'

^'
9
^'
^+
Y
Y
^

4

5
! ^
$
% 5
5
5
%%
% $$
% 5
5
%%
$$
% 5
5
%%
6% 5
5
%%
7
% 5
5
%%
8% 5
5
5
%%
$

8

5
5
5
5

5
5
5
5

Figure 2-10. Filesystem Hardening LX243.0
Notes:
There are some protective measures you might want to make to the filesystem. Each
filesystem, when mounted, can support a number of options which might make it a little
more difficult for a hacker to exploit a system. These include the following:
• noexec: You cannot execute commands on this filesystem, even if they have the
execute (x) bit set.
• nosuid: SetUID and SetGID bits do not take effect when executing a program.
• nodev: Special files that represent devices do not take effect.
• ro: The filesystem is read-only.
These options can be specified in /etc/fstab.
Student Notebook
; 8 ;

YY'

##
! 5:=
' ^

Figure 2-11. Disable Ctrl-Alt-Del LX243.0
Notes:
Depending on your local situation and the people who have access to the console, you
might want to alter the behavior of Ctrl-Alt-Del, or disable it completely. This is done by
commenting out the corresponding entry in /etc/inittab and a subsequent restart of init.
Note however that there may be situations in which another system administrator might
need to shutdown the system. If Ctrl-Alt-Del is disabled completely, he or she has no
choice but to just turn the power off. So disabling Ctrl-Alt-Del certainly has its drawbacks.

V3.0
Student Notebook
Uempty
## >##
] 9

_^#

"|

9

1
:

15

Figure 2-12. /etc/issue, /etc/issue.net LX243.0
Notes:
Hackers are a strange bunch of people. Their reasoning sometimes follows the logic: "If it is
possible, it is allowed." This is the equivalent of an intruder claiming it was legal to enter
your house because you left your bathroom window open.
A clear usage policy in /etc/issue and /etc/issue.net (which is shown before a person logs
in) prevents this.
A second reason for changing this file is that most distributions set up this file by default so
that it reveals the operating system type and version. This information might be used by
hackers to quickly try the known vulnerabilities of that particular operating system version.
Typically, in these files you will want to reveal as little information as possible.
Note that some distributions overwrite /etc/issue and /etc/issue.net at boot time. In this
case, figure out where this is done (typically in /etc/rc.local) and disable this.
Student Notebook
##"$

;;;;;;;;;;;;;;;;;;;;;;;;;;<=9:+";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;9

1
:
;
;

15
;
;

;
;;
;)

> ;
;

=;
;5
<=9;
;;
;-

;
;

?=@=AA:00",:>9"?B
;
;

;
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Figure 2-13. /etc/motd LX243.0
Notes:
/etc/motd is the file which is displayed after a user logged in. It can be used once again to
warn unauthorized users not to use this system.

V3.0
Student Notebook
Uempty
@B&:B7 G
#
$ &

~Y
^
~ Y

[<+!" ^
"B&:BJR[\\
Figure 2-14. $TMOUT Shell Variable LX243.0
Notes:
Have you ever logged into a system as root and then left without logging out? I know I
have. And by the time you realize it, it is usually too late to do something about it.
The bash-shell has a shell variable, $TMOUT, built in, which allows you to specify the
maximum idle time (measured in seconds) a session may have. After this time, the session
is ended automatically.
To set this variable, you can either add it to /etc/profile or to $HOME/.bash_profile,
whatever you prefer.
Student Notebook
8!"] "

" _

"
" @
9
J
Notes:
1.
2.

V3.0
Student Notebook
Uempty
7

Notes:
Student Notebook

V3.0
Student Notebook
Uempty Unit 3. The TCP/IP Protocol Suite

This unit discusses the TCP/IP protocol suite and the implications of
this suite for a firewall.

• Discuss the IP protocols and IP addressing
• Describe the content of IP, TCP, UDP and ICMP packets
• Trace TCP/IP traffic with tcpdump
• Change TCP/IP kernel options

Accountability:
© Copyright IBM Corp. 2000, 2003 Unit 3. The TCP/IP Protocol Suite 3-1
Student Notebook
Objectives
Discuss the IP protocols and IP addressing
Describe content of IP, TCP, UPD and ICMP packets
Trace TCP/IP traffic with tcpdump
Change TCP/IP kernel options
Notes:

V3.0
Student Notebook
Uempty
TCP/IP Layering
TCP/IP Applications
TCP UDP
ICMP
IP
Network Interface
Figure 3-2. TCP/IP Layering LX243.0
Notes:
The TCP/IP protocol suite consists of a number of protocols which build upon each other to
offer the user various different services. The diagram above shows the TCP/IP layering of
the protocols. We will discuss these one by one, starting with the IP protocol.
Student Notebook
IP Protocol
Internet Protocol
Defined in RFC 791, 950, 919, 922 and 1349
Main protocol to forward data to destination host
Uses "datagrams" (packets) to send data
Source and destination are identified with an IP address
Connectionless, unreliable service
Hop-by-hop forwarding in "routers"
Figure 3-3. IP Protocol LX243.0
Notes:
The IP (Internet Protocol) is the basis of the TCP/IP protocol suite. Its main task is to
forward data from one host to another, and it does this task by encapsulating the data into a
"datagram" (packet), prepended with a header. In this header the details about the data is
stored, for instance the source and destination.
IP provides so-called unreliable, connectionless service. This means that the IP layer does
its best to deliver the data to the destination host, but offers no guarantees. Data packets
may be lost in transit, they may be duplicated in transit or the order of packets may be
changed. It is up to the higher layer protocols to add reliability by testing for packets that
were lost, and resending them. Also, IP layers are not aware of "connections". They treat
every IP packet as an individual packet and do not keep state information about
connections. Again, this is up to the higher layers to provide.

V3.0
Student Notebook
Uempty
IP Addressing
Every interface needs a unique IP address
IP addresses are 32 bit
Usually written in "dot-quad" notation: 9.132.123.133
binary: 00001001 10000100 01111011 10000101

8+1 128+4 64+32+16+8+2+1 128+4+1
dot-quad: 9 . 132 . 123 . 133
Figure 3-4. IP Addressing LX243.0
Notes:
IP addresses are 32 bit, unsigned integers and are unique for each interface of every host
on the Internet. They are assigned by the network administrator.
To represent this 32 bit value to a human reader, the dot-quad notation is used: the address
is represented by four decimal values separated with a dot. Each decimal value represents
eight bits of the IP address.
Student Notebook
IP Address Assignment
IP addresses assigned by IANA
Internet Addressing and Naming Agency
http://www.iana.net
5 "classes":
A: 8 bits assigned, 24 free
B: 16 bits assigned, 16 free
C: 24 bits assigned, 8 free
D: multicast - assigned individually by IANA
E: experimental - not used any more
Reserved classes for private networks:
A: 10.0.0.0
B: 172.16.0.0 through 172.31.0.0
C: 192.168.0.0 through 192.168.255.0
Other special:
Class A 127.0.0.0 used for loopback interface
Figure 3-5. IP Address Assignment LX243.0
Notes:
Because IP addresses need to be unique across the Internet, they are assigned by one
organization called the Internet Addressing and Naming Agency (IANA). They don't assign
individual addresses but assign blocks of addresses. These blocks come in five classes, of
which the first three are of the most interest to us:
• A class A block of addresses means that you receive a block of addresses which all
have the same first eight bits. The other 24 bits are available to assign yourself. This
means that you effectively received 224 or 16 million addresses.
• A class B block of addresses means that you receive a block of addresses which all
have the same first 16 bits. The other 16 bits are available to assign yourself. This
means that you effectively received 216 or 64 thousand addresses.
• A class C block of addresses means that you receive a block of addresses which all
have the same first 24 bits. The other eight bits are available to assign yourself. This
means that you effectively received 28 or 256 addresses.

V3.0
Student Notebook
Uempty With the tremendous growth of the Internet, this scheme proved to be too restrictive.
Addresses nowadays are usually assigned using Classless InterDomain Routing (CIDR)
addresses, which allows you to specify any number of addresses, as long as it is a power
of 2.
There are two other classes which we will not see often, but we need to know about them
anyway:
• The class D address range is used for multicast addresses. These addresses are
assigned on an individual basis by the IANA.
• The class E address range is used for experiments. These addresses are no longer in
use.
The IANA reserved several ranges of addresses for special purposes. These are:
• The class A address range 10.0.0.0, the class B address ranges 172.16.0.0 through
172.31.0.0 and the class C address ranges 192.168.0.0 through 192.168.255.0. These
addresses will never be assigned to Internet hosts and can therefore be used on private
networks which are not (directly) connected to the Internet.
• The class A address range 127.0.0.0. This class is reserved for the loopback device(s).
Student Notebook
IANA Address Assignment

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A |0 IANA | SELF | SELF | SELF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B |1 0 IANA | IANA | SELF | SELF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C |1 1 0 IANA | IANA | IANA | SELF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D |1 1 1 0 IANA | IANA | IANA | IANA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E |1 1 1 1 NOT | IN | USE | ANYMORE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class A: 2^7=128 networks of 2^24=16M addresses

Class B: 2^14=16K networks of 2^16=64K addresses
Class C: 2^21=2M networks of 2^8=256 addresses
Class D: 2^28=256M multicast addresses
Figure 3-6. IANA Address Assignment LX243.0
Notes:
To make sure that the class A, B and C address ranges do not overlap each other, the
IANA devised a simple strategy:
• Class A addresses always start with the first bit set to zero.
• Class B addresses always start with the first two bits set to 10.
• Class C addresses always start with the first three bits set to 110.
• Class D addresses always start with the first four bits set to 1110.
• Class E addresses always start with the first four bits set to 1111.

V3.0
Student Notebook
Uempty
IP Address Usage
Example: Use private address 10.0.0.0 to create 64K
networks of 256 hosts each
First 8 bits are fixed: 00001010 (number 10)
Next 16 bits identify the network (2^16=64K)
Last 8 bits identify the host in the network (2^8=256)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1 0| Network Identifier | Host ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Use "subnetmask" 255.255.255.0 to identify what

part is network ID and what part is host ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
255 . 255 . 255 . 0
Figure 3-7. IP Address Usage LX243.0
Notes:
After you have obtained a block of IP addresses (or decided to use one of the reserved IP
address ranges), you need to decide how many networks you are going to create and how
many hosts you are going to have at most in each network. These two numbers then
decide how to configure the netmask.
This netmask is a 32 bit number which starts with a certain number of ones followed by a
number of zeros, and identifies which part of the IP address is the network identifier and
which part is the host identifier. The netmask used to break down the IP address into
network and host portions on byte boundaries only (so, after 8, 16 or 24 bits). This proved
to be too restrictive however, and therefore you will see netmasks breaking down the IP
address after the 23rd bit for instance (255.255.254.0). This is called Classless
InterDomain Routing (CIDR).
The network identifier is the same for all hosts in the same network, and is unique for this
network across the Internet. The host identifier is unique for each host on this particular
network.
Student Notebook
When talking about networks, it is usually necessary to supply both the network identifier
and the netmask. A common notation for this is "10.0.0.0/255.255.255.0", or, more modern,
"10.0.0.0/24". Nearly all implementations support the first notation, and quite a few (but not
all) implementations also support the second one.

V3.0
Student Notebook
Uempty
IP Packet Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VERS | HLEN | Service type | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | FLG | Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to live | Protocol | Header checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional: IP Options |
. +-+-+-+-+-+-+-+-+-+-+-+
. | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP data |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3-8. IP Packet Format LX243.0
Notes:
The visual shows the IP packet format. Each IP packet consists of a header and the data
itself. The header then consists of a number of fields:
• The VERS (Version) field identifies the IP protocol version. The current version is 4.
• The HLEN (Header Length) field identifies the length of the IP header. This field is
needed because the header length is variable. The header length is in words of 32 bits.
• The Service Type field identifies the type of service requested for this IP datagram. It is
used as follows:
- The first three bits identify the Precedence, with 000 being the lowest (Routine
traffic) and 111 being the highest (Network control).
- The next four bits identify the Type of Service. At most one of these four bits can be
set, with the first bit meaning "minimize delay", the second "maximize throughput",
the third "maximum reliability" and the fourth "minimize monetary cost". All zeros
means normal service.
- The last bit is reserved for future use.
Student Notebook
• The total length field identifies the total length of the IP datagram (header+data) in
bytes. If the total length exceeds 64 Kb, this field is not used and an option field is
inserted with a 32 bit value specifying the length in bytes for a maximum of 4 Gb.
• The Identification, Flags and Fragment offset fields ensure that packets that are too
large for the infrastructure can be fragmented and later reassembled again.
• The TTL (Time To Live) field identifies the number of seconds or number of hops
(whichever is shorter) that this IP packet is allowed to live. Every router will decrease
this field by one. Once the counter reaches zero, the packet is discarded.
• The Protocol field identifies the upper layer protocol for which the data is meant.
Common protocol identifiers are ICMP (1), TCP (6) and UDP (17). Later in this course
we will also see ESP (50) and AH (51).
• The header checksum is used to verify that the IP header itself is still intact. If the listed
checksum does not match the calculated checksum, the packet is discarded.
• The source and destination IP address are the 32 bit addresses of the source and
destination host.
• There are various options fields that can be inserted after the core IP header. These
include options for routing, big packets, security and time stamping.

V3.0
Student Notebook
Uempty
Important IP Header Fields
Total length: Might be used to force fragmentation or
buffer overflows
ID, FLG and Fragment Offset: Might be used in DoS
attacks since fragments need to be buffered
Source IP Address: might be forged ("spoofed")
to prevent tracing back an attack
to masquerade as a trusted host
Destination IP Address: might be an address behind the
firewall to discover firewall capabilities
IP Options: Source Routing might be used to bypass
routing algorithms
Figure 3-9. Important IP Header Fields LX243.0
Notes:
A hacker usually has tools available to create arbitrary IP. packets.1 With these tools he
can set any of the IP header fields to anything he wishes. Obviously setting the header
checksum to a strange value is not very useful, but setting other fields is:
• The total length field, in combination with the correct amount of data, can force
fragmentation in routers or hosts. This can be used to overflow buffers in poorly written
TCP/IP stacks.
• The headers that govern fragmentation can be used to send packets that appear to be
fragments of a larger IP packet to a host. Since these fragments need to be buffered
before reassembly, buffer overflows may result.
• The source IP address can be forget ("spoofed") so an attack cannot be traced back to
the origin. This has a disadvantage too: all packets that are sent back to the hacker do
not arrive there. He has to either intercept these packets in another way, or has to
guess the contents of these packets (which is not all that hard to do, in certain cases).
Another misuse of this field is to insert the IP address of a trusted host here. Certain
1
See http://www.packetfactory.com/libnet for an example of such tools.
Student Notebook
services can be configured only to accept connections from a given source. By

masquerading as this source a hacker can actually circumvent these checks.
• The destination host is usually not spoofed, since packets will then not arrive at the
target. However, it may be useful in detecting what's behind the firewall. (This technique
is called firewalking).
• The option fields may be used too by a hacker. A hacker might for instance use the
source routing options to bypass the routing tables on various routers.

V3.0
Student Notebook
Uempty
The ICMP Protocol
Internet Control Message Protocol
Defined in RFC 792 and 950
Used to report network errors back to sender
except errors from ICMP itself
Used to discover information about another host
Uses IP for packet forwarding
Figure 3-10. The ICMP Protocol LX243.0
Notes:
The ICMP protocol is mostly used to report back errors in the IP protocol, for instance
packets destined to nonexistent hosts. It is also used to discover information about a
certain host. It is built on top of IP, which means that it uses IP as its transport mechanism.
Student Notebook
ICMP Packet Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | CODE | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICMP Data (depending on type) |
| |
. .
. +-+-+-+-+-+-+-+-+-+-+-+
. | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3-11. ICMP Packet Format LX243.0
Notes:
The ICMP packet is fairly simple, and largely depending on the type of ICMP packet we are
talking about:
• The type field is used to denote the ICMP packet type.
• The code field is used to report the type of error. It's value is dependent on the packet
type.
• The checksum is used to verify that the ICMP packet (header + data) is correct.
Some of the more well-known types are:
0 Echo reply: Answer to an echo request (type 8)
3 Destination unreachable: A router received a packet with an unknown
Destination IP address, or a host received a packet with an unknown
Protocol.
4 Source Quench: Sent by routers to indicate congestion.
5 Redirect: Sent by routers to indicate errors in routing tables.

V3.0
Student Notebook
Uempty 8 Echo request: Used to verify if a host is alive.

11 Time Exceeded: Used to indicate that a packet was discarded because the
TTL expired.
12 Parameter problem: Used to indicate that for instance the checksum on the
packet was wrong.
Student Notebook
Important ICMP Message Types

Echo request (8)/Echo reply (0): Test whether a host is
active
Used in smurf attacks with a spoofed source address to
flood a target
Destination unreachable (3):
From a router: Don't know the route to the target
Can be used to obtain information about the firewall
From a host: Protocol or port not enabled
Used in port scans to verify that a port is not active
Source Quench (4): Packets arriving too fast - slow down
Can be used for DoS attacks
Redirect (5): Use another router to route these packets
Can be used to redirect traffic over another route so
that it can be sniffed
Figure 3-12. Important ICMP Message Types LX243.0
Notes:
Some of the more common DoS attacks use ICMP in various capacities.
A smurf attack sends a ping (echo request) to a host or broadcast address, but lists a
broadcast address on the local network as source IP address. The echo reply will thus be
received by every host on the network, tying up CPU time and network bandwidth. If lots
and lots of pings are received this way, the complete network may come to a halt.
The destination unreachable ICMP packet is usually not sent by hackers, but is eagerly
awaited by hackers. It basically tells the hacker whether a given service is not running or
running behind a filter. This will influence his strategy. It can also be used to deduct firewall
rules.
The Source Quench can be used for DoS attacks by effectively choking all available
bandwidth to a certain destination.
The Redirect ICMP packet can be used to influence routing tables so that certain traffic
takes another route (maybe one where the hacker is sniffing) to the destination.

V3.0
Student Notebook
Uempty
UDP Protocol
User Datagram Protocol
Defined in RFC 768
Uses IP to send data
Uses port numbers (16 bits) to identify the service
Connectionless, unreliable service
Figure 3-13. UDP Protocol LX243.0
Notes:
The UDP protocol is a simple extension to the IP protocol, adding 16 bit port numbers to
identify the service where the data has to go to.
Student Notebook
UDP Packet Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP data |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3-14. UDP Packet Format LX243.0
Notes:
The UDP packet format is extremely simple. It contains the source port and destination
port, a length field and the UDP checksum, which verifies the integrity of the whole packet.

V3.0
Student Notebook
Uempty
Important UDP Header Fields
Source Port: Port where packet originates from
Can be spoofed to simulate a "secure" port (<1024)
Can be spoofed to simulate a well-known service
Destination Port: Port where packet goes to
Used to select the target service
UDP does not support "pacing": The sender can send as
many packets per second as his network connection
allows
Can be used in DDoS attacks to overload the network
Figure 3-15. Important UDP Header Fields LX243.0
Notes:
For a hacker, only the source port and destination port are interesting. With the destination
port he can select the service he wants to connect to. The source port is normally chosen
at random, but for some protocols a source port lower than 1024 is considered a "secure"
port which offers more privileges than a normal port.
The UDP protocol has no support for "pacing". Pacing is the process where the recipient of
the data indicates how much buffer space is available and thus how much data the sender
is allowed to send. The lack of this feature means that it is perfectly legal to send UDP
packets as fast as your network connection will allow. This is used a lot in DDoS attacks,
where not the server, but the network leading to the server is being overloaded.
Student Notebook
TCP Protocol
Transmission Control Protocol
Defined in RFC 793
Uses IP to send data
Uses source and destination ports to select service
Reliable, connection-oriented service
Figure 3-16. TCP Protocol LX243.0
Notes:
The TCP protocol is the protocol that is used most often. As with UDP, it uses IP as its
transport mechanism and a system of ports to select the service. But, unlike UDP, TCP
offers connection-oriented, reliable service.

V3.0
Student Notebook
Uempty
TCP Packet Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Data | |U|A|P|R|S|F| |
|Off- | Reserved |R|C|S|S|Y|I| Window |
| set | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options |
. +-+-+-+-+-+-+-+-+-+-+-+-+-+
. | Padding .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Data |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3-17. TCP Packet Format LX243.0
Notes:
The TCP header is far more ingenious than the UDP header. This is needed because of the
connection-oriented, reliable service.
The first two fields are the source and destination ports. They work just like UDP ports.
The next field is a sequence number. This is used to figure out the correct order of packets
if packets are lost and resent, or if one packet overtakes the other in transit.
The next field is an acknowledgement number. This is used to acknowledge packets that
have been received.
The Data offset field is used to indicate where the TCP data starts if TCP options are
present.
The Urgent flag and urgent pointer are used to transmit urgent data in the TCP message.
The ACK flag means that this packet contains an acknowledgement.
The PSH (push) flag is an invitation to the other side to send all its remaining data.
The RST (reset) flag is used to reset the TCP connection in case of unrecoverable errors.
Student Notebook
The SYN (synchronize) and FIN (finish) flags are used when starting or stopping a
connection.
The window value is the number of bytes the receiver is able to receive in this connection.
A sender should never exceed the window value because the receiver will not have any
space to store these packets.
The checksum works just like the UDP checksum over the TCP header and the TCP data.
Various options can be used in a TCP packet. These include selective acknowledgements,
a scale to apply to the window value and timestamps.

V3.0
Student Notebook
Uempty
TCP Connection Setup
First packet:
SYN bit set, Sequence number a
(a should be random)
Second packet:
Initiator ACK bit set, Acknowledgment number a+1 Server
SYN bit set, Sequence number b
(b should be random)
Third packet:
ACK bit set, Acknowledgment number b+1
May contain data
Figure 3-18. TCP Connection Setup LX243.0
Notes:
The diagram above shows the sequence of packets that are used to set up a connection.
The first packet from the initiator to the server only has the SYN bit set. This indicates that
this is a new connection. The initiator proposes a sequence number for this direction, here
denoted as a. This means that the initiator of the connection is going to pretend that it has
already sent byte a and the next byte it is going to send is a+1.
If the server supports the service that is requested, a packet is send back to the initiator.
This packet holds a SYN bit too, because a TCP connection is always a two-way
connection. The server here proposes b as the byte that was supposed to have been sent
already. This packet also contains the acknowledgement for the SYN packet, so the ACK
bit is set and the acknowledgement number is a+1, meaning that the first expected byte is
a+1.
The last packet in the opening sequence is the ACK packet from the initiator to the server,
acknowledging the sequence number proposed by the server.
Student Notebook
Important in this respect are two things:

• Based on the presence of the SYN flag and the ACK flag, even a stateless router can
determine in which direction a certain connection is set up. This makes it very easy to
allow outgoing connections, but deny incoming connections.
• The sequence numbers that are proposed are supposed to be completely random. This
actually makes it extremely hard for a hacker to successfully predict these numbers.

V3.0
Student Notebook
Uempty
Important TCP Header Fields
Source Port: Port where packet originates from
Can be spoofed to simulate a "secure" port (<1024)
Can be spoofed to simulate a well-known service
Destination Port: Port where packet goes to
Used to select the target service
Sequence number: Which packet this is in the stream
Needs to be in window range
URG: Urgent data
Certain applications are known to crash on receiving
this
SYN: Used in SYN attacks where a 1st SYN packet is
sent but the connection is not set up further
Fills up the connection table (DoS)
SYN cookies prevent this
Figure 3-19. Important TCP Header Fields LX243.0
Notes:
Several fields in the TCP header are interesting for hackers:
The source port and destination port work just like UDP: the destination port selects the
service. The source port can be spoofed below 1023 to simulate a well-known or secure
port.
The sequence number is actually the hackers curse. To be able to successfully hack into
existing connections or to predict packets in a series of TCP packets (which is needed for
instance when spoofing your IP source address), a hacker has to predict the sequence
numbers that are going to be used. By using truly random sequence numbers this becomes
virtually impossible. Linux and a number of other operating systems use truly random
sequence numbers, but a lot of operating systems do not. This makes them vulnerable to
spoofing attacks or replay attacks.
Certain applications do not handle urgent data well. This is the basis of the WinNuke
attack, for instance.
Student Notebook
The SYN flag is used in so-called SYN attacks, in which case a large number of SYN
packets are sent. This looks to the server as if a large number of connections are opened
and the server duly reserves resources for these connections. However the returning
packet is ignored by the hacker, effectively leaving the connections in a half-open state.
This ties up resources and may actually cause a poorly engineered server to crash. SYN
cookies (a Linux kernel option) prevents this in times of heavy load by not allocating
resources for a connection when the first of the three setup packets arrive. Instead,
important information is stored in the sequence number and cryptographically protected.
The resources are allocated only when the third packet actually returns with the correct
acknowledgement number. Since most SYN attacks come from spoofed IP addresses this
is actually a fairly simple but effective countermeasure.

V3.0
Student Notebook
Uempty
Tracing Network Traffic
Done with "sniffers"
tcpdump default sniffer in UNIX
Syntax: tcpdump [options] [expression]
Important options:
-i <interface>: Listen on <interface>
-p: Put interface in promiscuous mode
-l: Make output buffered (useful when viewing real-time)
-n: Don't translate IP addresses to hostnames
-s <number>: Show <number> bytes of packet
-x: Print whole packet in hexadecimal
Important expressions:
host <hostname or IP address>
ether <MAC address>
port <portnumber>
tcp
udp
Figure 3-20. Tracing Network Traffic LX243.0
Notes:
Tracing network traffic is traditionally done with the tcpdump tool, which is available in
nearly every Linux distribution. It monitors the interface and basically displays every packet
that matches the filter criteria to stdout. Stdout can then be saved to a file or viewed in real
time.
Tcpdump is the standard Unix tool for sniffing network traffic, and most forms of Unix
support it. It is however not very flexible and does not do much interpretation. Later in this
course we will look at Ethereal which is far more user friendly. You need to be able to work
with tcpdump though, because it is the only tool which is likely to be available on virtually
every system.
Student Notebook
Tcpdump Examples
[root@sys1 /root]# tcpdump -i eth0 -l -n
Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on eth0
16:21:08.341008 > 10.0.0.1 > 10.0.0.6: icmp: echo request
16:21:08.341554 < 10.0.0.6 > 10.0.0.1: icmp: echo reply
^C
2 packets received by filter
[root@sys1 /root]# tcpdump -i eth0 -l -n -x

Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on eth0
4500 0054 0172 0000 4001 6531 0a00 0001
0a00 0006 0800 ec0a e704 0000 14d8 f538
2adc 0500 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
16:22:12.384664 < 10.0.0.6 > 10.0.0.1: icmp: echo reply
4500 0054 0020 0000 ff01 a782 0a00 0006
0a00 0001 0000 f40a e704 0000 14d8 f538
2adc 0500 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
^C
2 packets received by filter
Figure 3-21. Tcpdump Examples LX243.0
Notes:
The visual shows a very simple example of two tcpdump traces.
The first trace is done without the -x option, and displays only the summary of every packet.
The second trace is done with the -x option, and therefore also displays the hexadecimal
dump of the contents of each packet.

V3.0
Student Notebook
Uempty
Understanding tcpdump Output
Hexadecimal Binary Meaning

---- ---- -------- -------- -------- -------- ---------------------------------
4500 0054 01000101 00000000 00000000 01010100 VERS=4, HLEN=5, Service=00,
Total length=0054(hex)
0172 0000 00000001 01110010 00000000 00000000 ID=0172, FLG=0, FO=0
4001 6531 01000000 00000001 01100101 00110001 TTL=40(hex), Protocol=01 (ICMP),
Checksum=6531
0a00 0001 00001010 00000000 00000000 00000001 Source IP addr=0a000001 (10.0.0.1)
0a00 0006 00001010 00000000 00000000 00000110 Dest IP addr=0a000006 (10.0.0.6)
0800 ec0a 00001000 00000000 11101100 00001010 ICMP type=08 (echo request), code=0,
Checksum=ec0a
e704 0000 11100111 00000100 00000000 00000000 ICMP echo request specific data
14d8 f538 00010100 10111000 11110101 00111000
2adc 0500 00101010 11011100 00000110 00000000
0809 0a0b 00001000 00001001 00001010 00001011 ICMP default pattern
0c0d 0e0f 00001100 00001101 00001110 00001111
1011 1213 00010000 00010001 00010010 00010011
1415 1617 00010100 00010101 00010110 00010111
... ...
Figure 3-22. Understanding tcpdump Output LX243.0
Notes:
Once you've got the hexadecimal output of the packet that you traced, you can spell it out
into every individual bit it's got. If you want or need to do this by hand, it is easiest to write
down the hexadecimal characters on a piece of grid paper, 8 hexadecimal characters on
each line. You then convert these to binary and figure out what each of the bits mean, using
the packet layouts from the lecture.
To spell packets out like this is a lot of tedious labor. Fortunately, programs exist that can do
it for you. We will meet some of these programs later on in the course. Note that tcpdump
doesn't do a very bad job either. The header line actually already tells you a lot about the
packet itself.
Student Notebook
Kernel Configuration Options

Default options set at compile time
Can be changed in virtual /proc filesystem
echo 1 > /proc/sys/net/ipv4/ip_forward
Should be configured before networking is started
Settings in /etc/sysctl.conf
net.ipv4.ip_forward = 1
Red Hat: Activated by /etc/rc.d/rc.sysinit
SuSE: Activated by /etc/init.d/boot.sysctl
Note: conflicts with /etc/init.d/boot.ipconfig
Extensive documentation in
/usr/src/linux/Documentation/proc.txt
Figure 3-23. Kernel Configuration Options LX243.0
Notes:
The kernel has certain default options built-in. These options can be changed however by
writing parameters to specific virtual files in the virtual /proc filesystem. This allows for
on-the-fly reconfiguration of the kernel. All writable options are in the /proc/sys hierarchy;
anything outside this hierarchy is read-only.
Most of the TCP/IP related options are under /proc/sys/net/ipv4. They should preferably be
configured before any interface is activated. This can be achieved by putting the options in
/etc/sysctl.conf, a file that is read by the sysctl commands, which in turn is called from
/etc/rc.d/rc.sysinit (Red Hat) or /etc/init.d/boot.sysctl (SuSE).
Note: SuSE by default does not enable boot.sysctl, but runs /etc/init.d/boot.ipconfig by
default. This file uses /etc/sysconfig/sysctl, which only contains a handful parameters, but
is far more readable than /etc/sysctl.conf. If you want to use /etc/sysctl.conf on SuSE, then
you need to disable boot.ipconfig (chkconfig boot.ipconfig off) and enable boot.sysctl
(chkconfig boot.sysctl on)

V3.0
Student Notebook
Uempty
Kernel Configuration Options (ICMP)
Ignore ICMP echo requests to broadcast address:
net.ipv4.icmp_echo_ignore_broadcasts = 1
Limits on sending ICMP packets (in # per 1/100s)

net.ipv4.icmp_ratelimit = 100
net.ipv4.icmp_ratemask = <mask>
icmp_ratemask determines to which ICMP packets icmp_ratelimit applies -
see /usr/src/linux/Documentation/networking/ip-sysctl.txt for details
Figure 3-24. Kernel Configuration Options (ICMP) LX243.0
Notes:
Various Linux kernel options exist for configuring ICMP. The first one is
icmp_echo_ignore_broadcasts, which, when set, forces the kernel to ignore ICMP Echo
Requests to a broadcast address. These requests are typically used in smurf attacks, and
can flood your network.
The other ICMP options limit the number of ICMP packets that may be sent per 1/100 of a
second. This can also prevent ICMP flooding attacks ("smurf attacks") in general.
Student Notebook
Kernel Configuration Options (IP)

Default TTL
net.ipv4.ip_default_ttl = 255
Local port range for TCP and UDP connections

net.ipv4.ip_local_port_range = 1024 32000
No Path MTU Discovery

net.ipv4.ip_no_pmtu_disc = 1
IP fragmentation memory thresholds and timeouts:

net.ipv4.ipfrag_high_thresh = 262144
net.ipv4.ipfrag_low_thresh = 196608
net.ipv4.ipfrag_time = 30
Figure 3-25. Kernel Configuration Options (IP) LX243.0
Notes:
Various options exist for managing IP too.
The ip_default_ttl sets the default TTL for IP packets.
The ip_local_port_range sets the local port range for dynamic ports used in outgoing
connections. If you have a large number of outgoing connections, set this range as wide as
possible.
The ip_no_pmtu_disc option disables PMTU discovery, a bandwidth-intensive trick to
discover the maximum allowed packet size. This is usually not interesting since the firewall
is connected to the Internet anyway and will in practice have a PMTU of 576 bytes.
Finally, there are some options which manage the behavior of IP defragmentation. The
ipfrag_high_thresh specifies the maximum amount of memory (in bytes) that may be used
to store fragments. If this limit is reached, no more fragments are accepted until the amount
of memory used hits ipfrag_low_thresh. Regardless of other factors, fragments are stored
in memory at most ipfrag_time seconds.

V3.0
Student Notebook
Uempty
Kernel Configuration Options (TCP)
Detect broken connections early:
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_time = 600
Protection against SYN attacks:

net.ipv4.tcp_syncookies = 1
Protect against unfinished connections:

net.ipv4.tcp_retries1 = 3
Protection against FIN attacks:

net.ipv4.tcp_fin_timeout = 30
Figure 3-26. Kernel Configuration Options (TCP) LX243.0
Notes:
Various kernel options exist for TCP as well:
tcp_keepalive_probes is the maximum number of TCP keepalive packets that may go
unanswered before the connection is dropped. tcp_keepalive_time is the timeout on these
keepalive packets.
tcp_syncookies protect against SYN attacks by sending a cryptographic challenge known
as SYN cookie in the TCP startup sequence packets.
tcp_retries1 is the maximum number of times a data packet is resent before the connection
is dropped.
tcp_fin_timeout is a time limit on the number of seconds a connection may be in the
finishing state. This prevents against FIN attacks, which work nearly the same as a SYN
attack.
Student Notebook
Kernel Configuration Options (Interface)

Interface specific options are in
/proc/sys/net/ipv4/conf/<interface-name>
Changes to the "default" interface apply to all
interfaces that will be configured later
Changes to the "all" interface apply to all interfaces
that are already configured
Do not accept/send ICMP redirects
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0
Do not accept source-routed packages
net.ipv4.conf.default.accept_source_route = 0
Log packets with source address with no known route
net.ipv4.conf.default.log_martians = 1
Source address validation:
net.ipv4.conf.default.rp_filter = 1
Figure 3-27. Kernel Configuration Options (Interface) LX243.0
Notes:
A number of options can be configured per interface. These are then stored in
/proc/sys/net/ipv4/conf/<interface>. Changes to the "all" interface apply to all current active
interfaces, changes to the "default" interface apply to all interfaces that will be configured
later.
accept_redirects controls whether ICMP redirects are accepted.
send_redirects controls whether ICMP redirects are sent.
accept_source_route controls whether source routed packets are accepted.
log_martians controls whether packets with an unknown (not in the routing table) IP source
address are logged or not.
rp_filter checks whether a packet that arrives on a certain interface is, according to the
routing table, expected to arrive on that interface. Suppose for instance that a packet with
source address 10.0.0.1 arrives on interface ppp0, but the routing table specifies that the
route to the 10.0.0.0 network is through eth0. In that case the incoming packet is rejected.

V3.0
Student Notebook
Uempty Note: rp_filter is known to generate conflicts with certain low-level TCP/IP applications,
such as multicasting and Virtual Private Networking. Be prepared to turn rp_filter off if you
encounter any such problems.
Student Notebook
1. What are the core protocols in the TCP/IP protocol
suite?
2. Name at least two important fields in every one of the
four protocols discussed.
Notes:
1.
2.

V3.0
Student Notebook
Uempty
Summary
The TCP/IP Protocol Suite consists of four major
protocols: IP, ICMP, UDP and TCP
IP forwards data to the destination host
ICMP reports on errors, using IP
UDP offers connectionless, unreliable data transport to
applications, using IP
TCP offers connection-oriented, reliable data transport to
applications, using IP
tcpdump can be used to trace all data packets on a
network
Various kernel options for TCP/IP can be changed in the
/proc/sys/net/ipv4 hierarchy
Notes:
Student Notebook

V3.0
Student Notebook
Uempty Unit 4. Packet Filtering and Network Address

Translation

This unit describes the implementation of packet filtering and network
address translation in Linux.

• Describe Packet Filtering concepts
• Describe Network Address Translation concepts
• Use iptables to implement Packet Filtering and Network Address
Translation
• Save and restore iptables rules

Accountability:
© Copyright IBM Corp. 2000, 2003 Unit 4. Packet Filtering and Network Address Translation 4-1
Student Notebook
Objectives
Describe Packet Filtering concepts
Describe Network Address Translation concepts
Use iptables to implement Packet Filtering and Network
Address Translation
Save and restore iptables rules
Notes:

V3.0
Student Notebook
Uempty
Packet Filtering
Packet Filtering: Filtering IP packets based on
Network Interface
Protocol (UDP, TCP, ICMP, ...)
Source and/or Destination IP address
Source and/or Destination TCP or UDP Port
Direction of TCP Connection Setup
Existence of TCP connection
ICMP Packet Type
MAC address
User ID of sending/receiving process
Possible actions:
Accept: Allow packet
Drop: Don't allow packet
A "rule" is a statement which combines a set of criteria
with an action to perform
Figure 4-2. Packet Filtering LX243.0
Notes:
Packet Filtering is the act of filtering IP packets based on various criteria:
• The Network Interface the packet arrives on or is supposed to leave the system
• The protocol that is listed in the IP packet (UDP, TCP, ICMP or any other protocol that
uses IP)
• The source and/or destination IP address
• The source and/or destination TCP or UDP port
• Direction of TCP Connection Setup
• Existence of a TCP connection where this packet claims to be a part of
• The ICMP packet type
• MAC address
• User ID of sending/receiving process
Based on these filtering rules, there are two main actions that can be performed:
• Allow the packet.
• Drop the packet.
Other actions can be specified, but require the loading of a kernel module. This will be
covered later.
Student Notebook
Network Address Translation

Changing Source and/or Destination IP address and/or
Port of packets in transit
Source NAT (SNAT): Change source IP address
IP Masquerading
Destination NAT (DNAT): Change destination IP address
Port Forwarding
Transparent Proxying
Packet Mangling: Change TCP/IP options
Priority
TTL
Figure 4-3. Network Address Translation LX243.0
Notes:
Network Address Translation is completely separate from IP Filtering, but is implemented in
the same tool. It involves changing the IP addresses and, if necessary, the port numbers
that are listed in the packet.
Generally speaking, there are two forms of NAT: Source NAT and Destination NAT.
With Source NAT (SNAT), the source IP address and, if necessary, the source port is
changed. This is generally called IP Masquerading and is typically used on a firewall to give
internal clients (with a reserved IP address) access to servers outside the firewall. To the
server involved, the connection seems to come from the firewall itself, since the source
address of the IP packet is changed to the IP address of the firewall while the packet
traverses the firewall.
With Destination NAT (DNAT), the destination IP address and, if necessary, the destination
port is changed. There are basically two applications for this:
• With port forwarding, an IP packet which is destined for a specific port on the firewall
itself is forwarded to an IP address in the internal network.

V3.0
Student Notebook
Uempty This is useful if you don't want to run a webserver on your firewall-in-a-box, but want to
place that webserver on your internal network. To the outside world, it looks as if the
webserver is running on the firewall.
• With transparent proxying, an IP packet which originates from the internal network and
has a destination on the outside network is routed to a local port on the firewall. On this
port you typically run a proxy server. This gives clients on the internal network a
transparent connection to the outside world, while in reality they are using a proxy
server.
Something closely related to Network Address Translation, is packet mangling. This means
that other aspects of the TCP/IP packet, such as the options or the TTL is changed.
Student Notebook
Chains (1)
A "chain" is a series of rules that are checked for a
certain type of packet
Default chains:
INPUT: For packets send to this host
OUTPUT: For packets send from this host
FORWARD: For packets send through this host
PREROUTING: For DNAT
POSTROUTING: For SNAT
A user can add his own chains
A rule in a default chain then refers to this chain
Rules in a chain are checked in order
When a rule does not match, check next
When a rule matches, execute the action
Accept, Drop or go to user-defined chain
Figure 4-4. Chains (1) LX243.0
Notes:
A chain is a notion which is central to the kernel filtering rules. It is basically a series of
rules which are checked in order for certain types of packets.
There are five default chains: INPUT, OUTPUT, FORWARD, PREROUTING and
POSTROUTING.
A user can add his own chains under any given name. Actions in one of the default chains
then can point to this user defined chain. This can be very useful in large installations,
where you can just have a number of user-defined chains and "plug them in" the input and
output chain to get a certain behavior. Such a hierarchical structure may benefit
performance as well.
When a packet needs to be tested against a given chain, each rule is tested in turn. When
the packet matches the rule, the action for that rule is executed. When the packet does not
match the rule or the rule does not specify an action1, the next rule is tested. When none of
the rules match, the default action for a chain is performed.
1
A rule might be there for logging or statistics collation, not for filtering.

V3.0
Student Notebook
Uempty
Chains (2)
Incoming Packets
Sanity Check
PREROUTING
y Destination n
= local?
ip_forward n
INPUT on?
y
Local Process FORWARD
OUTPUT Discard
packet
POSTROUTING
Outgoing Packets
Figure 4-5. Chains (2) LX243.0
Notes:
The visual shows the order in which the chains are checked. Note that the INPUT,
OUTPUT and FORWARD chains are mainly used for packet filtering, while NAT takes
place in the PREROUTING (DNAT) and POSTROUTING (SNAT) chain.
Student Notebook
Packet Filtering in Linux

Packet Filtering done at kernel level
Usually compiled as kernel modules which are loaded
automatically
Configuration done with user space tools
Linux 2.0 kernel: ipfwadm
Linux 2.2 kernel: ipchains
Linux 2.4 kernel: iptables
Downwards compatibility ensured
Additional features:
Logging
Statistics
Figure 4-6. Packet Filtering in Linux LX243.0
Notes:
Packet Filtering is implemented in the Linux kernel. It is one of the areas where
development is still ongoing to get the best performance and flexibility.
The configuration of the kernel filter rules is done through a user space tool. This tool is
continually improving to keep track of the kernel changes. The tool for the 2.0.x series
kernel was called ipfwadm, the tool for the 2.2.x kernel is called ipchains and the tool for
the current (2.4.x) kernel is called iptables. However, up until now downwards compatibility
has been ensured.
In addition to the filtering rules, the kernel also supports logging and statistics gathering.

V3.0
Student Notebook
Uempty
The iptables Tool
User level tool for configuring kernel filter rules
Different modes of operation:
Flush all rules
Set default action for a chain
Append, Insert, Replace, Delete rules
Display rules
Display, reset statistics
Check packet against a chain
iptables-save and iptables-restore can be used to save
and restore all rules to/from a file
Figure 4-7. The iptables Tool LX243.0
Notes:
The iptables tool is the tool which is used to configure the Linux kernel filter rules. It has
various modes of operation.
In addition to this, two other tools, iptables-save and iptables-restore can be used to save
the current ruleset to a file and to restore the ruleset from a file.
Student Notebook
iptables Basic Syntax (1)

iptables [-t table] command [chain] [parameters] [-j
target]
Tables:
filter (default): For filtering rules
nat: For NAT rules
mangle: For packet mangling rules
Simple commands:
-L: List all rules
-F: Flush all rules
-Z: Zero all counters
-A: Append a rule
-I: Insert a rule
-P: Default action for this chain
-N: Create user defined chain
-X: Delete user defined chain
Figure 4-8. iptables Basic Syntax (1) LX243.0
Notes:
The basic syntax of the iptables command is iptables [-t table] command [chain]
[parameters] [-j target]
Because of the different layout of a filter, NAT or mangle rule, they are stored in three
different tables:
• filter: For filter rules
• nat: For NAT rules
• mangle: For packet mangling rules
If no table is specified, the filter table is used.
Some of the more common commands are:
• -L: List all rules.
• -F: Flush all rules. This removes all the rules.
• -Z: Zero all counters.

V3.0
Student Notebook
Uempty • -A: Append a rule to the end of the chain.

• -I: Insert a rule to the top of the chain.
• -P: Specify a default action for the chain (executed if no rule in the chain matches).
• -N: Add a user-defined chain.
• -X: Delete a user-defined chain.
The -L, -F and -Z commands can optionally take the name of a chain as parameter, in
which case the command only applies to that chain. For all other commands, the chain is
required, and the command only applies to that chain.
Student Notebook
iptables Basic Syntax (2)

iptables [-t table] command [chain] [parameters] [-j
target]
Simple parameters:
-i incoming interface
-o outgoing interface
-p protocol
-s source-IP
--sport source-port
-d destination-IP
--dport destination-port
--icmp-type type
Use ! to negate options
Targets:
Basic: ACCEPT, DROP
Extended (require kernel module): REJECT, LOG, ...
Figure 4-9. iptables Basic Syntax (2) LX243.0
Notes:
Some simple parameters that specify the filtering criteria:
• -i interface: The interface that the packet was received on.
• -o interface: The interface that the packet will be transmitted on.
• -p protocol: The protocol as mentioned in the IP packet (for instance, TCP, UDP, ICMP).
The protocol may be listed as symbolic name (tcp) or value (6).
• -s source-ip: The source IP address.
• --sport source-port: The source port number.
• -d destination-ip: The destination IP address.
• --dport destination-port: The destination port number.
Source IP addresses may be specified as networks too, using the IP address/netmask
or IP address/bits notation (10.0.0.0/255.255.255.0 or 10.0.0.0/24). The any/0 or 0/0
notation means any IP address.

V3.0
Student Notebook
Uempty Source ports and destination ports are only valid when a protocol is specified that
supports port numbers. Port numbers may also be specified as ranges (1:1023).
• --icmp-type type: The ICMP message type.
The exclamation sign (!) can be used to negate options. For instance, "-s ! 10.0.0.1"
matches any source IP address except 10.0.0.1.
There are more options possible, depending on the protocols involved and the kernel
modules loaded. These are all covered in the iptables manual page.
A number of targets can also be used. The target is always identified with the -t option:
• ACCEPT, DROP: These are built-in actions which allow or discard the packet,
respectively.
• REJECT, LOG, ...: These are actions that are defined in a loadable. kernel module. Only
if the kernel module is loaded can the action be chosen2
2
Fortunately, in most cases modprobe will load the correct module for you.
Student Notebook
Scenario
The Internet
ppp0: 62.186.134.70
Firewall
in-a-box
eth0: 10.0.0.1
Company Network
10.0.0.0/24
Figure 4-10. Scenario LX243.0
Notes:
This is the scenario that will be used in the following examples.

V3.0
Student Notebook
Uempty
iptables Initial Setup
Delete all user-defined chains
Flush all rules
Set default policy for each chain
Enable all traffic over the loopback and ethernet interface
Deny all traffic not destined for or originating from the
external interfaces IP address
# iptables -X
# iptables -F
# iptables -P INPUT DROP
# iptables -P OUTPUT DROP
# iptables -P FORWARD DROP
# iptables -A INPUT -i lo -j ACCEPT
# iptables -A OUTPUT -o lo -j ACCEPT
# iptables -A INPUT -i eth0 -j ACCEPT
# iptables -A OUTPUT -o eth0 -j ACCEPT
# iptables -A INPUT -i ppp0 -d ! 62.186.134.70 -j DROP
# iptables -A OUTPUT -o ppp0 -s ! 62.186.134.70 -j DROP
Figure 4-11. iptables Initial Setup LX243.0
Notes:
When starting with a new iptables set of rules we usually prefer to start with an empty set.
This is done with the iptables -X command, which deletes all user-defined chains, and with
the iptables -F command, which flushes all rules.
We then specify the default policy for each chain, in this case DROP.
We then enable all traffic over the loopback device. A number of programs (including X)
require this and it is not a security risk.
Continuing, we enable all traffic over the Ethernet device. This is our internal adapter and
not so much a security risk. (If we don't trust our own colleagues we can actually install
filtering rules here too.)
Lastly, we deny all traffic that arrives on our external interface but does not have our
interface as destination address, or originates from our interface but does not have our
interface as source address. This might happen if somebody is using our firewall as a plain
router, if somebody is broadcasting IP packets or if somebody is spoofing IP addresses.
Student Notebook
Protect against Spoofed Addresses

Don't accept or send packets on the external interface
claiming to be coming from and/or going to
The internal network
Yourself
Any reserved IP address
The loopback interface
Universal broadcast addresses
# iptables -A INPUT -i ppp0 -s 10.0.0.0/8 -j DROP
# iptables -A OUTPUT -o ppp0 -d 10.0.0.0/8 -j DROP
# iptables -A INPUT -i ppp0 -s 0.0.0.0 -j DROP
# iptables -A OUTPUT -o ppp0 -d 255.255.255.255 -j DROP
Figure 4-12. Protect against Spoofed Addresses LX243.0
Notes:
The IANA reserved a number of addresses for Intranets, which means that these
addresses may never be used on the Internet. IP packets claiming to come from these
addresses are therefore either spoofed or caused by a misconfiguration. In both cases we
can safely deny these packets. The same holds for addresses claiming to be from 0.0.0.0,
or claiming to go to 255.255.255.255.

V3.0
Student Notebook
Uempty
Configure ICMP Echo Request/Reply Filtering
Allow ICMP Echo Request/Reply (type 8/0)
Can be used in smurf DoS attacks though
Sending echo requests to a broadcast address with
spoofed source address floods a server with replies
So only accept Echo Requests for your IP address
# iptables -A OUTPUT -o ppp0 -p icmp -s 62.186.134.70 -d 0.0.0.0/0 --icmp-type 8 -j ACCEPT

# iptables -A INPUT -i ppp0 -p icmp -s 0.0.0.0/0 -d 62.186.134.70 --icmp-type 0 -j ACCEPT

Figure 4-13. Configure ICMP Echo Request/Reply Filtering LX243.0
Notes:
In most cases you will need to allow the outside world to ping your firewall. And almost
certainly you will want to be able to ping the outside world from your firewall. The rules in
the visual allow you to do just that.
Student Notebook
Configure other ICMP Filtering

Allow the following ICMP packets:
Destination Unreachable (type 3)
Source Quench (type 4)
Time exceeded (type 11)
Parameter Problem (type 12)



Figure 4-14. Configure other ICMP Filtering LX243.0
Notes:
In addition to ping, you might want to enable other types of ICMP packets too, depending
on your situation. The rules above are meant as a suggestion.

V3.0
Student Notebook
Uempty
Configure Outgoing TCP/UDP Connections
Allow outgoing TCP and UDP connections
Source port > 1023, destination port <= 1023
# iptables -A OUTPUT -o ppp0 -p tcp -s 62.186.134.70 --sport 1024: -d any/0 \

--dport :1023 -j ACCEPT
# iptables -A INPUT -i ppp0 -p tcp -s any/0 --sport :1023 -d 62.186.134.70\
--dport 1024: -j ACCEPT
# iptables -A OUTPUT -o ppp0 -p udp -s 62.186.134.70 --sport 1024: -d any/0 \

# iptables -A INPUT -i ppp0 -p udp -s any/0 --sport :1023 -d 62.186.134.70\
Figure 4-15. Configure Outgoing TCP/UDP Connections LX243.0
Notes:
The last "general" iptables rule we will want to add is to allow outgoing TCP and UDP
connections. This can easily be configured because outgoing connections are supposed to
originate from portnumbers 1024 and higher, while their destination is a port lower than
1024.
Note: There are some protocols that do not follow this convention3. Fortunately, none of
these protocols are generally required to pass our firewall.
3
For example, NFS.
Student Notebook
Identd Considerations
The IDENTD protocol (RFC 1413) identifies the owner of
a connection
Used for FTP
Required for IRC
Uses TCP port 113
Incoming connections should not be denied but rejected
Otherwise: long timeouts on the client
Disadvantage: Hackers may use this instead of ping to
determine if a host is alive
# iptables -A INPUT -i ppp0 -p tcp -s 0.0.0.0/0 -d 62.186.134.70 --dport 113 -j REJECT
1025 ftp logon request 21

ftp client
113 who is on port 1025? ftp
identd tux is on port 1025 daemon
welcome, tux
Figure 4-16. Identd Considerations LX243.0
Notes:
Identd is a strange protocol. It works roughly as follows:
• You initiate an outgoing ftp session (or irc, or anything else) to a remote server.
• The remote ftp server accepts the connection.
• The remote ftp server then initiates a second connection to the identd daemon running
on your local host, and sends your local port number to the identd daemon.
• The local identd daemon then retrieves your local username and sends it to the remote
ftp daemon.
• The remote ftp daemon then greets you with your own username.
Obviously having an identd daemon running on your local host poses a slight security risk,
because it is possible to retrieve local usernames through this. But the problem is, just
dropping traffic to the identd port (tcp/113) is no solution either. If the remote ftp daemon
cannot contact your identd daemon and receives nothing back, it will wait until its timeout
expires (usually 5 to 15 seconds) before it will greet you (without your username of course).
It is therefore a good idea to REJECT instead of DENY traffic to port 113. The remote ftp

V3.0
Student Notebook
Uempty daemon will then receive an ICMP destination unknown packet and will continue
immediately.
The REJECT action is an extended action which requires the ipt_REJECT kernel module.
This module is loaded automatically when you configure REJECT rules.
Student Notebook
iptables Statistics
For every rule configured, a counter counts the number of
matches for that rule
To retrieve counters, use iptables -v -L [chain]
Use -x option to print full numbers instead of K, M or G
To reset counters, use iptables -Z [chain]
Figure 4-17. iptables Statistics LX243.0
Notes:
For every rule that is defined in all your chains, a counter counts the number of matches to
that rule, as well as the total number of bytes.
To retrieve these counters, use the iptables -v -L [chain] command. The numbers will be
rounded to the nearest thousand, million or billion if appropriate, and will have a K, M or G
appended. To prevent this use the -x option.
To reset all counters use iptables -z [chain].

V3.0
Student Notebook
Uempty
iptables Logging
Arbitrary packets can be logged to syslogd with "LOG"
target (requires ipt_LOG kernel module)
Use --log-level to specify log level (default DEBUG)
Use --log-prefix to specify prefix
Facility is always KERN
To limit the amount of logging, use -m limit extension
(requires ipt_limit kernel module)
Use --limit to specify maximum average
Use --limit-burst to specify maximum initial number
LOG rules are nondeterministic: can be inserted
anywhere in a chain without affecting the workings of the
chain
# iptables -I INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level DEBUG\
--log-prefix "Incoming IP packet:"
Figure 4-18. iptables Logging LX243.0
Notes:
iptables supports logging too as a separate target. This is done with the kernel module
ipt_LOG, and logs to the syslogd daemon.
The --log-level option allows you to specify which log level to use, and the --log-prefix
allows you to specify a prefix text.
Since a small network packet can lead to a large number of bytes in the logfile, you need to
be careful not to suffer a DoS attack this way. For this, it is a good idea to limit the amount
of logging by combining it with the ipt_limit kernel module functionality. This kernel module
can in fact be used with every rule, including filtering rules, and effectively limits the number
of times a certain rule is matched in any given period. This module is neither a protocol not
a target, so it needs to be activated separately with the -m option. If it is activated, two
additional options become available:
--limit, which specifies a maximum average number
--limit-burst, which specifies a maximum burst number
Student Notebook
A rule with the LOG target is nondeterministic. This means that after the rule has matched
and is executed, the next rule is matched, instead of jumping out of the chain. This means
that LOG rules can be inserted anywhere in the chain. A LOG rule that is inserted at the
start of the chain will for instance log all packets, while a LOG rule at the end of a chain will
log all packets that were not DROPped or ACCEPTed by earlier rules, and thus will be
handled by the default action for that chain.

V3.0
Student Notebook
Uempty
IP Masquerading
Only done on a router
Replaces the source IP address with the router IP
address on outgoing packets
Keeps track of connections for de-masquerading
Also works for UDP and ICMP
10.0.0.2:1287 -> 134.191.38.72:80 62.186.134.70:4011 -> 134.191.38.72:80
Router
Client 134.191.38.72:80 -> 10.0.0.2:1287 with 134.191.38.72:80 -> 62.186.134.70:4011 Server
IP Masq.
10.0.0.2 10.0.0.1 134.191.38.72

62.186.134.70
Intranet Internet
Figure 4-19. IP Masquerading LX243.0
Notes:
IP Masquerading is the process whereby on a router the source IP address and port
number on an outgoing packet are replaced with the IP address of the router and a suitable
port number. Any packets then returning to that port number are subsequently changed to
contain the right destination IP address and port number (de-masquerading)
This is done for two reasons:
• To protect the identity of the client host and the structure of the internal network.
• To allow a company to use any of the IANA reserved address ranges for its Intranet
without sacrificing Internet access.
Although usually only done with TCP, UDP and ICMP packets can be masqueraded as
well.
Student Notebook
Configuring IP Masquerading
Done with iptables in "POSTROUTING" chain
Target MASQUERADE used for dynamic IP addresses:
Connections dropped when interface is down
Target SNAT used for static IP addresses: Connections
persist when interface down; requires specification of
source address
Need to allow this traffic in FORWARD chain
IP Forwarding needs to be enabled
# iptables -t nat -A POSTROUTING -o ppp0 -p tcp -s 10.0.0.0/24 --sport 1024: -d ! 10.0.0.0/24\
--dport :1023 -j SNAT --to-source 62.186.134.70
- OR -
# iptables -t nat -A POSTROUTING -o ppp0 -p tcp -s 10.0.0.0/24 --sport 1024: -d ! 10.0.0.0/24\
--dport :1023 -j MASQUERADE
# iptables -A FORWARD -i eth0 -o ppp0 -p tcp -s 10.0.0.0/24 --sport 1024: -d ! 10.0.0.0/24\

# iptables -A FORWARD -i ppp0 -o eth0 -p tcp -s ! 10.0.0.0/24 --sport :1023 -d 10.0.0.0/24\
# echo 1 > /proc/sys/net/ipv4/ip_forward
Figure 4-20. Configuring IP Masquerading LX243.0
Notes:
NAT is implemented in the POSTROUTING chain by specifying a special action
"MASQUERADE" or "SNAT".
"MASQUERADE" is typically used on a system which uses dynamic IP addresses on its
outgoing interface. All outgoing connections via this interface must be dropped when the
interface goes down, since next time the IP address on that interface might be different.
"SNAT" is typically used on a system which uses one or more static IP addresses on its
outgoing interface. When the interface goes down, it does not need to drop all connections.
When the interface is brought up again, the same IP address is used. "SNAT" rules require
you to specify the source address to masquerade as with the --to-source option.
In order for IP Masquerading to work, you need to add filter rules to the FORWARD chain
that allow connections originating from the internal network to pass through the firewall.
Furthermore, IP forwarding needs to be enabled in the kernel.
IP Masquerading can be done for TCP, UDP and ICMP, although usually only TCP is
allowed (as in the visual). UDP has the problem that it is a stateless protocol. The Linux

V3.0
Student Notebook
Uempty kernel therefore is not able to detect that a connection has ended and has to work with
timeouts before releasing the port. ICMP does not work with port numbers at all, making
NAT very difficult to implement in a secure manner.
Student Notebook
Configuring NAT for Difficult Situations

NAT support in Linux is extensible by loading kernel
modules
For regular FTP support (with server initiated data conn.)
modprobe ip_conntrack_ftp ip_nat_ftp
For IRC support
modprobe ip_conntrack_irc ip_nat_ftp
And more...
Make permanent by adding this to /etc/rc.local or
/etc/modules.conf
Figure 4-21. Configuring NAT for Difficult Situations LX243.0
Notes:
A number of protocols do strange things like opening a reverse tcp connection (from the
server to the client). To cope with these situations different IP masquerading modules have
been developed which are aware of the difficulties involved in masquerading that protocol
and thus enable running that protocol across a firewall.
Note however that this generally means opening up your internal network to tcp
connections coming from the outside. If not configured correctly, this might cause security
problems.
As an example, let's consider the FTP protocol. The original protocol works like this:
• An ftp client opens a TCP connection (portnumber 1024 or higher) to the ftp server (port
21).
• This connection (called the control connection) is used to transfer the username and
password, and all the commands that the user gives.
• If the user gives a command that involves a data transfer (such as an ls, dir, get or put),
the client ftp program requests another (dynamically assigned) TCP port from the

V3.0
Student Notebook
Uempty operating system. The client then sends this port number with a special command, over
the control connection, to the ftp server. ("Port command successful.")
• The ftp server then opens a TCP connection, originating from port 20 to the client port
which it just received. This connection is the data connection and is used to transfer the
data. After the data transfer has finished, this connection is closed. ("Data connection
closed.")
In a firewall situation, this presents a problem, because an incoming TCP connection is not
allowed. One of the ways to solve this is to load the ip_conntrack_ftp and ip_nat_ftp
modules. These modules are FTP-aware and will enable reverse NAT (actually port
forwarding) as soon as the port command is issued in an FTP control connection.
You can add the various modprobe commands to /etc/rc.local, but you can also use
post-install commands in /etc/modules conf to load these modules automatically:
post-install ip_conntrack modprobe ip_conntrack_ftp
post-install iptable_nat modprobe ip_nat_ftp
Student Notebook
Saving and Restoring iptables Rules

# /sbin/iptables-save > iptables.rules
# chmod 600 /etc/iptables.rules
# cat /etc/iptables.rules
*mangle
:INPUT DROP
...
COMMIT
*nat
:PREROUTING ACCEPT
:POSTROUTING ACCEPT
-A PREROUTING -s ...
COMMIT
*filter
:INPUT DROP
:FORWARD DROP
:OUTPUT DROP
-A FORWARD -s...
COMMIT
# iptables -F
# iptables -X
# /sbin/iptables-restore < iptables.rules
Figure 4-22. Saving and Restoring iptables Rules LX243.0
Notes:
The programs iptables-save and iptables-restore allow you to save your current ruleset and
to restore it at a later moment.

V3.0
Student Notebook
Uempty
Restoring iptables Rules on Startup (Red Hat)
Red Hat comes with an iptables startup script
/etc/rc.d/init.d/iptables
Supports various options:
start: Restore rules from /etc/sysconfig/iptables
stop: Flush rules, delete user-defined chains
restart: Same as stop/start
save: Save current rules in /etc/sysconfig/iptables
panic: Flush all rules, set all defaults to DROP
status: Executes iptables -nL
Integrated in boot process before networking is started
chkconfig iptables on
Figure 4-23. Restoring iptables Rules on Startup (Red Hat) LX243.0
Notes:
Red Hat ships with an iptables startup script called /etc/rc.d/init.d/iptables. This script
support various options to easily work with iptables rules.
The following options are supported:
start Flush all iptables rules, delete all user defined chains and read all rules
from /etc/sysconfig/iptables.
stop Flush all iptables rules and delete all user defined chains.
restart Same as stop/start.
save Save the current ruleset to /etc/sysconfig/iptables
panic Flush all rules and set all default policies to DENY.
status Execute iptables -nL
By configuring this script before networking is started you can be sure that all your rules are
in place once you've got a network connection.
Student Notebook
SuSEfirewall2
SuSE comes with an elaborate firewall setup:
yast: Configure internal/external interface and services
offered - stored in /etc/sysconfig/SuSEfirewall2
rcSuSEfirewall2: Script that activates about 200
iptables rules to protect system properly, based on
/etc/sysconfig/SuSEfirewall2 information
If you don't want to use SuSEfirewall2, need to make
your own startup scripts, e.g. using iptables-restore
Figure 4-24. SuSEfirewall2 LX243.0
Notes:
SuSE comes with a highly advanced firewall setup called SuSEfirewall2. This basically
consists of two components:
• yast has a firewall module that basically asks you what your internal and external
interfaces are, what services you want to allow on your external interface, and whether
you want IP forwarding and masquerading or not. All this information is then stored in
/etc/sysconfig/SuSEfirewall2.
• rcSuSEfirewall2 and a few other scripts take the information in
/etc/sysconfig/SuSEfirewall2 and activate about 200 iptables rules to properly protect
your system, while allowing access to the services mentioned. They even go as far as
configuring rules that change the TOS (Type of Services) of, for instance, FTP data
connections to “maximum throughput” and DNS queries to “minimize delay”.
The rules that are configured by SuSEfirewall2 are suitable for most situations. However, if
you want something really special, there is no hook in the scripts to configure your own
rules. In that case, you will have to disable SuSEfirewall2, and create your own startup
scripts. Such a script will generally use iptables-restore to activate a set of custom rules.

V3.0
Student Notebook
Uempty Since that is exactly what Red Hat does (activate a set of iptables rules that are stored in a
file which was created by iptables-save) you could also copy the /etc/init.d/iptables file
from Red Hat.
Student Notebook
FWBuilder
GUI frontend that allows for easy creation/management
of firewall rules
Supports other firewall rule types as well: ipfilter,
OpenBSD PF and Cisco PIX
http://www.fwbuilder.org
Figure 4-25. FWBuilder LX243.0
Notes:
FWBuilder is an open-source project (http://www.fwbuilder.org) that aims to create an
easy-to-use frontend for various firewall products. It works by creating a generic policy file,
where you define the traffic that is allowed and not allowed to pass through your firewall.
This policy file can be created using a drag-and-drop GUI interface.
Once the policy file has been created, you can use it to create firewall rules for a variety of
operating systems and hardware firewalls. Currently, FWBuilder supports Linux iptables,
ipfilter, OpenBSD PF and Cisco PIX.

V3.0
Student Notebook
Uempty
Other iptables Features
Transparent proxying
A packet that needs to be routed is sent to the local
system (e.g. proxy) instead (DNAT)
Port forwarding
A packet that is sent to a local port is masqueraded and
sent to another server instead (DNAT)
Useful if you have an internet web server inside the
firewall
Stateful TCP inspection
Only allows TCP packets through that belong to an
existing connection
Requires ipt_state kernel module
Packet mangling
Change IP and TCP options on packets in transit
Figure 4-26. Other iptables Features LX243.0
Notes:
iptables has some other useful features here which we will not discuss in depth here.
• The first feature is transparent proxying. What happens when you enable it is that a
packet that should be routed by the firewall (so both the source and destination IP
address are not the firewalls), is sent to a local port anyway, where for instance a
caching proxy is active. This allows clients to think that they have a direct connection to
the Internet, while in fact they are behind a proxy. The following iptables rules define
transparent proxying for outgoing traffic:
# iptables -t nat -A PREROUTING -p tcp -s 10.0.0.0/0 --sport 1024:\
-d any/0 --dport 80 -j DNAT --to-destination 10.0.0.1:8080
• The second feature is port forwarding. Port forwarding is sort of the opposite of
transparent proxying. In this case a packet that has the firewall as destination is
masqueraded and sent on to another host, for instance a webserver inside the firewall.
Port forwarding is by default not built into Linux, but can be enabled. The following
iptables rule define port forwarding for all incoming connections to port 80:
Student Notebook
# iptables -t nat -A PREROUTING -p tcp -s any/0 --sport 1024: -d\ 62.186.134.70

--dport 80 -j DNAT --to-destination 10.0.0.10:80
• Another useful feature of the Linux netfilter implementation is stateful TCP inspection.
This allows you to specify filter rules that only allow packets through that are part of an
existing TCP connection. This marginally improves your security, since it is harder for
hackers to "hijack" existing TCP connections (but that was already really hard even
without stateful TCP inspection).
So far, we've always allowed TCP connections with rules like this:
# iptables -A FORWARD -p tcp -j ACCEPT
With stateful TCP inspection, such a rule becomes:
# iptables -A FORWARD -p tcp -m state --state NEW --syn -j ACCEPT
# iptables -A FORWARD -p tcp -m state --state ESTABLISHED,RELATED -j\ ACCEPT
# iptables -A FORWARD -p tcp -m state --state INVALID -j DROP
(Note that you might want to add filter rules based on source and destination IP address
and port. They have been left out for clarity.)
Stateful TCP inspection requires a lot more administration than stateless IP filtering. In
particular, you need to have enough memory available to store the state of all
connections, and the CPU power to handle all the administration. This can be a problem
on a high-bandwidth router.
Stateful TCP inspection is automatically enabled when your router performs NAT, so if
you are already using NAT, the additional performance penalty for enabling stateful TCP
inspection is negligible.
• Packet mangling is the last feature we'll discuss here. It is used to alter other IP and
TCP options while the packets are in transit. As an example, here's a rule that changes
the IP Type of Service field on all outgoing SMTP connections to "Minimize Cost":
# iptables -t mangle -A OUTPUT -p tcp --dport 25 -j TOS --set-tos 0x02

V3.0
Student Notebook
Uempty
1. What criteria can be used in packet filtering?
2. How is packet filtering implemented in Linux?
3. What is a chain?
4. What is a rule?
5. What is Network Address Translation?
Notes:
1.
2.
3.
4.
5.
Student Notebook
Summary
Packet Filtering and Network Address Translation is
integrated in the Linux Kernel
The user administration tool depends on the kernel level:
ipfwadm, ipchains or iptables
Netfilter uses five default "chains", each containing rules
which are applied to packets
A rule can specify different things to do with a packet:
ACCEPT, DROP, REJECT, LOG, SNAT, DNAT,
MASQUERADE
Notes:

V3.0
Student Notebook
Uempty Unit 5. Secure Shell and Secure Copy

This unit describes the inner workings of the SSH protocol and the
installation of OpenSSH.

• Discuss problems associated with telnet, ftp, rlogin, rsh, rcp and
rexec
• Describe the SSH standard
• List different SSH implementations
• Use OpenSSH

Accountability:
© Copyright IBM Corp. 2000, 2003 Unit 5. Secure Shell and Secure Copy 5-1
Student Notebook

'

' ##
##
X< ##
Notes:

V3.0
Student Notebook
Uempty
B ><>> >"

#
*

X"`
[<+!"
*

' '_#
Figure 5-2. Telnet, ftp, rexec, rsh, rcp Problems LX243.0
Notes:
Various problems are associated with the traditional methods of remote login (rlogin, rsh),
file transfer (ftp, rcp) and remote execution (rsh, rexec). The most important problem is that
passwords are passed around in clear text, available for anybody to see with a sniffer. The
second problem is that authentication can be configured by a user to be based on IP
address instead of password, using the ~/.rhosts file, and by the superuser using the
/etc/hosts.equiv file. This is vulnerable to IP spoofing and, if hostnames instead of IP
addresses are used, dependent on a DNS server which itself might be compromised.
Student Notebook
775"""
^""
#
'$ Y]~
&
\ ^
Y

Y
< ^
!
X
#

# 9
X
9

Y YY 9
Figure 5-3. SSH Protocol LX243.0
Notes:
A solution to the problems in the previous visual is the SSH protocol. It was invented by a
Finnish company, not coincidentally called ssh. They submitted the protocol description to
the IAB (Internet Architecture Board), where it now lives as an Internet Draft. This is an
interim status in which standards can exist before an RFC number is assigned.
The SSH protocol provides you with all the capabilities mentioned before. The only
difference is that SSH uses strong encryption to encrypt the data in transit and to
authenticate the client and the server.
A typical SSH implementation consists of two client programs:
• ssh, which is used for remote logins and remote command execution.
• scp, which is used for remote copy.
In addition to this, you need to run a server program called sshd.
ssh and scp have the same syntax and capabilities as rsh and rcp. In fact, for ease of use,
most ssh implementations actually offer replacements for rsh and rcp, which actually use
the SSH protocol.

V3.0
Student Notebook
Uempty
775
"

^
^""
\
]
^" "
_
7_X

X< ##

@ 6_\^
*
"#
^"
" "
"
Figure 5-4. SSH Implementations LX243.0
Notes:
SSH is implemented on various operating systems, including Linux and Windows
95/98/NT/2000.
On Linux, the traditional implementation was done by http://www.ssh.fi. Unfortunately, this
company was bought by another who decided to change the license statement for SSH
2.0. You are no longer allowed to use their product in a commercial organization without
paying license fees. In addition to that, their product suffered from a number of security
problems which is especially important in high-risk areas such as firewalls.
So another group of people decided to implement the SSH protocol in an open source
product (GNU Public License). This product is called OpenSSH. It uses the OpenSSL
library of cryptographic routines, making it one of the most flexible SSH implementations
available.
Student Notebook
:
#^ "" " "$
^
34^!
$ &
3"4^]

^X
8^X
] [<+!"
]

^['#

9
!
$ &
Figure 5-5. ssh Usage LX243.0
Notes:
The ssh command allows you to remote login to a system, and optionally allows you to
execute a command automatically. By default it tries to log you in using the same
username as you are currently using, but this can be changed by specifying user@host
instead of the hostname.
If you login to a system remotely, and if enabled, ssh will also try to set up the $DISPLAY
variable and X authentication for you so, that any X clients that you start on the remote host
are automatically authenticated and tunneled over the SSH connection to your local
system.

V3.0
Student Notebook
Uempty
:
#^ "" "< $ "<
< ^
34^!
$ &
^
^]

8^X
3"4^]

~ ^ " <
\ Y ^

+
>! >
-! -
Figure 5-6. scp Usage LX243.0
Notes:
The scp command lets you copy files to and from the remote system. It is even possible to
do third-party copies, as shown in the visual1.
1
Well, at least, it is possible according to the official documentation. In reality, it doesn’t work. This is a long-standing bug.
Student Notebook
$:
'
'

#" "
@^
]
]Y ]#9
9
Y ]#9$ 9&
@
_ 9
!
9

$&
Figure 5-7. sshd Usage LX243.0
Notes:
The sshd daemon process should be running on the server. It is usually not run out of
[x]inetd, because it needs to generate an RSA session key2 each time it starts, and this
takes some seconds.
Note: A useful thing to know is that sshd can be started with the -d option. This prevents
sshd from forking itself into the background, and sends all debug output to stdout/stderr,
and is very useful for debugging a faulty configuration file.
2 A session key is a key which is unique to a particular session (invocation of sshd). Since a session key is never stored on disk, it is
extremely hard to obtain it and thus decrypt the data. Also, because session keys change with each session, replay attacks and the like
are impossible.

V3.0
Student Notebook
Uempty
# $5" "
!9
9 9

9 9"

X
9

X ^X9" $&J
@

9
[<+!"9
X
`
9 "
@ # 9

9
9[<+!"9
Y YY 9
Figure 5-8. ssh/sshd Host Authentication LX243.0
Notes:
Every sshd host (server) needs to generate a host key pair. This was done at install time
with the make host-key command. This key pair is stored in /etc/ssh/ssh_host_key
(private key) and /etc/ssh/ssh_host_key.pub (public key).
When a client first connects to the server, the public key of the host is transferred to the
client. The client then shows a warning that this host is unknown, and allows you to accept
this key or not. When the user accepts, the public key is stored in
$HOME/.ssh/known_hosts. Upon subsequent connections, the keypairs are verified and
the user is warned if the keys don't match.
When the StrictHostKeyChecking option is set either in $HOME/.ssh/config or in
/etc/ssh/ssh_config, the user can only connect to hosts whose public key is stored in
/etc/ssh/known_hosts or $HOME/.ssh/known_hosts. This effectively prevents against
man-in-the-middle attacks.
Student Notebook
$: "

~
^
" "
$ &
]`
"
"`
$
Y
&
" " ]#
$ &
]`
"
"`
`

]# $
Y

&
" ]#Y

]`

]#9
$
&
"

]`

$

9&
Figure 5-9. sshd User Authentication LX243.0
Notes:
After host authentication, user authentication is done. This is a four step process:
The first step is to verify whether the hostname (possibly in combination with the
username) is stored in $HOME/.rhosts or /etc/hosts.equiv. This works exactly the same as
rsh, rcp or rlogin and is considered very insecure. It is disabled by default.
The next step is .rhosts authentication combined with RSA authentication. This is
considered fairly insecure and normally disabled.
The third step is RSA challenge-response authentication. This basically comes down to the
fact that the user has to have the correct RSA key pair to be able to login. This is really
secure, even more secure than password authentication. The user needs to set it up
though.
The last step is password based authentication. Although the password is sent over an
encrypted channel, there are still possibilities of figuring out what the password is, based
on the timing with which the various packets are sent over the line3.

V3.0
Student Notebook
Uempty Most implementations of SSH will also check for the existence of /etc/shosts.equiv and
$HOME/.shosts in addition to /etc/hosts.equiv and $HOME/.rhosts in the first two steps.
3
This form of attack is described in http://paris.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf. What it basically comes down to is
that they have measured the amount of time that an experienced typist needs between keystrokes. This turns out not to be constant, but
is to a large extent depending on the placement of the characters, and the sequence of fingers needed to type them. The sequence ’fj’,
which is normally typed with the index finger of the left hand and then the index finger of the right hand, takes less time to type than the
sequence ’qa’, which are both typed with the little finger of the left hand.
Armed with this knowledge and a considerable amount of advanced statistics, the researches were able to gain a 50-fold decrease in
passwords that needed to be checked, compared to a brute-force attack. In practice, this meant that they would not need 65 days but
only 1.3 days to find the password of an arbitrary user.
Student Notebook
%78 % " "

X]#9 !
9 [<+!"

9 [<+!" "

\
9
[<+!"
>9
$8%$7$$!
$8%$7$$

1/
X

Figure 5-10. RSA Challenge-Response Authentication LX243.0
Notes:
RSA Challenge-Response Authentication requires each user to generate a keypair on the
client host with the ssh-keygen command. This command then stores the private key in
$HOME/.ssh/identity and the public key in $HOME/.ssh/identity.pub. The usage of this key
can be protected with a passphrase (so the system administrator cannot borrow them...)
The user then transfers the public key to the server and adds it to
$HOME/.ssh/authorized_keys. After that, the user can login without needing to supply a
password to authenticate itself. (Note however that if the key is protected with a
passphrase, he still has to type that one.)

V3.0
Student Notebook
Uempty
;78 % " "
##*
'# ]#
\'#9
!$
9 [<+!"

9 [<+!" "

\
9
[<+!"
>9
$8%$7$$!
$8%$7$$

1/%

1/%
X

Figure 5-11. DSA Challenge/Response Authentication LX243.0
Notes:
The SSH version 2 protocol uses DSA instead of RSA for user authentication. The
principles are completely the same, only the commands and files involved are a little
different:
• A keypair is generated with ssh-keygen -d instead of ssh-keygen.
• The keys are stored in id_dsa and id_dsa.pub instead of identity and identity.pub.
• The file containing the authorized keys is called authorized_keys2 instead of
authorized_keys.
Student Notebook
"0"+

9$ &

>
Y
9
' ^_ 9

#
^
Y

9 9

$$ 9

X $$3< 49
X $$ 9
X $$$3< 49
Figure 5-12. Protecting Your Private Key LX243.0
Notes:
As we've seen in the previous visuals, with RSA and DSA authentication can be performed
using a public/private key pair instead of with passwords. This method has several
advantages, but there is one big disadvantage: Anyone who is able to use your private key
is able to login to any of your accounts. Because of this, you should always
password-protect your private keys.
This leads to another disadvantage though: You need to type that same password every
time you need that private key. For this problem, a solution has been created too in the
form of the ssh-agent client-side daemon.
The ssh-agent client-side daemon retains all unlocked private keys in its memory space,
and activates them when one of its client processes needs them. This means that the
ssh-agent has to be started as the parent process of all shells and other programs that
make use of it.

V3.0
Student Notebook
Uempty There are basically two methods of starting ssh-agent:

• First, you can start ssh-agent in a regular shell with the command ssh-agent bash.
This will start ssh-agent, and will start a bash shell as its child. Any commands typed in
this shell will, if necessary, use ssh-agent.
• Second, you can integrate ssh-agent in your X-Windows startup scripts. How this is
done depends slightly on how the distribution starts X, but generally requires you to
modify your .Xclients or .Xclients-defaults file. In this file you will typically find a line like
this:
exec startkde
If you replace this line with the following line, then ssh-agent will be started early
enough in the X Windows start sequence that all X clients (including your xterms) will be
able to use it:
ssh-agent startkde
When ssh-agent has been started properly, you also need to unlock and upload your
private keys. This is done with the ssh-add command.
The ssh-add command without any options or arguments asks for the passphrase of
$HOME/.ssh/identity, $HOME/.ssh/id_rsa and/or $/.ssh/id_dsa to unlock them, and then
uploads them to the ssh-agent daemon. If your private key is stored in another file, you can
specify this file too.
The -l option to ssh-add shows all currently retained keys, and the -d option deletes keys.
Note: It is important to consider the security of every workstation or server where you
unlock your private key using this method: If you go on a coffee break without locking
(using vlock, xlock or similar mechanisms) your system, anybody passing by has access to
any system you have access to.
Student Notebook
775"9$
@

##

]`

]`
=="9$
Figure 5-13. SSH X Forwarding LX243.0
Notes:
If it is properly enabled, then the SSH protocol allows various streams of data to be
encrypted simultaneously within one SSH connection. A really useful example of this is X
forwarding.
With X forwarding, all X traffic which is generated on the SSH server is sent through the
SSH tunnel to the ssh client, and then sent to the local X server. This allows you to run an
X application on the server, while looking at its output on the client. Obviously this is
possible without SSH as well, but SSH takes care of the following three things:
• SSH automatically extracts, transfers and merges your MIT Magic Cookie. This means
that X authentication is automatically handled.
• SSH makes sure that your $DISPLAY variable is set correctly.
• SSH encrypts the traffic, so nobody with a sniffer is able to see what you’re doing.
The way X forwarding is handled is as follows:
• When the sshd daemon receives an ssh client request which also requests X
forwarding (this is the default), it opens an extra port on localhost with port number

V3.0
Student Notebook
Uempty 6010. This port number is deliberate: The X server and its X clients use TCP port 6000
for X display :0, port 6001 for X display :1, and so forth. As a result, port 6010 is used
when you use X display :10. Only, in this case, the connection does not arrive at an
actual X server, but at the sshd daemon, who encrypts and forwards the traffic to the
ssh client.
Obviously, if port 6010 is already in use, then sshd will use 6011, and so forth.
• The user logs in normally, but the sshd daemon also sets the $DISPLAY variable to
localhost:10.0. This ensures that all X applications that are started by the user have
their X output directed to sshd.
• Any X traffic that is forwarded through the SSH tunnel to the ssh client is sent to the
local X server, as if ssh is actually the local X client.
Note that X traffic is not particularly efficient: all mouse and keyboard events have to be
encrypted and sent through the tunnel to the sshd daemon, and all graphical output has to
be encrypted and sent back. This might generate a lot of traffic, depending on the actual X
application in use. For instance xeyes will generate about 50 packages per second...
Student Notebook
775B
##$Y&$Y]&

\ ""
"""
~
^
X

X^ 3 " "43" 43"
"43<9 4
]
^
X

X^ %3""43 " 43 "
"43<9 4
Figure 5-14. SSH Tunneling LX243.0
Notes:
SSH also allows us to set up our own tunnels, which can then be used to encrypt arbitrary
TCP connections. This is typically used to encrypt protocols that do not have encryption by
default, or to access servers behind a firewall.
The most often used variant of this is a “forward” tunnel. In this case, you ensure that a
local port (a port on your local client system) is opened, and all traffic is forwarded via the
SSH tunnel to an arbitrary host and port. This host on the other side of the tunnel can either
be the firewall itself, or a system accessible from the firewall.
The other variant is a “reverse” tunnel, where you ensure that a port is opened on the
firewall. All traffic that connects to this port is forwarded back to your local system via the
SSH tunnel, and then forwarded to a system and port that is accessible from your local
system.

V3.0
Student Notebook
Uempty
7759 8" $"
##

+

##

+

^
4>44444
$%&!4%$7$.&644
%%42>++" 9
4>
4
44%$7$.&644
%%444
$%&!42>++" 9
Figure 5-15. SSH Firewall Considerations LX243.0
Notes:
Obviously, after installing and configuring sshd on the firewall, we need to open up the
firewall to allow incoming connections on port 22, the sshd port.
Student Notebook
8!"] "

" @

J
" ##
9J
" @ ##
J
" @ $]#9 &J
6" @
9

J
" @

9

J
Notes:
1.
2.
3.
4.
5.
6.

V3.0
Student Notebook
Uempty
7
\

*

*

\##

9 9
#

^""
^" "
~
##
^

^
^ Y 9
$$^ Y9
$^Y
Notes:
Student Notebook

V3.0
Student Notebook
Uempty Unit 6. Socks Service

This unit describes the concepts and implementation of a Socks server
on Linux

• Describe Socks service concepts
• Name socks servers for Linux
• Install and Configure the Dante socks server

Accountability:
© Copyright IBM Corp. 2000, 2003 Unit 6. Socks Service 6-1

Student Notebook

' #9
_9

'9
Notes:

V3.0
Student Notebook
Uempty
7"! """
]~
9 "
~ `

"
#9

"
"""^ #9 #

"""^Y"""^ """^Y"""^
""" """ """

"""

Figure 6-2. Socks Protocol LX243.0
Notes:
The socks protocol is an IETF standard, defined in RFC 1928. It works as follows:
• The client starts a TCP connection to the socks server, usually to port 1080.
• The first data on this TCP connection is the IP address and the port number of the
server and service to connect to.
• The socks server then sets up a TCP connection to this IP address and port number.
• Once this connection is established, the socks server passes all data back and forth
between the two connections.
Two different versions of the socks protocol exist: socks version 4 and socks version 5. The
only real difference between the two is that socks version 5 allows for the use of user
authentication.

Student Notebook
$ $; $
^
\Y^
#_
\

{9 {

*
^
' ^
'9 X'
'9 +
<9 ^ '_#

7 _\
Figure 6-3. Advantages and Disadvantages LX243.0
Notes:
There are several advantages to this protocol:
• This protocol is TCP aware. That means that this protocol only works if a complete TCP
connection can be set up. This makes this protocol invulnerable to, for instance, IP
address spoofing, SYN spoofing and so forth.
• The connection is completely transparent after it has been set up. This means that
basically any application which uses TCP can use the socks server. In fact, it is possible
to "socksify" your entire TCP/IP stack and then the connection is completely transparent
even in the connection setup phase.
• Very comprehensive logging is possible.
• It is very secure: the socks server can be configured only to listen on the internal
interface, making it completely impossible for a hacker to connect to port 1080.
There are some disadvantages as well:
• It does not work well with UDP. With a few magic tricks it is possible to configure the
socks server to use UDP. The UDP protocol is stateless however, making it extremely

V3.0
Student Notebook
Uempty hard for the socks server to guess when the "connection" has finished and the allocated
resources (like a port number) can be freed.
• It does not work at all with ICMP. This means that for instance trying to ping a server
which does not respond is impossible.
• The client has to be able to obtain the IP address of the server, most likely through
DNS. This means that the firewall has to be configured to allow DNS queries through
the firewall.
• In general, a socks server will be a little slower than a NAT router.

Student Notebook
7"! 7
_#9^ ^"9""
<
]
'^ ^" "
~ #9
9
\9^ ^
" 9
'
+"""
Figure 6-4. Linux Socks Servers LX243.0
Notes:
There are at least two socks servers available for Linux.
The first one is the Nec Socks server, which is the reference implementation of a socks
server for all operating systems. It works fairly well but has a very restrictive license.
The second one is the Dante socks server, which is a free (GPLed) reimplementation of the
Nec socks server, specific for Linux. It also comes with some code to socksify your client
applications. This is the socks server we will be implementing.
A lightweight alternative to Dante is tsocks, which is an open source project on
sourceforge. tsocks can only handle TCP connections, and has no functionality for
socksifying your applications.
The socks protocol is really simple. That's why a lot of people chose to implement a socks
server just for fun, practice or some other reason. Because of this, a lot of different socks
servers are available. For a more complete listing, go to http://www.freshmeat.org and do a
search for "socks server".

V3.0
Student Notebook
Uempty
;
"$8"<"
' ^
$# #
<#""#$
$$
#"<<J#
!
!!
!
_^'
$

]+ ^
$$
Figure 6-5. Dante Installation and Configuration LX243.0
Notes:
The implementation of Dante is completely straightforward. What is useful is that Dante
also comes with a dante.spec file. This allows you to create a binary RPM with a single
command.

Student Notebook
7 ## "!$"<

!
?

!$$
$7=

!%$7$.&6=

!
)

!
)

!

)

!.9

!7&9

+

!$%&
!: $%&

!
?

/-
/ 3

!
!$%67

/

!

>
3

!$%&
!$%&

!

Figure 6-6. Sample /etc/sockd.conf LX243.0
Notes:
This is the /etc/sockd.conf file. It is fairly straightforward, and there are manual pages
available as well.
One thing that might need explaining is the "client pass" and "pass" statement. The Dante
socks server configuration file makes a distinction between the incoming connection (from
the client) and the outgoing connection (to the server). Both can be configured fairly
extensively. In our situation were are allowing connections from all incoming stations to
everywhere, that's why the stanza's are near-exact duplicates of each other.

V3.0
Student Notebook
Uempty
7$7" "!$
# 9

/

/

/

/

/

/

/

/
Figure 6-7. Starting and Stopping sockd LX243.0
Notes:
After installing, sockd can be started and stopped as any other daemon, and can be started
at boot time by running chkconfig dante on.

Student Notebook
7"! < "

!
\X'{9 {
!
\X'

9

^9"

!
!$%&!

!
!!$$
$7

!

!
/&
/

!

! ^

/

\9
^

?, "?=>,
/

Figure 6-8. Socksifying Applications LX243.0
Notes:
One of the advantages of the socks protocol is that it is protocol-independent. This
basically means that every application that sets up outgoing TCP or UDP connections can
be socksified, that is, made to work through a socks server instead of making direct
connections.
To set this up, you first need to configure the socks configuration file /etc/socks.conf. This
file is pretty basic. It specifies the socks server to use, what socks protocol (socksv4,
socksv5 or mssocks) to use, whether the socks server supports TCP and/or UDP, which
connections can be made directly instead of going through the socks server, and how to do
name resolution (if the client cannot do that itself).
To socksify applications, you just start the application with a wrapper program called
"socksify". This wrapper program will intercept all network traffic and send it through the
socks server if necessary.
An even better trick is by using the shared library loader. All programs that make use of
shared libraries (and most Linux applications will), can be socksified by simply loading the
libdsocks library when the application starts. This is achieved by setting the

V3.0
Student Notebook
Uempty $LD_PRELOAD variable. (Note: This apparently does not work for setuid/setgid
applications.)

Student Notebook
8!"] "

" 9 9J
" @
9 J
" @ 9
J
"
'9J
Notes:
1.
2.
3.
4.

V3.0
Student Notebook
Uempty
7
\9
9
\

\9

\
9
^
_!'\9
'
Notes:

Student Notebook

V3.0
Student Notebook
Uempty Unit 7. Proxy Service

This unit describes the concepts and configuration of a proxy server
on Linux.

• Describe Proxy Service concepts
• List advantages and disadvantages of proxies
• Name proxy servers for Linux
• Configure Apache for proxy service
• Install and Configure the Squid proxy server

Accountability:
© Copyright IBM Corp. 2000, 2003 Unit 7. Proxy Service 7-1

Student Notebook

'

_

#`

Notes:

V3.0
Student Notebook
Uempty
""""
]~
"
~ `
X]

"
7!\ ^""" 7!\ #

"""^Y"""^ """^Y"""^
""" """ """

"""

Figure 7-2. Proxy Protocol LX243.0
Notes:
The proxy protocol is an official IETF standard. It is described as part of RFC 2616.
It works roughly as follows:
• The client makes a connection to the proxy server, usually port 8080.
• The client sends his request to the proxy server in the form of an HTTP request, even if
the file requested is to be downloaded using FTP. The client can also specify other
HTTP options.
• The proxy server then fulfils this request and retrieves the data. This can be done using
the HTTP, HTTPS, FTP, WAIS or Gopher protocols.
• The data is then sent to the client as the result of the HTTP query.

Student Notebook
$ $; $
^
'_#9

*

*

Q
$

&
Q
Q
Q

' ^
<9
7_\
Figure 7-3. Advantages and Disadvantages LX243.0
Notes:
There are several advantages to the proxy protocol:
• The proxy server can do the DNS lookup. This means that it is not necessary to
implement DNS across the firewall.
• The proxy server can be configured to do very granular logging, to the level of which
user downloaded which web page from which server at what time, how big the web
page was, what type of page it was and so forth.
• The access control is very granular. One could for instance disable the loading of all
Java applets through the proxy.
• The proxy can do transparent caching. This greatly reduces the required bandwidth and
speeds up response times for pages that are retrieved often but change very little over
time.

V3.0
Student Notebook
Uempty As always, there are disadvantages too:

• The proxy protocol only works for specific protocols. Should a new protocol arise then
you need to add this functionality to your proxy server before clients can use it.
• A proxy is generally slower than NAT, for requests that are not cached on the proxy
server. If the requested data is already available on the proxy server and does not need
to be retrieved from the Internet, the perceived performance goes up.

Student Notebook
"7
^ ^" "
+

#
\\~\

*

]

#`
^ ^`
""
\\~\

*

#
$&

]

\#~ \9 $ ^" "&
*
~\ """
Figure 7-4. Linux Proxy Servers LX243.0
Notes:
There are multiple proxy solutions available for Linux:
The Apache web server, which has a market share of about 60%, has proxy functionality
built in, through the use of the mod_proxy module. This is very useful if you are already
using Apache and want to add proxy capabilities to your system.
The Squid proxy server supports the proxy function only. It can be configured very
extensively. A nice feature for large organizations (with multiple firewalls) is that it supports
the ICP (Internet Cache Protocol), with which proxy servers can inform each other as to
what they have cached. Should a proxy server receive a request for a certain page which it
does not have cached, it can then redirect the client to a proxy server which has that page
cached.
The TIS firewall toolkit contains various tools that can be used on a firewall, including a
number of proxy servers for various protocols. Among the protocols supported is telnet,
FTP, gopher, WAIS, HTTP and a number of others.

V3.0
Student Notebook
Uempty
8"<<""7
" "^
?$$!77
?
0

>0

: 0

3=
,

!;
=5

,

>

$%&
,

: 0

" "^

?$$!77
?
0

: 0

3=

;
=5

,

>

$%&

: 0

Figure 7-5. Configuring Apache for Proxy Service LX243.0
Notes:
The visual shows an extract of the /etc/httpd/conf/httpd.conf file for both Apache version 1.x
and 2.x in which the proxy service of Apache is enabled. The most important statement is
"ProxyRequests On". This enables the proxy functionality of Apache. The other statements
are just there to configure it in the right way.

Student Notebook

>8"<$77$
#`
^
$
#`
`
"$
&
##`

$
$
Figure 7-6. Installing, Configuring and Starting Squid LX243.0
Notes:
Squid is part of most distributions, so you can install it as any other RPM. The only thing
you need to do is change the config file.

V3.0
Student Notebook
Uempty
## $"<

$$!77

70-
3$$%

3

3

3

$%%%

3

3

Figure 7-7. /etc/squid.conf LX243.0
Notes:
The visual shows a very dressed down version of the squid config file. The squid RPM
comes with a sample config file with a truckload of comments in it, and I advise you to use
this file and make changes to it. However, that file did not fit the visual...
The options above are the most important options that need to be set for a simple proxy
configuration.

Student Notebook
7G B>7"! >"
_\ #9

+`

_ _
J
# ~ # #
9 \
$

&
J _ _ X

>

9
@ J \X'+ \X' '

\
'_#9
J #
\ 9 _

J 9

"
Figure 7-8. Summary Visual: NAT, Socks, Proxies LX243.0
Notes:
We've seen that there's basically three methods of allowing our internal users access to the
outside network: Network Address Translation (in particular, IP Masquerading), Socks
servers and Proxy servers.
This visual sums up the most important differences between the three solutions. As such, it
does not really belong to the proxy unit, but it would be silly to make a separate unit for it...
The first difference lies in the protocol independence: Where NAT and socks work for every
current and future protocol that uses TCP and/or UDP, a proxy server does not. If a new
protocol is invented, a new proxy server needs to be written for it. This means that you will
usually have to run a separate proxy server for each of the protocols that you will want to
allow over your firewall.1
The second difference is speed. Because the overhead is minimal, NAT will usually be
perceived as the fastest solution, with socks coming in as second best. In reality, the
differences are no more than a few percent though.
1
Fortunately, most HTTP proxies support FTP as well.

V3.0
Student Notebook
Uempty Another difference is the amount and detail of the data that goes into the logfiles. With NAT,
you can only log on IP packet level: Each IP packet transmitted gets its own line in the log
files. This is generally not detailed enough to do anything useful with. With a socks server,
individual TCP connections can be logged, with source and destination ports. With proxies,
application specific data can be logged, such as (for HTTP connections) the filename
retrieved, the mime-type, and the user who retrieved it.
A fourth difference is whether the solution supports caching. This is only possible for
proxies, if the application supports it. The most common protocols that are handled by
proxies (HTTP and FTP) both allow caching.
A fifth difference is how authorization is performed. With all solutions, authorization (who is
allowed to do what) can be based on the source IP address. With an HTTP proxy,
authorization can also be done on username and password.
Another difference is how the solution is generally implemented. NAT is implemented in the
Linux kernel, while other solutions require additional software to be installed.
Yet another difference is in the protocols that are supported. NAT generally supports TCP,
UDP and ICMP. Socks generally support all protocols that make use of TCP or UDP, and
proxies generally only support TCP-based protocols.
An important difference for the next unit is in the way DNS lookups are handled. With NAT
and socks, the client systems are required to do their own DNS lookups. This means that
DNS requests will somehow have to be allowed over the firewall. With proxies, the proxy
server will generally be able to do the DNS lookup on behalf of the client. This means that
DNS lookups do not have to be performed in your internal network.
The last difference we want to cover here is whether the solution is transparent for the user.
With NAT, a user will have a hard time even figuring out that NAT is being performed. With
socks the solution can also be transparent, if the user uses a socksified TCP/IP stack2 will
not be transparent for the user; they need to be configured for every client application.
2 In Microsoft Windows systems you can create a file socks.cnf which holds the socks configuration and is automatically used by all
applications, if it exists.

Student Notebook
8!"] "

" 9J
" @
J
" @
J
"

J
6"
#`
J
Notes:
1.
2.
3.
4.
5.

V3.0
Student Notebook
Uempty
7
\
$
&
\
X]

\
X]
\

#`

Notes:

Student Notebook

V3.0
Student Notebook
Uempty Unit 8. Securing DNS

This unit describes the considerations and configuration of DNS on a
Linux firewall.

• List DNS considerations on firewalls
• Configure DNS on firewalls

Accountability:
© Copyright IBM Corp. 2000, 2003 Unit 8. Securing DNS 8-1

Student Notebook
Objectives
List DNS consideration on firewalls
Configure DNS on firewalls
Notes:

V3.0
Student Notebook
Uempty
DNS Considerations
Don't give away internal information to internet users
Might be used by hackers
Might contain reserved IP addresses
Allow internal users to retrieve internet DNS information
Needed when using NAT or Socks
Not strictly needed when using Proxies (the proxy
resolves the IP address)
Ensure that regular and reverse DNS queries match
Don't allow dynamic updates
Might be used to insert malicious data
Don't allow large transfers to anybody (e.g. zone transfer,
dig)
Might be used for DoS attacks
Figure 8-2. DNS Considerations LX243.0
Notes:
There are various considerations when setting up DNS on a firewall.
The biggest consideration is not to give away internal information to Internet users.
Hackers may use this information to figure out what the internal network looks like and
what servers are good candidates for attacking. Even if it is not a hacker who retrieves the
information, the information may be worthless anyway, since it may contain reserved IP
addresses which are not routable on the Internet.
Another consideration is that in most cases internal users need to retrieve Internet DNS
information, for instance because you are using socks or NAT.
Something which is becoming extremely important nowadays is that the regular and
reverse DNS queries have to match exactly. To verify that a certain incoming connection is
not spoofed, most services to an reverse DNS lookup on the incoming IP address, followed
by a regular DNS lookup on the hostname. This should then yield the same IP address as
the one coming in. If for some reason there is no match or no resolution, the connection is
refused1.

Student Notebook
Some DNS servers support dynamic updates, for instance because DHCP is used in
combination with a static hostname per machine. When a DNS server supports this, and is
not secured properly, it is possible to poison the DNS tables with false entries. These can
then be used to attack sites which authenticate hosts based on their hostname.
The last consideration is not to allow large transfers (for instance zone transfers), except to
the secondary DNS server. These transfers can be used for DoS attacks.
1
This is important to remember when distributing IP addresses from a DHCP server. If clients which have a direct connection to the
Internet are assigned such dynamic addresses, there are basically two solutions:
• These clients get assigned a dynamic hostname too, using the DHCP hostname option, and there is a static relation between IP
address and DNS hostname.
• These clients get to use their own hostname, and need to update the DNS server themselves or through the DHCP server. This is
called Dynamic DNS (DDNS). In effect, there is a static relation between the MAC address and the hostname, with a dynamic IP
address in between. It is possible to secure this sufficiently, but it is usually not worth the trouble.

V3.0
Student Notebook
Uempty
DNS Name Considerations
One name registration:
www.acme.com: internet server
w3.acme.com: intranet server
One registration, two domains:
www.intranet.acme.com: intranet server
Two registrations:
www.acme.net: intranet server
Made-up Top-Level Domain (TLD)
www.servers.acme: intranet server
Figure 8-3. DNS Name Considerations LX243.0
Notes:
A special consideration is the DNS name you are going to use and the hostname scheme
that goes with it. DNS was never designed to be used in a firewall situation, so nearly every
solution will have its own drawbacks.
One possibility is to use one name registration, like acme.com. Every host in your DMZ and
Intranet gets a name in that domain, with the hostname identifying whether this is an
Internet or Intranet host. For instance, w3.acme.com is your Intranet host, and
www.acme.com is your Internet host.
This scheme can be extended a bit with a subdomain for the Intranet, like
intranet.acme.com. This is a little more typing for your employees when they want to
connect to an Intranet host (remember every server on the Intranet will be called
something.intranet.acme.com...) but makes the distinction between Intranet and Internet
hosts clearer2.
2 If the single hostnames of Intranet and Internet servers do not overlap, you could consider adding a search statement for the Internet
domain to all /etc/resolv.conf files. Users can then use the hostname w3, which resolves to w3.intranet.acme.com, and www, which
resolves to www.acme.com

Student Notebook
Another possibility is to try and get two name registrations, like acme.com and acme.net.
One is used for the Internet, the other is used for the Intranet.
The last possibility is to create your own Top-Level Domain and use that as the Intranet
domain name. This is technically possible, as long as you make sure that this TDL never
leaks to the Internet, for instance in the return address of an e-mail message.

V3.0
Student Notebook
Uempty
DNS Servers
Authoritative for the DMZ
DMZ Packet The Internet

DNS Filtering
Server DMZ Router
Packet
Filtering
Router
Authoritative for the intranet and DMZ

Forwards internet queries to DMZ DNS Server
Company Network Intranet

DNS
Server
Figure 8-4. DNS Servers LX243.0
Notes:
On the visual you can see where the DNS servers have been placed. The visual is not
completely accurate, since the Internet requires you to have at least two separate DNS
servers (one primary, one secondary) which serve your domain.
Anyway, what you will most likely need is two sets of DNS servers: one set (primary,
secondary) on the DMZ, serving the needs of the Internet. These servers are authoritative
for the DMZ, meaning that they contain all the hostnames and IP addresses of all servers
on the DMZ. They answer requests from the Internet. Additionally, they answer requests
from the servers on the DMZ, and forward the request to an Internet root name server if
necessary. They don't have any information on Intranet hosts.
The Intranet hosts are authoritative for the Intranet at the very least. They can answer
queries for the Intranet, and forward all other queries to the DMZ DNS servers.
There is one point to note here. If the Intranet uses the same domain name as the DMZ (as
was the case in the first example on the previous visual), then you've got a little problem.
Since the Intranet DNS servers are then authoritative for the acme.com domain, when they
get an Intranet client query for www.acme.com, they will say that this server does not exist.

Student Notebook
This is because a name server will never forward a query for a domain for which it is
authoritative to another name server.
The solution is simple but rather awkward: both the DMZ DNS servers and the Intranet
DNS servers should be authoritative for the DMZ. This basically means that all the
information that is added to the DMZ DNS servers should also be added to the Intranet
DNS servers.
A completely different situation arises when you have a firewall-in-a-box. In this case you
can actually use Split-DNS, where you effectively run two DNS servers in one box. One
acts as the DMZ DNS server, answering queries from the DMZ/Internet side, and the other
acts as the Intranet DNS server. This requires you to run two separate DNS server
programs, each running on port 53, but each binding to a specific interface so they don't
interfere with each other. Setting this up is not covered in this course.

V3.0
Student Notebook
Uempty
Scenario (DMZ Situation)
www.acme.com
DMZ
Sec. DNS Company
Server Webserver
bar.acme.com
foo.acme.com 62.186.134.71 62.186.134.20
DMZ Packet The Internet

Pr. DNS DMZ Filtering
Server 62.186.134.0/24 Router
62.186.134.70 62.186.134.1
ftp.acme.com 62.186.134.2
Packet
Company
Filtering
FTP server
Router
10.0.0.1
62.186.134.21
w3.acme.com widget.acme.com
Intranet Company Network 10.0.0.40
Webserver 10.0.0.0/24 Intranet
DNS
10.0.0.60 Server
Figure 8-5. Scenario (DMZ Situation) LX243.0
Notes:
This scenario will be used in the next few visuals. Note that we are running two DNS
servers on our DMZ. This is an IANA requirement. In fact, if at all possible you are required
to place them on separate subnets, each with its own connection to the Internet.
Unfortunately, this is not always feasible. Most ISPs though will run your secondary DNS
server on their servers for a small fee.
Furthermore, we are running a web server and an ftp server on our DMZ, and we are
running a web server on the Intranet.

Student Notebook
Internet Primary DNS Server Config File

# cat /etc/named.conf
// Internet DNS server for acme.com
options {
directory "/var/named";
};
zone "." {
type hint;
file "named.ca";
};
zone "acme.com" {
type master;
file "named.acme.com";
allow-update { none; };
allow-transfer { 62.186.134.71; };
};
zone "134.186.62.in-addr.arpa" {
type master;
file "named.62.186.134";
allow-transfer { 62.186.134.71; };
};
Figure 8-6. Internet Primary DNS Server Config File LX243.0
Notes:
In the visual you will see the config file of the Internet/DMZ DNS server. As you can see, it
serves the acme.com and 134.186.62.in-addr.arpa domains, and uses the hints section to
point to the root DNS servers on the Internet. Zone transfers are only allowed to
62.186.134.71, the secondary DNS server.

V3.0
Student Notebook
Uempty
Internet Primary DNS Server Name Zone File
# cat /var/named/named.acme.com
$TTL 86400
@ IN SOA foo.acme.com. webmaster.acme.com. (
2001120100 ;Serial
28800 ;Refresh
14400 ;Retry
3600000 ;Expire
86400 ;Default TTL
)
@ IN NS foo.acme.com.
@ IN NS bar.acme.com.
foo IN A 62.186.134.70
bar IN A 62.186.134.71
www IN A 62.186.134.20
ftp IN A 62.186.134.21
Figure 8-7. Internet Primary DNS Server Name Zone File LX243.0
Notes:
The visual displays the name zone file for the Internet DNS server. This DNS server is
authoritative for the acme.com domain which, as far as the Internet is concerned, consists
of all servers on the DMZ. No Intranet hosts are listed here.

Student Notebook
Internet Primary DNS Server IP Zone File
# cat /var/named/named.62.186.134
$TTL 86400
@ IN SOA foo.acme.com. webmaster.acme.com. (
2001120100 ;Serial
28800 ;Refresh
14400 ;Retry
3600000 ;Expire
86400 ;Default TTL
)
@ IN NS foo.acme.com.
@ IN NS bar.acme.com.
70 IN PTR foo.acme.com.
71 IN PTR bar.acme.com.
20 IN PTR www.acme.com.
21 IN PTR ftp.acme.com.
Figure 8-8. Internet Primary DNS Server IP Zone File LX243.0
Notes:
The visual shows the IP zone file for the Internet DNS server. Only hosts in the
62.186.134.* network are listed with their corresponding name.

V3.0
Student Notebook
Uempty
Internet Secondary DNS Server Config File
// Internet DNS server for acme.com
options {
};
zone "." {
type hint;
file "named.ca";
};
zone "acme.com" {
type slave; masters { 62.186.134.70; };
file "named.acme.com.bak";
allow-transfer { none; };
};
type slave; masters { 62.186.134.70; };
file "named.62.186.134.bak";
allow-transfer { none; };
};
Figure 8-9. Internet Secondary DNS Server Config File LX243.0
Notes:
The secondary DNS needs to import its files from the primary DNS. Obviously it may not
export them again to other hosts.

Student Notebook
Intranet DNS Server Config File
// Intranet DNS server for acme.com
options {
forward only;
forwarders { 62.186.134.70; 62.186.134.71; };
};
zone "acme.com" {
type master;
file "named.acme.com";
};
type master;
file "named.10.0.0";
};
Figure 8-10. Intranet DNS Server Config File LX243.0
Notes:
The Intranet DNS server cannot reach the root DNS servers on the Internet directly. That's
why it will use forwarders: DNS servers who will resolve the query for it. In our case the
forwarders are the DNS servers on the DMZ.
In addition to that, this DNS server is authoritative for the Intranet.

V3.0
Student Notebook
Uempty
Intranet DNS Server Name Zone File
$TTL 86400
@ IN SOA widget.acme.com. webmaster.acme.com. (
2001120100 ;Serial
28800 ;Refresh
14400 ;Retry
3600000 ;Expire
86400 ;Default TTL
)
@ IN NS widget.acme.com.
router1-dmz IN A 62.186.134.1
router2-dmz IN A 62.186.134.2
foo IN A 62.186.134.70
bar IN A 62.186.134.71
www IN A 62.186.134.20
ftp IN A 62.186.134.21
router2-int IN A 10.0.0.1
w3 IN A 10.0.0.60
widget IN A 10.0.0.40
Figure 8-11. Intranet DNS Server Name Zone File LX243.0
Notes:
This is the most intriguing file of the whole setup. The Intranet DNS server is authoritative
for the whole acme.com domain, both the DMZ and the Intranet. That means that both
networks need to be listed in this very file. And obviously the DMZ part of the file needs to
be exactly the same as the file on the DMZ DNS.

Student Notebook
Intranet DNS Server IP Zone File
# cat /var/named/named.10.0.0
$TTL 86400
@ IN SOA widget.acme.com. webmaster.acme.com. (
2001120100 ;Serial
28800 ;Refresh
14400 ;Retry
3600000 ;Expire
86400 ;Default TTL
)
@ IN NS widget.acme.com.
1 IN PTR router2-int.acme.com.
40 IN PTR widget.acme.com.
60 IN PTR w3.acme.com.
Figure 8-12. Intranet DNS Server IP Zone File LX243.0
Notes:
Since the Intranet uses another address range as the DMZ, we don't have that overlap
problem here. The IP zone file therefore is completely straightforward and listed here only
for completeness.

V3.0
Student Notebook
Uempty
DNS Query Resolving
Intranet client:
Client asks widget
widget forwards query to foo or bar for internet queries
foo or bar resolve query on internet
DMZ client:
Client asks foo or bar
foo or bar resolve query on internet
For intranet queries: store in /etc/hosts
Internet client:
Client asks foo or bar
foo or bar answer query
Figure 8-13. DNS Query Resolving LX243.0
Notes:
This visual shows the different servers that are involved in the different queries that are
possible.

Student Notebook
DNS Packet Characteristics

Regular client -> Server DNS query
Initially done through UDP, source port > 1023,
destination port 53
If fails done through TCP, source port > 1023,
destination port 53
Server -> Server DNS query
Initially done through UDP, source port 53, destination
port 53 (Bind 8.1: source port >1023)
If fails done through TCP, source port > 1023,
destination port 53
Server -> Server zone transfer
Only done through TCP, source port > 1023,
destination port 53
Figure 8-14. DNS Packet Characteristics LX243.0
Notes:
Listed in the visual are the DNS packet characteristics. What you should remember is that
DNS can use either UDP or TCP, and that port 53 is always used as server port and
sometimes as client port too (in case of a DNS server running bind 4 or lower).

V3.0
Student Notebook
Uempty
DNS iptables Rules
On the DNS server itself:
# iptables -A INPUT -i ppp0 -p tcp -s any/0 -d 62.186.134.70 --dport 53 -j ACCEPT

# iptables -A OUTPUT -o ppp0 -p tcp -s 62.186.134.70 --sport 53 -d any/0 -j ACCEPT
# iptables -A INPUT -i ppp0 -p udp -s any/0 -d 62.186.134.70 --dport 53 -j ACCEPT
# iptables -A OUTPUT -o ppp0 -p udp -s 62.186.134.70 --sport 53 -d any/0 -j ACCEPT
On a router:
# iptables -A FORWARD -i ppp0 -p tcp -s any/0 -d 62.186.134.70 --dport 53 -j ACCEPT
# iptables -A FORWARD -i ppp1 -p tcp -s 62.186.134.70 --sport 53 -d any/0 -j ACCEPT
# iptables -A FORWARD -i ppp0 -p udp -s any/0 -d 62.186.134.70 --dport 53 -j ACCEPT
# iptables -A FORWARD -i ppp1 -p udp -s 62.186.134.70 --sport 53 -d any/0 -j ACCEPT
# iptables -A FORWARD -i ppp0 -p tcp -s any/0 -d 62.186.134.71 --dport 53 -j ACCEPT
# iptables -A FORWARD -i ppp1 -p tcp -s 62.186.134.71 --sport 53 -d any/0 -j ACCEPT
# iptables -A FORWARD -i ppp0 -p udp -s any/0 -d 62.186.134.71 --dport 53 -j ACCEPT
# iptables -A FORWARD -i ppp1 -p udp -s 62.186.134.71 --sport 53 -d any/0 -j ACCEPT
Figure 8-15. DNS iptables Rules LX243.0
Notes:
These are the iptables rules that are needed generally to allow DNS queries and responses
to reach the correct destination.

Student Notebook
1. What are considerations when configuring DNS on a
firewall?
2. Do you need to be able to resolve internet DNS queries
on the intranet?
3. Where do you place your DNS servers?
4. Which DNS server has which information?
5. What DNS servers are used, in which order, to resolve
different client queries?
Notes:
1.
2.
3.
4.
5.

V3.0
Student Notebook
Uempty
Summary
If you are using NAT or socks, Intranet clients need to be
able to resolve DNS queries on the Internet
Internet clients need to be able to resolve DNS queries
for hosts on the DMZ
The usual configuration consists of at least two DNS
servers on the DMZ, and at least one DNS server on the
Intranet
The Intranet DMZ server(s) forward all Internet queries to
the DMZ DNS servers
The DMZ DNS servers are configured to give away as
little information as possible
Notes:

Student Notebook

V3.0
Student Notebook
Uempty Unit 9. Securing E-mail

This unit describes the considerations and configuration of an E-mail
server on Linux.

• List E-mail considerations
• List different MTA programs for Linux
• Configure Sendmail on a firewall
• Discuss a number of checks that can be performed on incoming
and outgoing E-mail

Accountability:
© Copyright IBM Corp. 2000, 2003 Unit 9. Securing E-mail 9-1

Student Notebook
Objectives
List E-mail considerations
List different MTA programs for Linux
Configure Sendmail on a firewall
Discuss a number of checks that can be performed on
incoming and outgoing E-mail
Notes:

V3.0
Student Notebook
Uempty
E-mail Considerations
Allow internal users to send e-mail to internet users
Allow internet users to send e-mail to internal users
Don't give away internal information
Don't allow your server to be used as a relay
Block messages that are too large
Block incoming junk email (spam)
Block messages with viruses
Block dangerous attachments
Figure 9-2. E-mail Considerations LX243.0
Notes:
Setting up e-mail on a firewall is a little bit more tricky than setting up e-mail for internal use
only. Here are some considerations that you should keep in mind:
• You need to allow internal users to send e-mail to Internet users and vice versa.
Obviously, you also need internal users to be able to send e-mail to other internal users,
but that is something which is usually already handled by the internal mail server.
• You will not want to give away internal information, such as userids, hostnames and so
forth.
• You should not allow Internet users to use your mail server as a mail relay to send
e-mail to other Internet users. Using sites as a relay is done mostly by spammers who
can use this to disguise their identity.
• You might want to block messages that are larger than a certain limit.
• You might want to block incoming junk e-mail, also known as spam.
• You might want to check every incoming and outgoing e-mail message for viruses. (This
will consume a large amount of CPU time however.)
• You might want to block certain dangerous attachments.

Student Notebook
Mail Gateway and Mail Server
Packet The Internet

Filtering
DMZ Router
Mail
Gateway Packet
Filtering
Router
Mail
Server Client
SMTP
POP/IMAP
Company Network
Figure 9-3. Mail Gateway and Mail Server LX243.0
Notes:
The example in the visual is the typical example of a mail environment setup. There is an
Intranet mail server which stores and handles all the e-mail for the Intranet users. Users
use this server to initially send their e-mail to and retrieve it from this server as well, usually
through the POP or IMAP protocol. Mail that shouldn't be delivered locally is sent to a mail
gateway on the DMZ. The mail gateway on the DMZ receives mail from the Intranet and
forwards it to the appropriate host on the Internet. Additionally, it receives mail from the
Internet and forwards it (after performing various checks) to the Intranet server.
Note that no internal client ever talks to the DMZ mail relay. The only server the mail clients
talk to is the mail server on the Intranet.

V3.0
Student Notebook
Uempty
Mail Servers for Linux
Sendmail (http://www.sendmail.org)
Traditional implementation
70% market share
Large security history
Very flexible
Available by default in Red Hat Linux
Postfix (http://www.postfix.org)
Developed as a secure replacement for Sendmail
Well thought out
Default in SuSE Linux
Qmail (http://www.qmail.org)
Developed as a secure replacement for Sendmail
Modular design
GNU Public License
Exim (http://www.exim.org)
Figure 9-4. Mail Servers for Linux LX243.0
Notes:
There are at least four mail gateway programs available for Linux: Sendmail, Postfix, Qmail
and Exim.
Sendmail is the oldest of the four. It runs on roughly 70% of the mail servers on the Internet.
This is reason for the people who wrote Sendmail to claim that virtually every e-mail that is
sent over the Internet is somehow handled by Sendmail. And they are probably right.
Sendmail has a number of problems though. The main source of problems is that the
program itself is one big monolithic program which has to run with root permissions1.
Having a next-to-impossible-to-understand configuration file doesn't help either.
It is for this reason that Sendmail has suffered from a large number of security problems.
The first real security incident on the Internet (the Morris Worm) was actually caused by a
Sendmail misconfiguration. Sendmail is getting better though, and as long as you keep
using the latest version and keep up to date using the various mailing lists, you can assume
to be reasonably safe.
1
Only recently was Sendmail changed so that it can as a non-root user too.

Student Notebook
Certain people on the Internet did not like Sendmail despite all the effort that had gone into
securing it. They developed alternatives to Sendmail which have a completely different
design and are inherently more secure. These alternatives are Qmail and Postfix.
Both Qmail and Postfix were explicitly developed as secure alternatives to Sendmail,
correcting all the mistakes that Sendmail has (according to the developers):
• Multiple small, independent programs that do not have to run with root permission.
• Easy to understand configuration files.
• Easy to maintain directory structures.
• Easy to understand log messages.
Qmail and Postfix are direct (but friendly) competitors to each other. They share a large
number of design characteristics and certain components are interchangeable. It is not
unlikely that they will eventually merge into one product.
The last alternative mentioned here is Exim. It does not have a large market share and not
much functionality (for instance, it cannot handle UUCP), but is a good alternative if you
just need a simple TCP/IP based mail server.

V3.0
Student Notebook
Uempty
Configuring Sendmail as Mail Gateway
Allow relaying of email to/from acme.com domain
cd /etc/mail
vi access
Add: acme.com RELAY
vi mailertable
Add: acme.com smtp:mail.acme.com
make
Allow connections via all interfaces
vi /etc/sendmail.mc
dnl DAEMON_OPTIONS(‘Port=smtp,
Addr=127.0.0.1, Name=MTA’)
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Restart Sendmail
service sendmail restart
Figure 9-5. Configuring Sendmail as Mail Gateway LX243.0
Notes:
The visual shows the different steps you need to take to configure sendmail as a mail
gateway:
• Sendmail by default is set up not to relay any e-mail. It can only receive e-mail from its
own domain. This domain is normally set up to contain "localhost" only. To allow
Sendmail to relay e-mail to and from a larger domain, this domain has to be added to
the file /etc/mail/access, with the RELAY tag behind it.
After that, you need to specify the mail server to forward the e-mail for this domain to.
This is specified in the /etc/mail/mailertable file. Note that the name used here is an
Intranet server. Since we are on the DMZ ourselves, we need to be able to resolve this
name to its IP address. This can be done by adding the name to /etc/hosts.
Alternatively, you can also specify the IP address of the mail server here.
After editing /etc/mail/access and /etc/mail/mailertable, you need to create the access
and mailertable database. This is done by running the make command in the /etc/mail
directory.

Student Notebook
• Another change you might need to make is to comment out any DaemonPortOptions
line in your sendmail.cf. This line is typically used by distribution manufacturers to
configure sendmail to only listen to the loopback device. You can edit the sendmail.cf
file directly, but since we will be making far more complicated sendmail.cf changes later,
we’re going to use sendmail.mc to generate the sendmail.cf file in this unit. You
therefore need to make changes to the sendmail.mc file, which is then used to create
your sendmail.cf file.
After making these changes, restart Sendmail.

V3.0
Student Notebook
Uempty
Configuring Postfix as Mail Relay
Allow relaying of mail to/from acme.com domain
cd /etc/postfix
vi access
Add: acme.com OK
postmap access
vi transport
Add: acme.com smtp:mail.acme.com
postmap transport
vi main.cf
myhostname = mailrelay.acme.com
mydomain = acme.com
myorigin = $mydomain
inet_interfaces = all
mynetworks = 192.168.1.0/24
relay_domains = $mydestination, $mydomain
rcpostfix restart
Figure 9-6. Configuring Postfix as Mail Relay LX243.0
Notes:
Setting up a Postfix mail relay is basically the same as setting up a Sendmail relay, in the
sense that both programs need the same information to work properly. You need to accept
mail from the inside network and relay it to the outside, and need to accept mail from the
outside which has a destination in the internal network.
Configuring all this in Postfix is a little easier than in Sendmail though. All that’s needed is:
• A few changes in the main.cf file, mainly identifying your own hostname and domain
name.
• A list of internal domains in the access file, so that the server knows that mail from/to
these domains can be relayed
• A pointer to the internal mail server in the transports file. Again, this mail server has to
be either a resolvable DNS name, or an IP address.

Student Notebook
Configuring Sendmail as Mail Server

Add local domain and smart relay info to config file:
vi /etc/mail/sendmail.mc
MASQUERADE_DOMAIN(team1.com)
define(‘SMART_HOST’, ‘mailrelay.acme.com’)
dnl DAEMON_OPTIONS(‘Port=smtp,
Addr=127.0.0.1, Name=MTA’)
Add local domain names to /etc/mail/local-host-names
Allow mail relaying from clients to clients in this domain:
vi /etc/mail/access
Add: acme.com RELAY
make
service sendmail restart
Enable POP3 server
chkconfig ipop3 on
Add local users
Figure 9-7. Configuring Sendmail as Mail Server LX243.0
Notes:
Setting up the mail server is not very hard either. There are a few things to change in the
sendmail.cf file:
• The server needs to know that it should deliver mail for our domain locally instead of
trying to pass it on to another mail server. This is done by adding our own domain name
to the Cw class, or to the /etc/mail/local-host-names file.
• The server needs to set the domain name on outgoing e-mail to our own domain name.
This will ensure that when a recipient hits the reply button, the correct e-mail address
will be used. Setting the domain name is done in the Dj definition or, when using
sendmail.mc, the MASQUERADE_DOMAIN configuration option.
• Since Sendmail cannot contact mail servers on the Internet directly, it needs to know
that it needs to use a Smart Relay. This is configured with the DS option or, when using
sendmail.mc, the SMART_HOST configuration option.
• And as with the mail relay, your distribution might have added a DaemonPortOptions
line to bind sendmail to the loopback interface only. Comment out this line.

V3.0
Student Notebook
Uempty Furthermore, the mail server needs to be able to relay mail for the local domain, originating
from remote clients to other clients on the network. That's why you need to add the local
domainname to /etc/mail/access with the RELAY statement, and then run make in the
/etc/mail directory to update the access.db database.
Additionally, you might need to configure the mail server so that users can actually retrieve
their e-mail from that server through the POP3 or IMAP protocols. For this to work, you
need to have the xinetd daemon installed and running, and you need to install the pop3
and/or imap daemons. Also don't forget to enable POP3 and/or IMAP in the xinetd
configuration files.
And the last thing you need to do is to add user accounts for each e-mail user to your
system.

Student Notebook
Configuring Postfix as Mail Server

Add local domain and gateway info to config file
vi /etc/postfix/main.cf
myhostname = mail.acme.com
mydomain = acme.com
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, $mydomain
relayhost = fw.team1.com
Allow relaying from local clients:
vi /etc/postfix/access
acme.com RELAY
Restart Postfix
rcpostfix restart
Allow POP3
chkconfig qpopper on
Figure 9-8. Configuring Postfix as Mail Server LX243.0
Notes:
Again, Postfix needs about the same information as Sendmail in order to function as a local
mail server:
• The local hostname and domain name, so that mail is masqueraded properly, and that
mail with a local destination is stored locally.
• The name (or IP address) of the smart relay, to which all outgoing mail is relayed.
• A line that allows communication via all interfaces.
• The list of local domains that this server is allowed to relay for.
Restart Postfix after configuring all this, and enable POP3 and/or IMAP.

V3.0
Student Notebook
Uempty
Configuring DNS for Mail Relaying
DMZ DNS MX records should point to the mail relay
.
@ IN MX 10 mailrelay.acme.com.
.
mailrelay IN A 62.186.134.80
.
Intranet DNS MX record should point to the mail server
.
@ IN MX 10 mail.acme.com
.
mail IN A 10.0.0.80
.
Figure 9-9. Configuring DNS for Mail Relaying LX243.0
Notes:
An e-mail message is always sent to someone@somedomain, not to
someone@somehost. But you cannot send something to a domain, can you?
The SMTP protocol works together with the DNS protocol to resolve this dilemma. In the
DNS tables, every domain is supposed to have one or more MX records. These MX
records identify the mail exchanger for a certain domain. If multiple MX records are present
then the one with the lowest value after the MX identifier has preference. Others will only
be used if the preferred one cannot be contacted.
This is the place where our two DNS servers come in handy. We can configure the DNS
server on the DMZ so that all messages coming from the Internet are sent to the mail relay.
Simultaneously, we configure the DNS server on the Intranet so that all messages are sent
to the mail server. The mail server has a smart relay statement so all non-Intranet mail is
sent to the mail gateway.

Student Notebook
Limiting Message Size

Sendmail: Configure MAX_MESSAGE_SIZE in
sendmail.mc
vi /etc/mail/sendmail.mc
define(‘confMAX_MESSAGE_SIZE’, ‘50000’)
Postfix: Set message_size_limit in main.cf
vi /etc/postfix/main.cf
message_size_limit = 50000
Figure 9-10. Limiting Message Size LX243.0
Notes:
Limiting message size is very easy.
For Sendmail, you need to make sure that the MaxMessageSize option is specified in
sendmail.cf. Again, this can be done directly, but if you take the m4 route, you need to add
the MAX_MESSAGE_SIZE configuration option to sendmail.mc.
For Postfix, all you need to do is set the message_size_limit.

V3.0
Student Notebook
Uempty
Blocking Junk E-mail (Spam)
Add spamming domain to /etc/mail/access or
/etc/postfix/access with keyword:
REJECT: Bounces messages as undeliverable
OK: Allow from this subdomain even if another rule
prevents receiving mail from the higher-level domain.
DENY (Sendmail) or DISCARD (Postfix): Discard
message, don't send anything back
### Error Message: Bounce messages with a custom
error number and message (similar to REJECT)
localhost.localdomain RELAY
localhost RELAY
127.0.0.1 RELAY
acme.com RELAY
cracker.org REJECT
spammer.org DISCARD
good.spammer.org OK
badsmtp.org 500 Bad SMTP spoken by you
Figure 9-11. Blocking Junk E-mail (Spam) LX243.0
Notes:
If you receive a lot of unwanted e-mail (spam) from a single domain, you can block these
domains by adding them to the access file. Both Sendmail and Postfix use such an access
file, and the syntax is comparable.
REJECT means that the message is bounced back to the sender as being undeliverable.
OK means accept the message even if another rule rejects or denies it. This is useful if you
don't want to accept messages from a large domain, but do want to accept messages from
a particular subdomain.
DENY (Sendmail) or DISCARD (Postfix) is very useful with regards to spam. It discards the
message but does not send anything back to the sender. The sender will therefore think
that the message was delivered ok.
You can also customize your own error messages by specifying the number to be used and
a custom message.

Student Notebook
SpamAssassin
Evaluates message using various criteria to determine
"spam score"
If spam score is too high, message is spam and marked
as such (subject or other header fields)
Can use Bayesian filtering too
Learns what spam is from past messages classified
manually as such
Two modes:
Invoke every time (inefficient)
Run as daemon with lightweight client
Invocation:
By MTA using milter interface (Sendmail) or external
filter (Postfix)
By procmail
Figure 9-12. SpamAssassin LX243.0
Notes:
SpamAssassin is a program that looks at the actual message content, and determines,
based on a number of characteristics, the “spam score”. There are a lot of characteristics,
including:
• Uppercase words and lines
• Presence of URLs in the message
• Presence of 0-800 numbers (US toll-free numbers) in the message
• Presence of words which typically occur in today’s spam (“Viagra”, “Mortgage”, ...)
All scores are added, and if the message gets a spam score above a user-defined
threshold, it is marked as spam. Depending on the settings, this might be indicated in the
subject line itself, or as an additional SMTP header. The user can then use these headers
to manually or automatically filter spam out. Depending on the local UA, this requires a
.procmail file or various filter rules in the users mail program.
SpamAssassin also incorporates a “Bayesian Filter”: a program which can be trained to
recognize spam. This works as follows:

V3.0
Student Notebook
Uempty 1. For a month or so, don’t delete spam but collect it in a separate mail folder (file on disk).
Also collect all regular non-spam mail in a separate mail folder (file on disk).
2. Feed these two files to sa-learn, so that SpamAssassin can apply Bayesian statistics to
learn what spam is.
3. Run SpamAssassin normally, with the Bayesian filter enabled. Spam is now also
classified based on these statistics.
SpamAssassin is written in perl, a high-level scripting language. It is really powerful, but
one of the disadvantages is that it takes quite a while for the perl interpreter to load and
precompile a perl script. If you’ve got hundreds of mail messages per second going through
your mail server, you are not going to keep up because of this.
In order to alleviate this problem, you can run SpamAssassin as a daemon too. In this
case, the (heavyweight) perl daemon is started only once, and is kept running at all times.
In addition to this, there is a lightweight spamc client, written in C (which is far more
efficient in starting up), which just sends the message to the spamd for evaluation. This
scheme, although harder to configure, saves a tremendous amount of CPU time.
SpamAssassin obviously needs to be integrated in your e-mail system. This can generally
be done in two ways:
• Both Sendmail and Postfix have a mechanism that allows external programs (filters) to
be invoked as part of the message handling process. For Sendmail, this mechanism is
the “milter” interface, and for Postfix, you need to configure an external filter. These
mechanisms allow you to check all mail, including mail that is being relayed.
• When delivering mail locally, both Sendmail and Postfix invoke a local delivery agent,
typically procmail. Procmail is able to invoke external programs such as
SpamAssassin. This is fairly easy to set up, and can even be done on a per-user basis
by the users themselves. The disadvantage is that this does not work on a mail relay.

Student Notebook
Installing SpamAssassin
Install spamc/spamd client/server pair, start and test
daemon
Included in most distributions as RPM
Sendmail: Install spamass-milter and activate milter
interface in sendmail.mc:
INPUT_MAIL_FILTER(‘spamassassin’, ‘S=local:/var/run/spamass.sock,
F=, T=C:15m;s:4m;R:4m;E:10m’)dnl
define(‘confMILTER_MACROS_CONNECT’, ‘b, j, _, {daemon_name},
{if_name}, {if_addr}’)
Postfix: Create postfixfilter which calls spamc and then

reinjects message in Postfix; then modify main.cf to use
postfixfilter:
smtp inet n - n - - smtpd -o content_filter=spamfilter
spamfilter unix - n n - - pipe flags=Rq argv=/usr/bin/postfixfilter -f ${sender}
-- ${recipient}
Figure 9-13. Installing SpamAssassin LX243.0
Notes:
SpamAssassin is included in most distributions, including Red Hat and SuSE, by default.
The RPM typically contains three programs:
• spamassassin, which is the stand-alone spam filter.
• spamc, which is the lightweight spam client.
• spamd, which is the heavyweight spam daemon.
Depending on your needs, you are either going to use the standalone spamassassin, or
using the spam client and daemon.
After installing SpamAssassin, test out the product with the supplied sample-spam.txt and
sample-nonspam.txt files, and start the daemon, if necessary.
If you are using Sendmail, then the next step is configuring the milter interface to
SpamAssassin. For this you need an add-on product “spamass-milter”. This program
creates a UNIX socket (a file in your filesystem by which two programs can communicate),
with which it communicates with the Sendmail daemon through the use of the milter API.
When it receives a message through this socket, it sends it (by means of the spamc

V3.0
Student Notebook
Uempty program) to the SpamAssassin daemon. The modified message is then send back to
Sendmail. Spamass-milter can be downloaded from
http://savannah.nongnu.org/projects/spamass-milt.
The next step is to configure Sendmail to use Spamass-milter. This is most easily done by
adding the following lines to your sendmail.mc file, and then generating the sendmail.cf file:
INPUT_MAIL_FILTER(‘spamassassin’, ‘S=local:/var/run/spamass.sock, F=, T=C:15m;s:4m;R:4m;E:10m’)
define(‘confMILTER_MACROS_CONNECT’, ‘b, j, _, {daemon_name}, {if_name}, {if_addr}’)
For Postfix users, you need to create a small program which receives a mail message from
stdin, sends it through spamc, and then reinjects the results back into the Postfix message
stream. This program will look like this:
#!/bin/bash
/usr/bin/spamc | /usr/sbin/sendmail -i "$@"
exit $?
You also need to modify the master.cf file (which is the file which controls the Postfix
message flow) to include this external filter, after receiving the message via smtp. This is
done by defining a new content filter "spamfilter":
spamfilter unix - n n - - pipe
flags=Rq argv=/usr/bin/postfixfilter -f ${sender} -- ${recipient}
The spamfilter is then invoked by modifying the smtp line:
smtp inet n - n - - smtpd -o content_filter=spamfilter
When this is done, and Postfix is restarted, spam filtering should be enabled.

Student Notebook
Real-Time Blacklisting
Real-Time Blacklisting:
List of known spammers at vix.com (and other sites)
Accessible through DNS hack:
If hostname 196.197.198.199.rbl.maps.vix.com exists,
199.198.197.196 is a known spammer
More information on http://maps.vix.com/rbl
Figure 9-14. Real-Time Blacklisting LX243.0
Notes:
The last defence against spam is real-time blacklisting. This works as follows:
• People from all around the world watch their inbox for spam.
• They trace back the e-mail to the origin, and retrieve the IP address of this origin.
• This IP address is sent to the administrators at vix.com, who add it to a modified DNS
database.
• This DNS database can then be used to verify that incoming e-mail is not originating
from a known spammer. Say for instance that your mail software receives an e-mail
originating from 199.198.197.196. Your mail software can then to a DNS lookup on the
hostname 196.197.198.199.rbl.maps.vix.com. If this hostname exists, then that IP
address is a known spammer and the e-mail message should be discarded.
Sendmail and Postfix can both be configured to support real-time blacklisting. The
instructions for this are listed on http://maps.vix.com/rbl.

V3.0
Student Notebook
Uempty
Detecting Viruses in Attachments
AMaViS (A Mail Virus Scanner)
http://amavis.org
Detaches all attachments (uncompresses if necessary)
Uses a separate virus scanner to scan attachments
20+ commercial virus scanners supported
If virus found, deletes message & send e-mail to sender,
recipient and/or administrator
Two modes:
Invoke every time (inefficient)
Run as daemon with lightweight client
Invokation:
By MTA using milter interface (Sendmail) or external
filter (Postfix) (always)
By procmail (only when delivering mail locally)
Figure 9-15. Detecting Viruses in Attachments LX243.0
Notes:
A very useful feature to introduce in your e-mail configuration is the possibility to check for
viruses in e-mail attachments.
The program that makes this possible is called AMaViS. It basically works as follows:
• AMaViS receives every e-mail message that passes through your mail relay and
detaches all attachments in a secure directory. It even uncompresses and untars them
if necessary.
• It then calls a separate virus scanner to scan the body of the message and the
attachments for viruses. AMaViS supports a number of commercial virus scanners
which are available for Linux. If multiple virus scanners are installed it will actually use
them all in turn.
• If the virus scanner detects a virus, the message is deleted (actually, stored in a special
directory, out of reach from anybody except root), and a warning is sent both to the
sender, the recipient and the system administrator.
• If no virus is found, delivery of the message is continued.

Student Notebook
AMaViS is written in perl, just like SpamAssassin, and suffers from the same drawbacks: a
large number of required perl modules, and a slow startup. The large number of perl
modules is something you need to solve when installing AMaViS with help of CPAN, the
Comprehensive Perl Archive Network. This allows you to install perl modules automatically.
Furthermore, AMaViS also supports a client/server mode, where the heavyweight perl
program runs continuously, and a lightweight client (written in C) is started for each and
every message.

V3.0
Student Notebook
Uempty
Installing AMaViS
Install a commercial virus scanner
Install amavisd
Required a large number of perl modules which might
not be included with your distribution
Requires various decompress utilities
Sendmail: Add milter interface for AMaViS:
INPUT_MAIL_FILTER(‘milter-amavis’,
‘S=local:/var/amavis/amavis-milter.sock, F=T, T=S:10m;R:10m;E:10m’)dnl
Postfix: Add AMaViS as external filter (before

SpamAssassin):
smtp inet n - n - - smtpd -o content_filter=vscan
vscan unix - n n - 10 pipe user=vscan argv=/usr/sbin/amavis ${sender}
${recipient}
localhost:10025 inet n - n - - smtpd -o content_filter=spamfilter
Test setup with eicar.com test file
Figure 9-16. Installing AMaViS LX243.0
Notes:
AMaViS does not scan for viruses itself. Instead, it requires a regular (commercial) virus
scanner for that. Virus scanners today are without exception commercial products,
because the staff to check new viruses and keep the virus database up to date is
expensive.
Once your virus scanner is operational, you can start installing AMaViS. This is fairly
straightforward until you reach the stage where you need to install various perl modules.
Not every distribution (particularly Red Hat) includes all the required perl modules by
default, and in that case you can use the CPAN network to install these modules. This is
done by invoking the command perl -MCPAN -e shell, and then executing various install
commands to download and install these modules from CPAN.
An important sidenote in this respect: The default settings for the $LANG shell variable on
a Red Hagt system are incompatible with CPAN. In order for this to work correctly, you
need an export LANG=en_US before you run this command.

Student Notebook
Also, AMaViS requires a large number of decompress utilities, including arc, zoo and
others. If these are not installed on your system by default, you need to fake their
existence, for instance by setting up a symlink to gunzip.
When installing AMaViS, make sure you use the configuration option --enable-milter if
you’re using Sendmail. This enables the milter interface.
When AMaViS is installed and configured, you need to integrate this in your MTA. Just as
with SpamAssassin, this requires the definition of a milter in Sendmail, or an external mail
filter in Postfix. You can then restart your MTA an test things out.
Obviously, you’re not going to test things with a "live" virus. Instead, we’re going to use a
special file that is completely harmless but which virus scanner manufacturers have agreed
upon to include in their virus definition files anyway. This file, eicar.com, can be
downloaded from http://www.eicar.org. (EICAR is the European Institute for Computer
Anti-Virus Research.)

V3.0
Student Notebook
Uempty
SMTP Firewall Rules
Allow incoming connections to port 25 (SMTP):
# iptables -A INPUT -i ppp0 -p tcp -s any/0 -d 62.186.134.70 \

--dport 25 -j ACCEPT
# iptables -A OUTPUT -o ppp0 -p tcp -s 62.186.134.70 --sport 25 \
-d any/0 -j ACCEPT
Figure 9-17. SMTP Firewall Rules LX243.0
Notes:
The last thing we need to do is to configure the SMTP firewall rules. This basically comes
down to allowing incoming and outgoing traffic to and from port 25.

Student Notebook
1. Which E-mail servers are available for Linux?
2. Name some considerations of E-mail on a firewall.
3. Name some checks you can have performed
automatically on incoming and outgoing E-mail.
Notes:
1.
2.
3.

V3.0
Student Notebook
Uempty
Summary
There are several e-mail servers available for Linux:
Sendmail
Qmail
Postfix
All these programs can be used as a mail relay on a
firewall
All these programs can be extended to reject spam,
check for viruses, reject messages that are too large and
so forth
Notes:

Student Notebook

V3.0
Student Notebook
Uempty Unit 10. Virtual Private Networks

This unit describes the configuration of Virtual Private Networks on a
Linux firewall.

• Describe Virtual Private Networks concepts
• List different VPN protocols
• List different VPN solutions for Linux
• Install, configure FreeS/WAN

Accountability:
© Copyright IBM Corp. 2000, 2003 Unit 10. Virtual Private Networks 10-1
Student Notebook
Objectives
Describe Virtual Private Networks concepts
List different VPN protocols
List different VPN solutions for Linux
Install, configure FreeS/WAN
Notes:

V3.0
Student Notebook
Uempty
Virtual Private Networks Concepts
Packet The Internet

Filtering
DMZ Router
Packet Tunneling
Filtering Device
Router Firewall
with
Client
Tunneling
Company Network Customer Network

Intranet
Server
Figure 10-2. Virtual Private Networks Concepts LX243.0
Notes:
A Virtual Private Network is the name of a technique to connect two private networks
(Intranets) through each other using the Internet or another non-private network. Privacy is
guaranteed however by using strong encryption, and all this is completely transparent to
the users of these networks. Virtual Private Networks are sometimes also called Extranets.
Student Notebook
Virtual Private Network Solutions

PPP over telnet or ssh
PPTP (Point to Point Tunneling Protocol)
IETF Standard (RFC 2637)
PPP over IP
PAP, CHAP authentication
RC4 encryption (max 128 bits)
Supported in Microsoft Windows 95/98/NT/2000
IPSec (IP Security Protocol)
IETF Standard (RFC 2411)
IP encapsulated over IP
Integral part of IPv6, ported back to IPv4
Encryption, Authentication, Integrity protection, Replay
protection, Non-repudiation
Key management protocol
Widely supported
Figure 10-3. Virtual Private Network Solutions LX243.0
Notes:
VPNs are beginning to become very popular these days. A number of organizations and
individuals have been working on creating VPN solutions, and the visual describes some of
them.
The first solution is by setting up a telnet or ssh connection and running a PPP connection
over it. This is useful if your firewall administrator only allows telnet or ssh access to the
outside world but you want full-fledged connectivity. In fact, a mini-"how to" has been
written just about this topic. PPP over telnet, ssh or whatever (even DNS queries have
been used as transport medium...) is not a standard however. An example of such a VPN is
described at
http://www.uni-erlangen.de/docs/RRZE/dezentral/unix/linux/HOWTOS/mini/VPN.html.
Another protocol that has gained ground is the PPTP protocol. This solution is basically
PPP over IP, with all the authentication and encryption handled by PPP. PPTP is supported
in nearly all Microsoft Windows products starting with Windows 95 and this is the reason
that it is fairly popular. It has a number of security flaws though. These essentially come
from the fact that PPTP was not designed as a secure protocol from the start on, but just

V3.0
Student Notebook
Uempty designed to do PPP tunneling over IP. Security was added as an afterthought by Microsoft
using MS-CHAP. And their implementation was not very good. For a discussion about
PPTP and the inherent weaknesses see
http://kubarb.phsx.ukans.edu/~tbird/vpn/FAQ.html#Q6: and
http://www.counterpane.com/pptp-faq.html. There is an implementation of PPTP for Linux
though: PoPToP. It can be downloaded from
http://www.moretonbay.com/vpn/download_pptp.html.
The last solution is IPSec. IPSec is a fairly new set of protocols which are an integral part of
IPv6, but have been backported to IPv4. It is more difficult to set up but is inherently safer
than PPTP.
Student Notebook
IPSec Overview
RFC 2411 (Documentation Roadmap)
Uses three subprotocols
IKE (Internet Key Exchange)
ESP (Encapsulation Security Protocol)
Authentication and Encryption
AH (Authentication Header)
Only Authentication
Uses any encryption algorithm that is available
(automatic negotiation at startup)
Allows two modes:
Transport mode: host-to-host
Tunneling mode: router-to-router
Figure 10-4. IPSec Overview LX243.0
Notes:
IPSec consists of a number of subprotocols:
• The IKE protocol is a protocol that runs on top of UDP and is used for things like key
exchange and session configurations.
• The ESP protocol is a protocol that runs on top of IP and is used for sending encrypted
and authenticated data.
• The AH protocol is also a protocol that runs on top of IP and is used for sending
authenticated but unencrypted data.
In a typical configuration you will choose either to use AH or ESP, depending on your
needs. In fact, you can use both: AH for less sensitive data and ESP for sensitive data.
Authentication and encryption is done using any encryption protocol that is available to
both sides of the connection. The actual protocol that is used is negotiated at session
startup. The IPSec standards specify a small number of protocols that need to be
supported at the very least so that a match is always possible.
IPSec allows for two modes of communication: transport and tunneling mode.

V3.0
Student Notebook
Uempty
IPSec Modes
H1 H2
Transport mode: host-to-host security
H1 R1 R2 H2
Tunnel mode: router-to-router security
Figure 10-5. IPSec Modes LX243.0
Notes:
With transport mode, the host that generates the data is the one that encrypts the data as
well. Similarly, the host that unencrypts the data is the recipient as well.
With tunneling mode, the hosts that send or receive the data are not necessarily the ones
that encrypt and decrypt the data. This mode is primarily used for creating VPNs.
The difference may seem arbitrary at first glance, but is rather substantial: With tunneling
mode it is mandatory to encrypt the IP header as well, and to add another IP header. This is
not the case in transport mode.
Student Notebook
Authentication Header Protocol (AH)

Integrity checking
Authentication through MD5 or SHA
Protocol number 51
Regular IP packet: IP Header IP Payload
IP packet, transport: IP Header AH Header IP Payload
IP packet,
IP Header AH Header IP Header IP Payload
tunneled:
Figure 10-6. Authentication Header Protocol (AH) LX243.0
Notes:
The AH protocol ensures that the data that is received is the same data that was sent by
the sender. This is called integrity checking. The data is not encrypted however. For this
integrity checking the IPSec protocol specifies that at least the MD5 and SHA protocols
need to be supported. Other protocols may be supported too. AH uses IP protocol number
51.
You can clearly see the difference between transport and tunneling mode here. In transport
mode, an AH header is inserted between the IP header and the data and that's it. In tunnel
mode however, the IP header is left intact and a new IP header is prepended to the packet.

V3.0
Student Notebook
Uempty
Encapsulating Security Payload (ESP)
Integrity checking
Authentication through MD5 or SHA
Encryption through DES, 3DES, CDMF
Protocol number 50
Regular IP packet: IP Header IP Payload
IP packet, transport: IP Header ESP Header IP Payload (encrypted)
IP packet, IP Header
IP Header ESP Header IP Payload (encrypted)
tunneled: (encrypted)
Figure 10-7. Encapsulating Security Payload (ESP) LX243.0
Notes:
With ESP, the same considerations as with AH arise. The only thing added is encryption.
Here, the IPSec documentation specifies that an implementation of IPSec should at least
support DES1, 3DES and CDMF. ESP will always be done in combination with
authentication, since accepting encrypted data without knowing who it's from is like using
stolen foreign secrets that you found scribbled on the restroom wall...
1
DES is no longer considered secure enough for data communication because of the limited key size, and is therefore usually disabled.
Student Notebook
Internet Key Exchange (IKE)

Uses UDP/IP as transport protocol
UDP Port 500 on both sides
Automated connection setup between two IPSec hosts
Initial phase: cleartext
Negotiate session key using Diffie-Hellman
Rest of communication is encrypted
Automated negotiation of Security Associations
Unique, one-way session between two IPSec systems
Need two SA's for two-way communication
Automated refresh of cryptographic keys
Figure 10-8. Internet Key Exchange (IKE) LX243.0
Notes:
The IKE protocol manages all AH and ESP sessions. It uses UDP/IP as the transport
protocol and is usually started automatically when a host starts.
The IKE uses an elaborate session setup to ensure that all IKE communication is
encrypted too, with session keys being generated in a secure manner using the
Diffie-Hellman protocol.
After IKE session setup, the IKE protocol is used to negotiate the setup of Security
Associations. Every SA is basically one AH or ESP session. Note that an SA is a one-way
session: a regular AH or ESP session needs at least two SAs to function.
The last thing IKE does is the regular refresh of cryptographic keys. This effectively
protects against replay attacks.

V3.0
Student Notebook
Uempty
FreeS/WAN
http://www.freeswan.org
Open Source implementation of IPSec for Linux
GNU Public License
Components:
Klips: Kernel IPSec patches
Pluto: Key negotiation daemon
Various utilities
Config files:
/etc/ipsec.conf
/etc/ipsec.secrets
Figure 10-9. FreeS/WAN LX243.0
Notes:
FreeS/WAN is an Open Source (GPLed) implementation of IPSec for Linux. It has three
main components:
• Klips, which is a large number of kernel patches for the Linux kernel. This adds IPSec
and encryption capabilities to the kernel. These patches cannot be part of the regular
kernel tree: US export restrictions would not allow the export of the Linux kernel2.
• Pluto, the key negotiation daemon. This daemon runs in user space and negotiates
keys with other IPSec hosts.
• Various utilities for key generation and so forth.
FreeS/Wan is configured using two configuration files:
• /etc/ipsec.conf, which contains information about the sessions that can be set up.
• /etc/ipsec.secrets, which contains various keys for various sessions and hosts.
2
US Laws recently changed to the effect that encryption software is no longer considered a munition. Certain export rules still apply
though. For more information, see http://www.whitehouse.gov/OMB/legislative/sap/2000/HR2086-h.html.
Student Notebook
Installing FreeS/WAN from Source

Make sure you have a working /usr/src/linux/.config
# cd /usr/src/linux
# cp configs/kernel-version-arch.config .config
# make oldconfig
Unpack and build FreeS/WAN executables

# cd /usr/src
# tar -zxvf /root/freeswan-version.tar.gz
# cd freeswan-version
# make programs
# make install
Insert FreeS/WAN patches in kernel and recompile

# make insert
# cd /usr/src/linux
# make menuconfig
# vi Makefile (change EXTRAVERSION)
# make dep clean bzImage modules
etc...
# reboot
Figure 10-10. Installing FreeS/WAN from Source LX243.0
Notes:
Implementing FreeS/WAN is one of the hardest tasks in this whole course, since it requires
a kernel recompilation. It will therefore also be one of the lengthiest ones.
Before you patch your kernel with the freeswan patches, make sure that you have a
working .config file for your kernel source tree. You can create one yourself, but you can
also use the appropriate config file for your system from the configs directory3.
The next step is then to unpack the freeswan package and build the FreeS/WAN binaries.
This is fairly straightforward.
Then we get to the hard part. This part requires you to insert the patches into the Linux
kernel source tree, and to rebuild the kernel. It is absolutely vital to run the make
menuconfig command, as else the kernel patches won't be activated. Then, make the
kernel in the usual manner.
3
In this directory Red Hat stores the various config files that were used to build the various kernel images on the installation CD-ROM.

V3.0
Student Notebook
Uempty
Installing FreeS/WAN (Red Hat/SuSE)
The FreeS/WAN team creates RPMs for Red Hat and
makes these available on http://www.freeswan.org
freeswan-userland.rpm: Userland programs, init
scripts, ...
freeswan-modules.rpm: Kernel modules
Need to copy the correct ipsec.o-arch module to
ipsec.o
RPMs are created for each Red Hat version, kernel,
architecture
SuSE integrates FreeS/WAN by default in their
distribution
Kernel module is compiled into each kernel
Userland programs: freeswan.rpm
Figure 10-11. Installing FreeS/WAN (Red Hat/SuSE) LX243.0
Notes:
If you are using Red Hat on your firewall, then you’re lucky. Red Hat is the reference
distribution for the FreeS/WAN team, and the FreeS/WAN team makes RPMs available for
each and every Red Hat version, kernel and architecture. You can find these RPMs on
http://www.freeswan.org.
In order to run FreeS/WAN, you need two RPMs:
• The freeswan-userland-version.rpm contains all the userland programs, scripts,
utilities and so forth.
• The freeswan-modules-version.rpm contains the kernel modules.
A single freeswan-modules RPM will always contain multiple ipsec.o modules, one for
each architecture (i386, i586, i686, various smp variants and so forth) that this particular
kernel version is compiled for. You need to go to the directory
/lib/modules/version/kernel/net/ipsec, and rename the correct ipsec.o-architecture
module to “ipsec.o”. Optionally, you can delete the others. Then, run a depmod -a.
Student Notebook
When downloading these RPMs, you need to be extremely careful in determining which
RPM you need. The RPM version number consists of two parts:
• The FreeS/WAN version, e.g. 2.02
• The Red Hat kernel version that this compile is for, e.g. 2.4.20-18.9
A full RPM name thus will look like this: freeswan-modules-2.02_2.4.20_18.9-0.i386.rpm,
meaning that this RPM contains the FreeS/WAN 2.02 modules, compiled for kernel version
2.4.20-18.9. It’s the first (0) revision of this compile.
If you’re a SuSE user, you’re even more lucky. SuSE has fully integrated FreeS/WAN into
their distribution:
• The ipsec.o kernel module is included with every kernel that SuSE distributes.
• The FreeS/WAN userland modules are included in the form of a freeswan-version.rpm
module.

V3.0
Student Notebook
Uempty
Activating FreeS/WAN
Verify that IP forwarding is on
# cat /proc/sys/net/ipv4/ip_forward
Verify that rp_filter is off

# cat /proc/sys/net/ipv4/conf/all/rp_filter
Verify that Pluto is started automatically

# chkconfig ipsec on
Decide on keying method and authentication method

Add connection information to /etc/ipsec.conf
Add secret keys to /etc/ipsec.secrets
Start ipsec
redhat# service ipsec start
suse# rcipsec start
Figure 10-12. Activating FreeS/WAN LX243.0
Notes:
Configuration of the freeswan environment requires a number of steps.
• Verify that IP forwarding is actually turned on.
• Verify that rp_filter is turned off. This filter is a feature in the Linux kernel that checks
that packets arriving on a certain interface actually should arrive on this interface, by
means of the routing table. If a packet arrives on the “wrong” interface, it is discarded.
This is a security measure against spoofed source IP addresses.
• When using FreeS/WAN however, packets will arrive on the external interface while
they actually should be arriving on the (virtual) ipsec0 interface and thus discarded. For
this reason, rp_filter needs to be disabled when using FreeS/WAN.
• Ensure that the Pluto daemon is started automatically.
• Decide on the keying method and authentication method. This will be covered in the
next visual.
• Add connection information to /etc/ipsec.conf and add secret keys to /etc/ipsec.secrets.
• Start ipsec.
Student Notebook
Session Key Exchange and Authentication
Session Keys
Manually keyed: Automatically keyed:

Session key stored in Session key negotiated and
/etc/ipsec.conf refreshed automatically
(Same on both machines, (Needs authentication)
does not need authentication)
Authentication
Shared secret: Public key (RSA):

Stored in /etc/ipsec.secrets Public keys in /etc/ipsec.conf
(same on both machines) or DNS
Private key in
/etc/ipsec.secrets
Figure 10-13. Session Key Exchange and Authentication LX243.0
Notes:
Each separate session between two IPSec hosts needs a so-called session key. This is a
cryptographic key that is used to encrypt and/or authenticate the data. In fact, if you use
ESP you need encryption and authentication. This is done by different protocols with
different keylengths, so you actually need two keys per SA.
There are basically two ways you can create these keys: manual and automatically.
• When using manual keying, the session keys are stored in /etc/ipsec.conf. These keys
obviously need to be the same on both machines. Also, you need to set the permissions
on this file to 600, so nobody except root can read this file. With manual keying, the
keys stay constant over time, which makes you vulnerable to replay attacks. It also
means that once an intruder has gained your key, he or she can read all the traffic that
has ever been encrypted with that key.
For this reason, manual keying is almost never used. The only reason that you would
want to use this in a production environment is when you need to be able to sniff the
traffic using tcpdump or other tools. tcpdump is able to accept IPSec keys on its
command line and then decrypt traffic that has been encrypted with these keys.

V3.0
Student Notebook
Uempty • Another method is automatic keying. When using this, the keys are negotiated
automatically between both hosts, and they will regularly negotiate new keys, making
you practically invulnerable to replay attacks. It also means that if an intruder gains
access to a session key, he or she is only able to read a limited amount of traffic,
typically only eight hours. However, to use automatically keyed connections, you need
to setup up authentication.
Authentication can be done in two ways too: By using a shared secret and by using public
key authentication methods such as RSA.
• Authentication through a shared secret basically means that a passphrase (a sentence
or something) known to both hosts is stored in /etc/ipsec.secrets (which obviously
should have permissions set to 600 as well). By testing whether the other side knows
the secret in a secure manner (using a challenge-response protocol), the other host is
authenticated.
The shared secret is sometimes also known as a pre-shared secret or pre-shared key.
• Authentication through a public key mechanism is the way to go if you are
communicating between a large number of sites. When using this authentication
method, every host generates a private/public key pair. The private key is stored in
/etc/ipsec.secrets and the public key is published to the whole world. If you want to
setup a connection with another host, you grab the others public key and add it to your
/etc/ipsec.secrets file, or use DNS to look up the key. If the other does the same, you
can authenticate each other and set up an SA. This greatly reduces the management
overhead.
Student Notebook
/etc/ipsec.conf Global Options

version 1.x:
config setup
interfaces="ipsec0=ppp0" Interfaces to use
klipsdebug=none Do not log debug messages
plutodebug=none for klips and pluto
plutoload=%search Search through this file
plutostart=%search for connections to load
and/or start
conn %default Connection defaults
keyingtries=0 Try keying forever
esp=3des-md5-96 Use ESP with 3DES
encryption and MD5
authentication
version 2.x: Use "version 2"; plutoload and plutostart no

longer allowed (default behavior is same as %search)
Figure 10-14. /etc/ipsec.conf Global Options LX243.0
Notes:
The visual shows a number of global options in the /etc/ipsec.conf file. Note that we are
talking about an "ipsec0" interface here. This is one of the things that was added to the
Linux kernel when installing Klips. The ipsec0 interface is a virtual interface which acts like
a PPP connection, connecting you to the other side of a secure IP tunnel.
The klipsdebug and plutodebug parameters specify whether debugging is enabled.
The plutoload and plutostart parameters specify which connections (that are also specified
in this file) to load and to start automatically. In the case above, "%search" means that it
needs to search through the file to identify the connections to load and start.
The "%default" connection specifies defaults that apply to each connection:
• keyingtries=0 means that we try keying (initializing a connection) forever.
• esp=3des-md5-96 means that we use 3DES encryption and MD5 authentication.
There are only a few combinations of encryption and authentication protocols allowed
within the scope of the RFCs. See man ipsec_spi for an overview of them.

V3.0
Student Notebook
Uempty Starting with version 2, some minor changes have been made to the configuration file:
• Each configuration file should contain the stanza “version 2”
• The plutoload and plutostart parameters are no longer allowed: The %search
functionality is now standard.
Student Notebook
/etc/ipsec.conf Manual Keyed Connection

Configure connection information (on both machines):
conn team1-team2
left=62.186.134.70 IP address of "left"
leftsubnet=192.168.1.0/24 Intranet of "left"
#leftnexthop=62.186.134.1
right=62.186.134.71 IP address of "right"
rightsubnet=192.168.2.0/24 Intranet of "right"
#rightnexthop=62.186.134.1
auto=add Load automatically
spi=0x200 Security Parameter Index
espenckey=0x1234567... 192 bit hex 3DES key
espauthkey=0x01234... 128 bit hex MD5 key
To start, run on both machines:

# ipsec manual --up team1-team2
Figure 10-15. /etc/ipsec.conf Manual Keyed Connection LX243.0
Notes:
The visual shows the configuration of a manually keyed connection in the /etc/ipsec.conf
file. Every connection has two parts to it: a "left" part and a "right" part. It does not really
matter which side of the connection is left and right, as long as the same side is called left
in all the ipsec.conf files.
The "left" and "right" options specify the IP address of the router.
The "leftsubnet" and "rightsubnet" specify the subnet that is behind the router.
The "leftnexthop" and "rightnexthop" specify the router that needs to be used as first router
to get data from left to right (right to left, respectively). This looks strange at a first glance,
and it actually is. The reason for this is that AH and ESP traffic bypasses the kernel routing
tables, and this entry is just the replacement for this routing table. If both routers are on the
same subnet (as will be the case in the classroom network), these statements are not
necessary.

V3.0
Student Notebook
Uempty The "auto" option specifies whether this connection should be loaded and/or started
automatically when IPSec is started. (Remember the plutoload and plutostart statements
on the previous visual?)
The "spi" option is the security parameter index. This is a unique value identifying the SA. It
is normally negotiated automatically together with the keys.
The "espenckey" is the 192 bit 3DES key that is used for the encryption in this connection.
It is written in hexadecimal form.
The "espauthkey" is the 128 bit MD5 key that is used for the authentication in this
connection. It is also written in hexadecimal form.
To start the connection, you need to run the ipsec command on both hosts.
Student Notebook
Automatically Negotiated Session Key

Configure connection information (on both machines)
conn team1-team2
left=62.186.134.70 IP address of "left"
leftsubnet=192.168.1.0/24 Intranet of "left"
#leftnexthop=62.186.134.1
right=62.186.134.71 IP address of "right"
rightsubnet=192.168.2.0/24 Intranet of "right"
#rightnexthop=62.186.134.1
auto=add Load automatically
authby=secret Use shared secret
authentication
Configure Authentication
On both machines, run:
# ipsec auto --add team1-team2
# ipsec auto --up team1-team2
Figure 10-16. Automatically Negotiated Session Key LX243.0
Notes:
The visual shows an automatically keyed connection. This is done by removing the spi,
espenckey and espauthkey components from the connection configuration. We do need to
configure authentication in this case, and that is covered in the next visual.

V3.0
Student Notebook
Uempty
Manual Authentication
Add a common secret to both /etc/ipsec.secrets files
Secret can be an arbitrary sentence or a random
number generated with ranbits
The shared secret is sometimes also known as
"passphrase" or "pre-shared key"
62.186.134.70 62.186.134.71 "This is our common secret"
62.186.134.70 62.186.134.72 "0x70b2c76d_f2ds30e9_f9..."
Figure 10-17. Manual Authentication LX243.0
Notes:
Authentication is required when using automatically keyed connections. It can be done in
two ways.
The first way is to use a common secret, also called “shared secret”, “preshared secret”
and “passphrase”. It is either a password or passphrase, or a random number, and is
stored in the /etc/ipsec.secrets file. Both sides should have the same shared secret in their
ipsec.secrets file, and during session setup an elaborate challenge-response protocol is
used to test whether the other side knows the same secret, without actually sending the
secret over the line.
Student Notebook
RSA Public Key Authentication

Generate RSA public/private key pair for each station
# ipsec newhostkey --output /etc/ipsec.secrets
Extract public key and put in other sides /etc/ipsec.conf

# ipsec showhostkey --left # If you are left
# ipsec showhostkey --right # If you are right
Use @hostname as leftid and rightid in /etc/ipsec.conf

/etc/ipsec.conf of left: /etc/ipsec.secrets of left:
conn team1-team2 @fw.team1.com: RSA {
authby=rsasig #pubkey=0sAQOB3aR6V1...
auto=start #IN KEY 0x4200 4 1 AQOB3aR...
left=10.0.0.1 Modulus: 0x81dda47...
leftid=@fw.team1.com PublicExponent: 0x03
leftsubnet=192.168.1.0/24 PrivateExponent: 0x15a4f0b...
leftrsasigkey=0sAQOB3aR6V1... Prime1: 0xcc464225...
right=10.0.0.2 Prime2: 0xa2bff86...
rightid=@fw.team2.com Exponent1: 0x882ed6c...
rightsubnet=192.168.2.0/24 Exponent2: 0x6c7ffaec...
rightrsasigkey=0sAQNruF0ig... Coefficient: 0x3a78add...
}
Figure 10-18. RSA Public Key Authentication LX243.0
Notes:
To set up RSA authentication, each side needs to generate an RSA public/private key pair.
This is done with the following command:
ipsec newhostkey --output /etc/ipsec.secrets
The /etc/ipsec.secrets file now contains the full RSA public/private keypair. The public key
can be extracted from this file using the ipsec showhostkey command, with the --left or
--right option specifying whether you are going to be left or right in the connection.
This public key is then added to the /etc/ipsec.conf file of your partner system. Likewise,
your partner should create a keypair and send you the public part for inclusion in your own
/etc/ipsec.conf file.
Note that FreeS/WAN also requires that your own public key is listed in your own
/etc/ipsec.conf file. This is to ensure that the ipsec.conf stanza can be copied verbatim to
the partner system.

V3.0
Student Notebook
Uempty
Storing Public Keys in DNS
Instead of storing public keys in /etc/ipsec.conf, you can
also store keys in DNS
Advantages:
Easier setup
Easier change procedure of keys
Disadvantages:
Authentication is now dependent on integrity of DNS
server
To setup, extract your own key with ipsec showhostkey
--key and add it to your own leftid/rightid DNS entry
fw.team1.com. IN KEY 0x4200 4 1 AQOB3aR...
Other side can now refer to DNS in /etc/ipsec.conf:

leftid=@fw.team1.com
leftrsasigkey=%dns
Figure 10-19. Storing Public Keys in DNS LX243.0
Notes:
Instead of distributing our public key to all the parties we communicate with, we can also
store our public key in our own DNS server. All the parties that want to communicate with
us can then retrieve the key via the DNS protocol. This is easier to set up, and makes it
easier for us to change our key (for instance, when it has been compromised). The big
disadvantage however is that suddenly we’re now dependent on the integrity of our DNS
server for authentication: If an intruder is able to break into our DNS server, or is able to set
up his own DNS server claiming to be ours, then our partners are trusting the intruder to be
us, and are setting up VPN connections to the intruder. So it’s dependent on your local
security policy whether you want to do this or not4.
If you want to set this up, extract your own key with ipsec showhostkey --key. This gives
you the public key in a format suitable for inclusion in a DNS zone file. Which file this key
should be in depends on the leftid/rightid that is given in the /etc/ipsec.conf file. If this leftid
is of the form @FQDN, then you should add this KEY record to the FQDN in your DNS
4
A fairly new standard to protect DNS integrity is DNSSec. This allows you to verify the integrity of DNS responses using a hierarchical
system of public keys. Not many implementations support DNSSec, and an even smaller number of sites actually use it.
Student Notebook
zone files. If no leftid/rightid is given, then you should add this KEY record to the reverse IP
map for your system.
Once this has been set up, the other side can now add the following line to his
/etc/ipsec.conf file:
leftrsasigkey=%dns
This tells FreeS/WAN to contact the DNS server to retrieve the public key of left.

V3.0
Student Notebook
Uempty
Firewall-to-Firewall and Firewall-to-Subnet
A regular tunnel only allows subnet-to-subnet
communications
For firewall-to-firewall and firewall-to-subnet
communications, set up additional connections without
leftsubnet, rightsubnet or both:
All host-to-host connections are using "transport mode"
conn team1net-team2net conn team1fw-team2net
left=10.0.0.1 left=10.0.0.1
leftsubnet=192.168.1.0/24 right=10.0.0.2
right=10.0.0.2 rightsubnet=192.168.2.0/24
rightsubnet=192.168.2.0/24 ...
...
conn team1net-team2fw conn team1fw-team2fw

left=10.0.0.1 left=10.0.0.1
leftsubnet=192.168.1.0/24 right=10.0.0.2
right=10.0.0.2 ...
...
Figure 10-20. Firewall-to-Firewall and Firewall-to-Subnet LX243.0
Notes:
A VPN connection as we’ve set up so far only encrypts traffic from systems in the leftsubnet
to systems in the rightsubnet and vice versa. It does not encrypt traffic between the firewall
itself and systems in the other subnet5, nor does it encrypt traffic between the firewalls
themselves6.
If you want this traffic to be possible and encrypted, you need to set up firewall-to-subnet
and firewall-to-firewall connections too. Setting this up is fortunately easy: you just copy the
connection description over, give it another connection name and remove the respective
leftsubnet and rightsubnet statements.
If either a leftsubnet or a rightsubnet statement is present in the connection description,
then FreeS/WAN will automatically configure the connection in tunnel mode. But if neither a
leftsubnet nor a rightsubnet is present, then the connection will be set up in transport mode.
5
FreeS/WAN does not set up the routing for this traffic, so it’s impossible to communicate between the firewall and systems in the other
subnet.
6
This traffic is not handled by FreeS/WAN and thus unencrypted.
Student Notebook
Additional IPSec Applications

"Road Warrior"
Scenario where a mobile worker with a dynamic IP
address connects to the "home network" through IPSec
"Opportunistic Encryption"
Scenario where IPSec encryption is applied
automatically if both sides discover that the other side is
supporting this
Authentication via reverse DNS lookup
Figure 10-21. Additional IPSec Applications LX243.0
Notes:
FreeS/WAN and the IPSec standard do not only allow transport and tunneled connections
between two fixed-IP hosts. There’s two more scenarios which may be of interest:
The first interesting scenario is the “Road Warrior” scenario, where a system with a single
IP uses IPSec to connect to his home network to get transparent access. This is used a lot
for mobile workers. The main difference between fixed-IP connections is that the firewall
will not know the IP address of the road warrior system beforehand. It therefore needs to
use the “%any” wildcard.
Here’s the ipsec.conf stanza for the road warrior:
conn roadwarrior
left=%defaultroute # picks up our dynamic IP automatically
leftnexthop=%defaultroute # same for our default router
leftid=@roadwarrior.team1.com
leftrsasigkey=0xAQNruF0ig...
right=10.0.0.1
rightid=@fw.team1.com

V3.0
Student Notebook
Uempty rightsubnet=192.168.1.0/24
rightrsasubkey=0sAQOB3aR6V1...
auto=add # We still need to start manually
And here’s the ipsec.conf stanza for the firewall:
conn roadwarrior
left=10.0.0.1
leftid=@fw.team1.com
leftsubnet=192.168.1.0/24
leftrsasigkey=0sAQ0B3aR6V1...
right=%any # We don’t know the IP beforehand
rightnexthop=%defaultroute
rightid=@roadwarrior.team1.com
rightrsasigkey=0sAQNruF0ig...
auto=add # Connections are started by the other side
Note that we are not being consistent in keeping the same system "left"; instead, we’ve
adopted the convention "left = local, right = remote".
Opportunistic Encryption is an extension to the IPSec standard by the FreeS/WAN team.
This means it’s not supported on other platforms. But it’s so simple, that you wonder why
the IPSec developers didn’t think of it at all.
With Opportunistic Encryption, all systems that support it publish their own public key in
their reverse DNS map. Two items need to be published: The key itself, in the DNS KEY
field, and a stanza describing that the system is authorized to negotiate encryption on it
own behalf. This is done in a TXT record.
The next step is by creating the OE stanza in /etc/ipsec.conf:
conn me-to-anyone
left=%defaultroute
leftrsasigkey=%dnsondemand
right=%opportunistic
rightrsasig=%dnsondemand
keylife=1h
rekey=no
auto=route
When a connection (any connection) is initiated, a reverse DNS lookup of the destination is
done, to see if this destination supports OE as well. If so, the FreeS/WAN code quickly sets
up a tunnel using the DNS KEY records and sends the connection via the tunnel. If no OE
is supported by the other side, the connection is set up normally, without any encryption at
all.
Student Notebook
Verifying Connections With tcpdump

On the workstation:
ping -p feedfacedeadbeef 192.168.2.2
On the firewall:
tcpdump -i eth0 -x -l -n
tcpdump -i ppp0 -x -l -n
Figure 10-22. Verifying Connections With tcpdump LX243.0
Notes:
Verifying that things actually work is fairly easy: You should be able to connect to someone
in the other private network (for instance by sending a ping) and see only encrypted traffic
on the public network.
To make it easy to see if data is encrypted, use ping -p feedfacedeadbeef.
"feedfacedeadbeef" is a hexadecimal number (decimal 18369614221520256751) which is
used as pattern in the ping request. Since the -x option to tcpdump also dumps the output
to the screen in hexadecimal, this makes this pattern stand out clearly if not encrypted.

V3.0
Student Notebook
Uempty
Useful Commands
ipsec look: Show all loaded and active connections
ipsec barf: Show debug information
ranbits n: Generate random hex string of n bits (n must
be multiple of 8)
Useful for generating random keys or shared secrets
Figure 10-23. Useful Commands LX243.0
Notes:
The visual shows some commands you might need to use with FreeS/SAN.
Student Notebook
IPSec iptables Rules

Need to allow protocol 50 (ESP) and 51 (AH) on external
interface (incoming and outgoing)
# iptables -A INPUT -s 62.186.134.71 -d 62.186.134.70 -p 50 -i ppp0 -j ACCEPT
# iptables -A OUTPUT -s 62.186.134.70 -d 62.186.134.71 -p 50 -i ppp0 -j ACCEPT
# iptables -A INPUT -s 62.186.134.71 -d 62.186.134.70 -p 51 -i ppp0 -j ACCEPT
# iptables -A OUTPUT -s 62.186.134.70 -d 62.186.134.71 -p 51 -i ppp0 -j ACCEPT
Need to forward traffic between eth0 and ipsec0

# iptables -A FORWARD -s 192.168.1.0/24 -d 192.168.2.0/24 -j ACCEPT
# iptables -A FORWARD -s 192.168.2.0/24 -d 192.168.1.0/24 -j ACCEPT
Need to allow all traffic over ipsec0 interface

# iptables -A INPUT -i ipsec0 -j ACCEPT
# iptables -A OUTPUT -o ipsec0 -j ACCEPT
Need to allow traffic to/from UDP port 500 (IKE)

# iptables -A INPUT -p udp -s 62.186.134.71 --sport 500 -d 62.186.134.70\
--dport 500 -i eth0 -j ACCEPT
# iptables -A OUTPUT -p udp -s 62.186.134.70 --sport 500 -d 62.186.134.71\
--dport 500 -i eth0 -j ACCEPT
Figure 10-24. IPSec iptables Rules LX243.0
Notes:
The visual above shows the iptables rules that need to be in place to allow IPSec traffic to
go through.

V3.0
Student Notebook
Uempty
1. What different VPN solutions are there for Linux?
2. Name the components of FreeS/WAN.
3. Name the steps to take to get FreeS/WAN up and
running.
4. Name two keying methods. Which one requires
authentication?
5. Name two authentication methods.
Notes:
1.
2.
3.
4.
5.
Student Notebook
Summary
Various methods for creating VPN's exist. The IETF
standard is IPSec
IPSec is implemented in Linux through FreeS/WAN
FreeS/WAN consists of Linux kernel patches, the Pluto
daemon and various utilities
To use FreeS/WAN, you need to patch and rebuild the
kernel
FreeS/WAN config files are ipsec.conf and ipsec.secrets
Keying can be done manually or automatically; automatic
keying requires authentication
Authentication can be done manually or through RSA
public/private keys
Notes:

V3.0
Student Notebook
Uempty Unit 11. Hackers’ Tools

This unit describes the installation and usage of various tools that may
be used by hackers to try and break into your firewall. It is by no
means an exhaustive list (hackers’ tools are continually improved
upon) but should give you a general idea of the workings of these
tools.

• List categories of hackers’ tools
• Install, configure and use ethereal
• Install, configure and use nmap
• Install, configure and use Nessus

Accountability:
© Copyright IBM Corp. 2000, 2003 Unit 11. Hackers’ Tools 11-1
Student Notebook

9%

_
Notes:

V3.0
Student Notebook
Uempty
8" "<5! B""
#
~
#

#
<
Figure 11-2. Categories of Hackers’ Tools LX243.0
Notes:
Various categories of hacker tools exist. Note that hackers do not think "hey, let's write a
fingerprinter", but rather write tools to solve a particular problem or idea they are having.
These tools are only categorized afterwards. That's also the reason for the existence of a
big "other" category.
Student Notebook
7<<
+

'
]+

]`
{

{
] 99
'9

X

*
^

$'

&
!$ ^"> "&
# $ ^ "
""&
! $ ^ "
"&
Y

#

+
$ ^" " &
Figure 11-3. Sniffers LX243.0
Notes:
Sniffers are tools which allow a hacker to monitor the network traffic that passes his host
and to view the content of various packets. This is useful to retrieve information, for
instance userids and passwords. Note that there exist sniffer programs that operate on a
distant host, and send the sniffed data back over the network to the host of the hacker.
Most Linux sniffers use the libpcap library, which is usually readily available on the
distribution CD-ROM. This general library contains all the low-level routines for putting the
adapter in promiscuous mode and receiving all packets on a network.
Note that this usually does not work on a switched network, since a switch forwards the
packet only to the destination. Other systems on the network (including the sniffer) do not
see all packets, only packets from or to that system. A special setting needs to be changed
in a switch (which is usually password protected) to allow a sniffer to work1.
Sniffers also have problems on Token Ring networks. The reason for this is that the Token
Ring definition actually specifies two levels of promiscuous mode: One mode allows you to
1
Another method is by sending an ARP storm to the sniffer. This floods the internal routing table of the switch, and most switches will
react to this situation by going into hub mode, which forwards every packet to every port. Programs such as ettercap make use of this
“feature”.

V3.0
Student Notebook
Uempty capture all regular network packets, and the other mode also allows you to capture all
internal Token Ring status messages, such as beaconing messages. This makes it a little
harder to put an adapter in promiscuous mode, provided that the adapter supports
promiscuous mode at all. That combined with the fact that Token Ring is not really in use
much, especially outside IBM and IBM's customers explains that sniffer tools work less well
on Token Ring than they do on Ethernet.
There are various sniffers for Linux available. The one we've already seen is tcpdump. It is
not very sophisticated, but it is by default available in every Linux distribution, making it a
very popular one. It is sort of the vi of Unix sniffers: Not everybody likes it, but everybody
has to know how to use it.
Other, more sophisticated sniffers exist too: Ethereal and Sniffit for instance. Ethereal will
be covered later.
An even more sophisticated sniffer is Ettercap. This program knows how to dissect various
TCP protocols that are known to contain plain-text passwords (such as telnet, POP3, HTTP
and even SSHv1). It automatically grabs and prints these userids and passwords.
Strangely enough, anti-sniffer software exists too. This software is usually based on the fact
that once a packet gets through the MAC address selection process on the adapter, no
check is performed anymore whether the MAC address actually is your own MAC address.
This means that you can send an ICMP echo request (a "ping") to a bogus MAC address
but a valid IP address - the IP address of the host on which you suspect a sniffer. If the host
is actually running a sniffer, then the packet is sent to the TCP/IP stack and an echo reply is
returned. If a sniffer is not running, the adapter is not in promiscuous mode and the packet
is never picked up by the host. You don't get a reply back then either.
Student Notebook
.
"
'Y
"">
^""
!^
$# # #
<#""#
$
#"<
!
!
]
!

!

Figure 11-4. Ethereal Installation LX243.0
Notes:
Ethereal is a very easy to use and powerful sniffer. The installation is completely
straightforward and configuration is not necessary. After starting, it displays a GUI which
allows you to configure everything.

V3.0
Student Notebook
Uempty
. .
Figure 11-5. Ethereal Example LX243.0
Notes:
This is the GUI interface of Ethereal. The window is divided in three panels:
The top panel shows all the packets that were sniffed in a one-line format, with the
sequence number, the timestamp, the source and destination address, the protocol and
some information. In this panel you can select one packet which you want to inspect in
more detail.
The second panel shows the interpreted content of the packet in a tree-like structure, with
the data fields interpreted and grouped per protocol.
The third panel shows the hexadecimal and ASCII display of the packet.
Various filters can be used to filter out specific traffic. This is especially useful on a busy
network or if you want to trace traffic over a longer period of time. Network traces can be
saved and loaded later.
A very useful feature of Ethereal is the “Follow TCP Stream” feature. When you right-click
on a TCP packet and activate this feature, Ethereal gathers all TCP packets that belong to
that specific connection and displays all data of that connection in one window, whereby
the up- and downstream data have different colors. This allows you to easily see all the
data that was sent over this connection.
Student Notebook

\
X' 9 <#
X

9
! ^
©
$ ^ " >`
&
Figure 11-6. Fingerprinters LX243.0
Notes:
A fingerprinter is a program that sends various valid and invalid TCP packets to a host and
waits for the return packets. Since writing a TCP/IP stack is horribly complex and every
TCP/IP implementation has errors or omissions of some kind, a fingerprinter can pretty
accurately predict the operating system based on the content of the returned packets.
The biggest advantage of fingerprinters is that they never fully open a TCP/IP connection.
That means that without any special means to detect it, these sorts of probes will almost
never be listed in logfiles or detected in another way.
The most famous fingerprinter is Queso. We will not discuss Queso here because the
Queso functionality is integrated in nmap too.

V3.0
Student Notebook
Uempty
"7

Y9$&
$ &

9

! ^
$&$'

&
#$ ^

"
&
_ $ ^"
" "&
Figure 11-7. Port Scanners LX243.0
Notes:
A port scanner is a more crude tool than a fingerprinter. What it basically does is connect to
every port the user wants it to and look at the packets that are coming back. Based on
these return packets the program then can determine which port is open (accepting
connections) and what version of the software is being used. A hacker can then use this
knowledge to make a more directed attack on a specific service (for instance one with
known vulnerabilities).
The disadvantage of a port scanner is that it usually leaves a log trail which might be picked
up by the system administrator.
Examples of port scanners include netcat (nc), which is a default tool in most distributions,
Strobe and Nmap, with Nmap being the most sophisticated tool available.
Student Notebook

~

#
^
\~ $©
&
* \$&
\
\
\~\
#_~_
\@
'+

+
\
' ]
]Y
#
9
Figure 11-8. Nmap LX243.0
Notes:
Nmap is one of the most sophisticated host scanning tools currently available. It supports
just about any scanning method currently known, including various stealth scanning
methods (methods which usually don't show up in a logfile). Additionally, it supports slow
scans to make detection harder.

V3.0
Student Notebook
Uempty

"
' Y "">
^"
" "
\ ^
$# #
<#""#
$# # #
#"<
!
!
\
^

_

Figure 11-9. Nmap Installation LX243.0
Notes:
The Nmap installation is completely straightforward on Linux. After compilation, there are
two executable, nmap and xnmap. Nmap is the port scanner itself, and needs to be called
with various options to perform a scan, and xnmap is a graphical front-end to nmap which
is very easy to use.
Student Notebook
.
Figure 11-10. Nmap Example LX243.0
Notes:
The visual shows a screen dump of the GUI of nmap.

V3.0
Student Notebook
Uempty

"7
\ 9

X

+

! ^
#$ ^" "ª>"&
# $ ^" " &
_
$ ^"
"&
Figure 11-11. Intrusion Scanners LX243.0
Notes:
Intrusion scanning is a completely different thing from port scanning. A port scanner
basically connects to all ports and tries to figure out which version of which program is
running. The hacker can then use a list of known vulnerabilities and use this to break into a
system.
An intrusion scanner works the other way around. It uses a list of known vulnerabilities and
tries them in turn on the target system, regardless of the open ports or software version that
is used.
Intrusion scanning usually leaves a log trail and may actually cause a host to crash (if it is
indeed vulnerable). Examples of intrusion scanners are Satan, Saint and Nessus, with
Nessus being the most sophisticated.
Student Notebook
9

#
~Q#'_Q#'#

@ «¬
Y#

#
^

$«9

Y &

Y

Figure 11-12. Nessus Overview LX243.0
Notes:
Nessus is one of the best intrusion scanners available today. It has all the design features a
hacker would want in a scanning tool.
It has a client/server architecture, which means that a hacker can start this on a foreign
host (possibly a host that was broken into) running Solaris, Linux, FreeBSD or NetBSD.
The server may work on other platforms as well, but installation may require some
tweaking. Additionally, there are Nessus clients available for Windows and Linux, and a
Java client has been created which can run on any platform which supports Java. All
client-server communication is encrypted for added security. The server supports different
user profiles, which are protected with public key authentication. With these user profiles,
you can for instance allow someone to scan his own host only.
Nessus supports port scanning (although not as sophisticated as Nmap) and intrusion
scanning. In this, it is the best tool available, with currently over 200 known vulnerabilities in
its database.
Last, it has a plug-in language that makes it easy to add other scans and intrusions to the
database.

V3.0
Student Notebook
Uempty

"=
'
^"
"^

Y Y ""> Y "">

YY "">

Y
Y "">
\ ^
<"!
"
$"
$# #
<#""#@!
$@!
#"<<J#
!
!
$"
_

Figure 11-13. Nessus Installation (1) LX243.0
Notes:
Installation of Nessus requires four packages to be installed in the correct order. The
installation of each package is completely straightforward.
Student Notebook

"
_

$$
_

!
#_

$;
#_

Figure 11-14. Nessus Installation (2) LX243.0
Notes:
After installation, you need to add a nessus user account on the server. This is done with
the nessus-adduser program. When creating a user account, a public/private key pair is
created for this user, and the user account is temporarily protected with a password.
Next, you need to create a server certificate. This is needed because the client-server
connection uses public-key cryptography to authenticate the server.
After creating the user account and the server certificate, you can start the daemon. This
daemon can just run forever and will execute port scans when a client asks for it.
After the client has started, you need to configure your user name and log in to the server.
You are then asked to provide your temporary password, after which the authentication key
is transferred to the client. This is then stored in the clients home directory and can be
protected with a password as well. However, you do not need to provide a
username/password combination the next time you log in.

V3.0
Student Notebook
Uempty
.
Figure 11-15. Nessus Example LX243.0
Notes:
The client uses a graphical front-end which is shown in the visual. The most important tab
is the Plugins tab, which shows all the known vulnerabilities in the database. You can select
which vulnerability to test for. Note that testing for all vulnerabilities may take several hours,
even on a fast network.
Student Notebook
.
Figure 11-16. Nessus Output Example LX243.0
Notes:
After having run a scan, Nessus will produce the scan results in a hierarchical format per
service. Security warnings are things that might be of interest, such as version numbers of
software, but are not security holes per se. Security holes are rather serious and mean that
an attacker might be able to hack your system using these.
Note: A security hole means that someone has mentioned that it might be possible to hack
a system using that hole, under certain circumstances. It does not mean that a program
that actually exploits the hole has already been written.
One thing from experience: Nessus sometimes reports that a system is vulnerable to a
certain DoS attack which crashes the system, but your target system is still running fine.
This false positive report is due to the fact that Nessus might be configured to use a TCP
ping (basically sending an illegal TCP packet and waiting for a response) to a port that is
firewalled with iptables. Because the port is firewalled, no data is returned to Nessus, and
Nessus concludes that the host has crashed. Disabling TCP pings (or configuring TCP
pings to go to another port) can be configured at the Prefs tab.

V3.0
Student Notebook
Uempty
5! B""
~ 9$ ^" 9" ~ 9&^
$ &

X 9

$ ^"9" &^
#9
{_9_ # {
\

!

\
9 ^""
^"
"
Figure 11-17. Other Hackers’ Tools LX243.0
Notes:
As said before, hackers’ tools are usually created because of a certain need or to prove a
certain concept. This means that there exist some very strange hackers’ tools which cannot
be categorized in any of the other categories. Two of these tools are listed here: Firewalk
and Cheops.
Firewalk is the end product of a theoretical study done by some college graduates who
thought they could use a traceroute style tool to probe for (legitimate) holes in an iptables
style firewall. By sending UDP/IP packets from a specific port (for instance 53) to a specific
port (again, for instance, 53) and a specific TTL they proved that they were able to
successfully deduct various rules that are in effect on a firewall. This they called
firewalking, hence the name of the tool: Firewalk.
Another tools, Cheops, was created to quickly scan a network for interesting devices. It
works like a Windows Network Neighborhood on steroids, effectively finding every IP
device on the network that responds to a ping, but also does a quick port scan and
Queso-type OS scan to see what sort of device it actually is. This allows a hacker to quickly
Student Notebook
get an overview of the network components and network structure, and to decide where to
give attention to.
The last tool is not a tool by itself, but a generic name. An "exploit" is the name for any tool
which allows you to actually use a vulnerability that exists in a system. Exploits are typically
custom-written programs which only handle one vulnerability. They are typically found on
sites like www.rootshell.com and www.insecure.org. In fact, if Nessus stumbles upon a
security hole for which an exploit exists, it will typically give you the URL of the exploit as
well.

V3.0
Student Notebook
Uempty
8!"] "
" 9

J
"

9
J
Notes:
1.
2.
Student Notebook
7
*
9 ^

# 9>

9

*

Notes:

V3.0
Student Notebook
Uempty Unit 12. Detecting and Countering Firewall

Intrusions

This unit describes the detection and countering of firewall intrusions.

• Create a baseline of your system and detect deviations from the
baseline
• Configure and use network packet monitoring
• Configure and use logfile monitoring
• React to attack attempts
• Discuss deception

Accountability:
© Copyright IBM Corp. 2000, 2003 Unit 12. Detecting and Countering Firewall Intrusions 12-1
Student Notebook
Objectives
Create a baseline of your system and detect deviations
from the baseline
Configure and use network intrusion detection systems
Configure and use logfile monitoring
React to attack attempts
Discuss deception
Notes:

V3.0
Student Notebook
Uempty
Detecting Attack Attempts
Filesystem Changes
Added/deleted/changed files
Changed file permissions
Network packet monitoring
Monitor network packets, try to detect pattern
Logfile monitoring
Look for strange entries in logfiles
Figure 12-2. Detecting Attack Attempts LX243.0
Notes:
There are basically three ways to detect attacks on your system - apart from users
complaining that a particular service no longer works as expected:
• Changes in the filesystem
• Strange packets on the network
• Strange entries in the logfile
Student Notebook
Baseline
Baseline is a "blueprint" of your firewall in pristine state
Saved to secure media
CD-Recordable
Tape
Read-only floppy
Used to figure out what has changed
after system administration
after a break-in
after a while
Various possibilities
Full system backup
Do It Yourself
File system monitoring
Figure 12-3. Baseline LX243.0
Notes:
The baseline of a system is the "blueprint" of your system when you know it is still in
pristine condition. This is usually a file or number of files who are saved to secure media,
such as a CD-Recordable, a tape which is made read-only, or a floppy which is made
read-only.
This baseline can then be used to figure out what has changed on your system. There are
various reasons for wanting to know this, for instance:
• You might want to know which files have been changed/added/deleted after a certain
system administration task. Not only to understand what you did, but also to update
your baseline with this information.
• You might want to know which files a hacker has deleted/changed/added or which
permissions he has changed in a successful attack.
• Computer systems have the tendency to change over time. Logfiles increase in size
and get rotated, users create and delete files, the mail spool grows and shrinks. It is
interesting to know what things are normally going on and what things are abnormal.

V3.0
Student Notebook
Uempty There are various possibilities for creating a baseline, and I suggest you use all of them:
• The first obvious baseline is a full system backup, which includes all files on the system.
This can be used to retrieve a deleted file, or to restore the whole system in case of
massive changes by a hacker which got in. It is not very practical for detecting small
changes however.
• You can create a baseline yourself, which includes everything you may find interesting.
• You can use various tools that are available for filesystem monitoring. These tools
essentially create a baseline of the filesystem only, and include tools to automatically
check the current situation against the baseline.
Student Notebook
Do-It-Yourself Baseline
Save the following files
/etc/*
/boot/*
Save output of following commands
ps -aux
netstat -an
netstat -rn
free
df
du /
vmstat
ls -lR /
mount
rpm -qa
Save md5sum of all executables and libraries
Figure 12-4. Do-It-Yourself Baseline LX243.0
Notes:
A do-it-yourself baseline should consist of all important files, settings and state information
of your system. Using this baseline you need to be able to quickly determine what a hacker
has changed.
In order to do this, you need various things:
• You need all configuration settings. These are mostly stored in the /etc hierarchy, with
some settings in /boot as well. (Note that certain programs may save their configuration
settings to /usr/local/etc too.)
• You need the output of various commands that list the status of your system.
• You need some information about the executables that are on your system, in order to
be able to detect that they have changed. md5sum does just that: it uses the MD5
algorithm to create a cryptographic checksum of a file.

V3.0
Student Notebook
Uempty All these files and the output of the commands could for instance be saved to a tar file and
stored on a floppy disk. You could even format a floppy with an ext2fs filesystem, write
everything to it, unmount the floppy, make it read-only with the read-only switch, and then
mount it read-only. This way a hacker cannot tamper with it but all the information is readily
available nevertheless.
Student Notebook
Filesystem Integrity Checking

Save characteristics of every important file:
User, group
Permissions
ctime, mtime
length
link count
checksum
...
Regularly verify actual situation with stored characteristics
Various tools available:
Tripwire (http://www.tripwire.com)
AIDE (http://www.cs.tut.fi/~rammer/aide.html)
L5 (ftp://avian.org/src/hacks)
See http://www.securityportal.com/lasg/attack-detection/index.html
for exhaustive list
Figure 12-5. Filesystem Integrity Checking LX243.0
Notes:
Filesystem integrity checking tools go through the filesystem and save all the important
characteristics of each file: user, group, permissions, ctime, mtime, length, link count,
checksum and so forth. Most tools add one or more cryptographic checksums (like MD5) to
the list as well. This list of characteristics per file is then stored in a (sometimes encrypted)
database, and the actual filesystem is regularly checked against this database. Deviations
are duly reported.
Various tools exist to do this:
• Tripwire is the oldest, classic tool to do this. It was developed in the academic world but
later taken over by a commercial company. The old, unsupported academic release is
still available for free, but you will have to pay for any later releases... unless you use
Linux. Tripwire Inc. has made a free (as in free beer) version available for Linux users.
• AIDE is a free (as in free speech) replacement for Tripwire. It is about as good as the
academic release of Tripwire, but not nearly as good (yet) as the current, commercial
version of Tripwire.

V3.0
Student Notebook
Uempty • L5 basically is the same story as AIDE. It aims at replacing Tripwire but is not as good
(yet).
• Various other tools exist too. www.securityportal.com has a very extensive list.
Student Notebook
Tripwire
Popular File Integrity Checking tool
Originally written as academic research project in 1992
No development until 1997 when one of the authors
continued development as a commercial product range
Core tool released as open source in 2000
All tripwire files encrypted and signed
Digital signatures protected with password
Creates a system-dependent config file automatically
when installing
Figure 12-6. Tripwire LX243.0
Notes:
Tripwire was originally started as a research project by Gene Kim and Dr. Eugene Spafford
at Purdue University in 1992. Their Academic Source Release (ASR) was released in 1992
and became widely adopted in commercial, educational, government and security
environments.
Further development of tripwire did not take place until 1997, when Gene Kim and another
business partner decided to continue development of tripwire as a commercial tool. Among
other things, they integrated it with an HQ Daemon, which allows you perform tripwire
checks on a site-wide basis.
In 2000, Tripwire Inc. decided to release the core product, tripwire, as open source again.
The official website for Tripwire, Inc. is http://www.tripwire.com. The official website for
open-source tripwire is http://www.tripwire.org.
The tripwire authors have done a great deal to make tripwire very secure. All
communications and tripwire files are signed and encrypted for instance, with the keys
being password protected. This makes it virtually impossible for a hacker, even after

V3.0
Student Notebook
Uempty obtaining root permissions on your system, to alter the Tripwire data files without knowing
the specific password for the data file. (It is therefore wise not to use the same password as
the root password.)
Another very nice feature of Tripwire is that a system-dependent config file is created
automatically when installing. This config file is very useful, not because the syntax is
horrible (it is not) but because there are a lot of categories of files on your system, who
each require a different sort of integrity checking.
Logfiles for instance need to be checked for permissions and ownership, but do not need to
be checked for length, since they are supposed to grow anyway. Files in home directories
should probably not be checked at all, except for the permissions and ownership of the
home directory itself. But you will want to enable full integrity checking for any SUID/SGID
program on your system.
Student Notebook
Tripwire Installation and Usage

Install tripwire-version.rpm
Review text config file /etc/tripwire/twcfg.txt and policy file
/etc/tripwire/twpol.txt
Create local, site key and signed/encrypted config and
policy files:
Automatically with /etc/tripwire/twinstall.sh (Red Hat)
Manually with twadmin (SuSE)
To initialize database:
tripwire --init
To perform a check against the database:
tripwire --check [filename]
twreport -m r -r report
To update the database:
tripwire --update
Figure 12-7. Tripwire Installation and Usage LX243.0
Notes:
On most distributions, tripwire is included as a regular RPM. After installing, you need to
review (and possibly alter) the text versions of the configuration and policy files. The
configuration file obviously holds the configuration of tripwire, and the policy file lists every
file that needs to be inventoried by tripwire, together with the attributes (size, owner,
permissions, checksum, ...) that need to be recorded.
Since both these files are really important for tripwire operations, you need to encrypt and
sign this with your site- and local key. These keys need to be generated too. For this, run
the /etc/tripwire/twinstall.sh script, if available. If it is not available, you need the following
commands to manually create your keys and encrypt the configuration and policy file:
twadmin --generate-keys -L <local-key-name>
twadmin --generate-keys -S <site-key-name>
twadmin --create-cfg-file -S <site-key-name> twcfg.txt
twadmin --create-polfile -S <site-key-name> twpol.txt

V3.0
Student Notebook
Uempty When this is done, you can initialize the tripwire database. This is done with the tripwire
--init command. The database is stored in /var/lib/tripwire/hostname.twd. To initialize the
database, you need to supply your local secret key password so this process cannot run
unattended.
Once the database is successfully initialized, you can check your system against it. This is
done with the tripwire --check command. This command is typically run from cron. Reports
are mailed to you and are also stored in /var/lib/tripwire/reports. To read these (encrypted
and signed) reports, use twprint -m r -r /var/lib/tripwire/reports/reportname.
If something changes on your system, you can update your database with the tripwire
--update command.
Student Notebook
Network Intrusion Detection Systems

Act like intelligent sniffers
Can work autonomously
Examples:
Psionic PortSentry
(http://www.psionic.com/abacus/portsentry)
Scanlogd (http://www.openwall.com/scanlogd)
Snort (http://www.snort.org)
Figure 12-8. Network Intrusion Detection Systems LX243.0
Notes:
Network Intrusion Detection basically means monitoring all packets on the network, like a
sniffer, and try to detect hacking attempts. Most network monitors only detect port scans,
because these are the easiest to detect (one IP address connecting to a large number of
ports in a short time is a sure sign of a port scan).
Most network packet monitors work autonomously in the background, and only warn you
(by e-mail for instance, or by logging entries in the logfiles) of any hacking attempt.

V3.0
Student Notebook
Uempty
Snort
"Open Source Network Intrusion Detection System"
Three modes:
Sniffer
Packet capture on disk
Intrusion Detection
Works on most UNIX systems (and Linux of course)
Uses libpcap
Installing snort:
# cd /usr/src
# tar -zxvf /root/snort-version.tar.gz
# cd snort-version
# ./configure
# make
# make install
Figure 12-9. Snort LX243.0
Notes:
Snort is the open source Network Intrusion Detection System. It is fast and highly
customizable. Because of this, it is the NIDS of choice for most installations based on open
source. For example the honeynet project (discussed later) uses snort as their main NIDS.
Snort can work in three modes:
• As a regular sniffer, similar to tcpdump
• As a packet capturer which stores all network packets on disk for later analysis
• As an intrusion detection device, which looks at network traffic and tries to detect
intrusion attempts based on patterns and specific packets
Snort uses libpcap, and installation is straightforward.
Student Notebook
Snort Sniffer Mode

Similar to tcpdump
General syntax: snort [-i interface] -v [expression]
[expression]: tcpdump-style packet selection
Options:
-e: show layer-2 info as well
-d: show data as well (hex and char)
Figure 12-10. Snort Sniffer Mode LX243.0
Notes:
The first usage of Snort is as a regular packet sniffer, like tcpdump. The advantage that
Snort has over tcpdump is that its output is more readable, because snort uses multiple
lines for each network packet. (The obvious disadvantage is that it is harder to use a
program like grep on Snort output.)

V3.0
Student Notebook
Uempty
Snort Packet Logging Mode
Saves all packets to disk
Two ways of storage possible:
tcpdump compatible (one binary for all packets)
snort-specific directory structure (slower)
tcpdump compatible:
snort -b [-l <directory>] [-L <filename>]
To read a tcpdump binary file: snort -r <file>
snort specific structure:
snort -l <directory> [-h <home-net>]
Directory structure is
<directory>/<foreign-IP>/<PROTO>:<port>-<port>
File content is identical to output of snort -v
Figure 12-11. Snort Packet Logging Mode LX243.0
Notes:
Snort can also save all packets received to disk. It can do this in two modes:
• In a tcpdump compatible binary file. This does not do any decoding of the packets but
just dumps all the network traffic in a single file. The file can then later be analyzed
using snort, but also for instance by ethereal (who supports the same package format).
This capture method is by far the fastest, since Snort does not need to do any packet
decoding. In fact, using this mode Snort is able to keep up with 100 Mbps networks.
To create a binary file, use snort -b [-l <directory>] [-L <filename>]. To read a
tcpdump binary file with Snort, use snort -r <file>.
• In a Snort-specific directory structure. In this case, all packets will be decoded (just like
when Snort acts as a sniffer), and the output is saved in a text file. Snort automatically
creates a text file for each protocol and network connection, using the directory
structure <snort directory>/<foreign-IP>/<protocol>:<port>-<port>. This makes it really
easy to retrieve all packages from a single source or connection.
In order not to have to save packets twice, it is a good idea to identify the home network
to snort.
Student Notebook
Snort NIDS mode

Logs interesting packets and sends alerts
Managed by configuration file /etc/snort.conf
snort variables
preprocessors (e.g. fragmentation reassembly)
output plugins (e.g. syslog, tcpdump, database, SNMP)
rules and rule set includes
A snort rule describes the traffic to watch for, and the action
to take
Example: log tcp any any -> 1.2.3.4 22
Rules may list packet data
Rules may use variables defined in snort.conf
A rule set is a file containing related rules which can be
included as a whole in snort.conf
See /usr/src/snort-version/rules
Figure 12-12. Snort NIDS mode LX243.0
Notes:
In NIDS mode, snort captures all network traffic, analyzes this and then generates logs
and/or alerts, as appropriate.
To run Snort in NIDS mode, you need to create a snort.conf file, which is normally stored in
/etc. This file consists of four parts:
• A definition of Snort variables such as $HOME_NET and so forth.
• A list of preprocessors to enable. Preprocessors are plug-in programs which can do, for
instance, fragmentation reassembly and TCP stream reassembly. This makes it easier
to configure rules (later on) that act on TCP connections instead of individual network
packets.
• A list of output plugins to enable. Snort can send logs and alerts to its own files, to
syslogd, to databases, to SNMP servers and so forth.
• A list of snort rules and rulesets to include. A rule describes the traffic to watch for, and
the action to take when this traffic appears.
Typically, rules will not be configured in snort.conf itself, but will be stored in separate
files, called rule sets.

V3.0
Student Notebook
Uempty
Snort Rulesets
Snorts includes ~50 rulesets by default
More rule sets are available on www.snort.org
When a new virus/exploit/... hits the web, a snort rule is
only hours away...
Tools to update/download rulesets automatically:
ArachNIDS: http://www.whitehats.com/ids/
SnortCenter: http://users.pandora.be/larc/
Snort Enterprise Implementation document:
http://www.superhac.com
Figure 12-13. Snort Rulesets LX243.0
Notes:
Snorts includes about 50 rulesets by default. These are stored in
/usr/src/snort-version/rules, but can be copied to any location, as long as the correct
location is specified in snort.conf.
Snort rule sets are all-important in the NIDS world. As soon as a new malicious exploit/virus
or something else is found on the internet, people will create a rule or ruleset for it. These
rules or rulesets are typically available within hours.
Most of these rules and rulesets will be published on www.snort.org. Several tools and
systems are available to automatically download and update your rulesets.
In this course we’re only implementing Snort itself, and not any of the management and
reporting tools that people have written for it. For an excellent document on implementing
Snort as an enterprise NIDS tool, see http://www.superhac.com.
Student Notebook
Logfile Monitoring
Monitor logfiles for strange entries, continuously or at
regular intervals (through cron)
Send mail to the sysadmin if certain entries appear
Examples:
Psionic LogSentry (formerly known as LogCheck)
(http://www.psionic.com/products/logsentry.html)
Swatch
(ftp://ftp.stanford.edu/general/security-tools/swatch)
Figure 12-14. Logfile Monitoring LX243.0
Notes:
Another way of intrusion detection is logfile monitoring, in which the logfiles of a system are
monitored, continuously or at regular intervals, for strange entries. If such a message
appears, the system administrator gets a warning, usually through e-mail (although this can
be configured in most cases).

V3.0
Student Notebook
Uempty
Swatch
Can analyze log files in batch or real-time
Can output to any scriptable interface
SMS, Pager!
Installation instructions:
Download from http://swatch.sourceforge.net
perl Makefile.PL
make
make install
Need selected modules from CPAN (Comprehensive Perl
Archive Network)
Usually included in distribution
Figure 12-15. Swatch LX243.0
Notes:
Swatch is one of the best logfile analyzers currently available in the open source market. Its
main advantage is its incredible flexibility, where the same tool and configuration file can be
used to analyze logfiles in batch (once a day) or in real-time. And a neat feature is that
Swatch can output to any scriptable interface. That means that if you are able to write a
script that sends things to your GSM cellphone using SMS, or to your pager, you can
integrate it into Swatch.
If Swatch is not included in your distribution, then you need to install it manually.
Fortunately, that’s easy. Note, though, that you need a few modules from CPAN (Date-Calc
and TimeDate). These modules are normally included in most distributions.
Student Notebook
Swatch Configuration
For each line of the log file, the configuration file is
parsed from top to bottom
Stop after first match
Default configuration file: ~/.swatchrc
Default log file: /var/log/messages
Figure 12-16. Swatch Configuration LX243.0
Notes:
Swatch uses a single configuration file, typically ~/.swatchrc. For each line in the logfile,
this file is parsed from top to bottom, with a stop after the first match. If no logfile is
specified on the command line, the logfile used is /var/log/messages.

V3.0
Student Notebook
Uempty
Swatch Configuration Options
ignore <regex>: Ignore these log lines
watchfor <regex>: Watch for these log lines and
execute actions:
echo [<color>]: Echo on stdout
bell: Ring a bell
exec <command>: Execute a command
mail addresses=<recip>,subject=<subject>: Send
e-mail
pipe <command>: Pipe to command
write <user>: Use write to alert user
throttle <limit>: Limit invocation amount
continue: Don't stop after match; continue searching
through config file for more matches
Figure 12-17. Swatch Configuration Options LX243.0
Notes:
As said, for each line of the log file, the swatch configuration file is parsed from top to
bottom. There are basically two things that can be done with each line:
• ignore <regex> means that all log lines that match the regular expression are ignored.
• watchfor <regex> means that the actions listed straight after this watchfor line are
executed, for each log line that matches the regular expression.
Regular expressions are compatible with the way they are specified within perl. For more
information and their exact syntax, see man perlre.
If a log line matches a watchfor directive, then a number of actions may be specified:
• echo echoes the log line to stdout, optionally in color.
• bell rings a bell.
• exec executes a command.
• mail sends an e-mail message
Student Notebook
• pipe sends the message to a pipe

• write writes the command to a users terminal, using the write command.
Two directives may be listed in addition to the commands:
• throttle limits the invocation of this watchfor line in time. This is for instance useful if
you are sending things to your pager, to limit the monetary cost of a break-in attempt.
• continue ensures that, even if this watchfor line matches, parsing continues and
doesn’t stop.

V3.0
Student Notebook
Uempty
Swatch Batch Mode
swatch [-c <config file>] -f <log file>
Reads whole logfile and applies actions in config file
Suitable for daily log analysis
Typical configuration (negative search):
ignore /test/
ignore /modprobe/
ignore /this too, and more/
watchfor /.*/
echo
Figure 12-18. Swatch Batch Mode LX243.0
Notes:
Swatch, when used in batch mode, is useful for analyzing a log file in batch mode, for
instance after rotating the file. A typical configuration employs a negative search: ignore
everything that’s not interesting, and you are automatically left with the interesting things.
Your swatch configuration file will typically contain a large number of ignore statement,
followed by a wildcard-driven echo statement which echoes everything to stdout which has
not yet been ignored.
Since Swatch in batch mode is typically run from cron, all output will be mailed to the user.
Student Notebook
Swatch "tail -f" Mode

swatch [-c <config file>] [-t <log file>]
Suitable as a tail -f replacement
Typical configuration:
watchfor /panic/
echo red
bell
watchfor /apm/
echo green
watchfor /startup|shutdown/
echo blue
watchfor /.*/
echo
Figure 12-19. Swatch “tail -f” Mode LX243.0
Notes:
Swatch in “tail -f” mode can be thought of as a replacement for the “tail -f
/var/log/messages” command: It reads and analyzes the last line of the logfile
(/var/log/messages by default), and then waits for new additions to the logfile, which are
also analyzed. Together with a suitable Swatch configuration file, this works as an excellent
“tail -f” replacement.
A typical configuration file would include a few positive searches, which are displayed in
color and optionally ring a bell, maybe some negative searches (ignore), and a wildcard
“echo” at the end.

V3.0
Student Notebook
Uempty
Swatch Daemon Mode
Similar to "tail -f" mode, but runs in background as a
System V service
No output to stdout. Instead, only send alerts via
mail/pager/SMS/write/wall for interesting events
Typical configuration:
watchfor /panic/
mail addresses=joe,pete,subject=panic
watchfor /snort/
exec "call_pager 7654321 NIDS Alert: $*"
throttle 00:05
ignore /.*/
Figure 12-20. Swatch Daemon Mode LX243.0
Notes:
The last Swatch mode is the daemon mode. It is similar to the “tail -f” mode in the sense
that it continuously monitors the logfile for new additions. Only this time we don’t ring bells,
and don’t send anything to stdout. Instead, we watch for certain expressions (positive
search), upon which we take specific action.
These actions are typically configured to attract the immediate attention of an
administrator: mail, SMS or pager alerts.
Note that the throttle directive is extremely useful here to minimize monetary cost of an
attack.
Student Notebook
General Logging Tips

Log to a remote host if possible
Make sure the log traffic cannot be seen (SuSE:
/dev/tty8!?) or sniffed (separate network, encryption, ...)
Maintain raw logfiles for at least 30 days
Publish MD5 sums of raw logfiles as soon as they're
closed -> proves that no tampering has occurred since
Even better: sign them with PGP/GPG (but that cannot
be done automatically)
Check logfiles and swatch configuration manually every
now and then
Don't be fooled by the logger command
Figure 12-21. General Logging Tips LX243.0
Notes:
The visual lists some general logging tips.

V3.0
Student Notebook
Uempty
Countering Attacks
Start a network trace (preferably on another system)
tcpdump -i eth0 -w file
Start script
script attack.log
Determine source of attack
Determine target of attack
Block source address
Disable or block target service
Check for damage on system
Plug the hole
Analyze, document
Figure 12-22. Countering Attacks LX243.0
Notes:
So you have determined that you are under attack. Now what? Obviously the answer to
this question depends on a number of factors. There are a few steps you need to take just
about every time to collect information about the attack:
• First, start gathering information. This is best done by starting a network trace with
tcpdump or ethereal, preferably from another, uncompromised system1 (This way a
hacker does not know he is being traced.) This trace is useful for analyzing what was
going on afterwards, but may also play an important part in possible legal actions. If at
all possible, make sure a chain of evidence is started. For instance, after the trace has
finished, compress the trace file, store it on a tape or floppy, and seal this in an
envelope which you date and sign.
• Next, before you start doing any investigative work on the firewall itself, start the script
command. This command starts a subshell within your current shell and records all the
commands you type and the output of these commands. This again allows you to
analyze what was happening that very moment and allows you to evaluate your own
actions. (Remember these are usually stressful times and when you do a ps -aux on a
1
This does not work on a switched network unless the switch is configured for it!
Student Notebook
busy system you might just miss something. If you are able to retrace what you did after
the stress is over you will surely learn something from looking at your own actions with
20/20 hindsight.)
The output of the script command is saved into a file as well. This is also part of your
chain of evidence and should possibly be treated as such as well.
• The next step is determining the source of attack. Simple hacking attempts or DoS
attacks can use spoofed IP addresses but the more ingenious attacks usually are not
possible with a spoofed IP address. This way you can quickly determine what the
source of the attack is. Do a reverse DNS query on this IP address and you have a
pretty good idea what sort of host this is. If a reverse DNS query does not work, try a
traceroute. And if you take a look at the whois database at
http://www.networksolutions.com/cgi-bin/whois/whois, you can even figure out who the
administrator of this system is and how he can be contacted.2
Do not send e-mail to the administrator of the system however, but use the telephone.
Remember that the system where the attack comes from may be compromised too,
without the administrator knowing that. In that case e-mail to the administrator will
almost certainly be intercepted by the hacker anyway, and will alert him to your trace.
• You will also need to determine the target of the attack. Are we talking about a general
nmap port scan or a dedicated attack on one particular service? This can easily be seen
from the network trace.
By now you should have a pretty good idea about the sort of attack you are facing, and if it
is time to do nothing or to take action to stop the attack. This can be done in a number of
ways:
• By blocking the source IP address of the attack. This is easy if the attack is only coming
from a limited number of hosts, but next to impossible if you are suffering from a DDoS
attack.3
IP addresses can easily be done with the command iptables -I INPUT -s <IP address>
-j DROP.
• The other alternative is disabling the service that is the target of the attack. This is not to
be done lightly, since that service is not running for the fun of it. Stopping services is
done by editing /etc/inetd.conf and restarting inetd (for an inetd started service) or by
running the /etc/rc.d/init.d script for that service with the stop parameter. After that, be
sure to run ps aux to make sure that all services have indeed been stopped.
• If the attack is really fierce, you might consider doing an service iptables panic.
2
This only works for .com, .org and .edu domains. For other domains, follow the links on this page.
3
A DDoS attack is initiated from a large number of hosts simultaneously, each host sending a large number of requests. This means that
by blocking the top-50 of client IP addresses you can probably counter a DDoS attack. You might consider writing a small shell script (on
a rainy day), which does exactly that: Go through the logfile (for instance the logfile of your webserver), sort the requests by IP address,
count the occurrences of each IP address and block each address that generated more than a certain number of requests the last 15
minutes or so.

V3.0
Student Notebook
Uempty • When all is quiet, first check for any damage to the system by running tripwire --check.
If damage is done, be sure to repair it (or restore the most recent - yesterdays... -
system backup).
• Then, find out why the attack succeeded and plug that hole (or leave the service off until
a patch has been released). In case of a DDoS attack, you might want to tune some
kernel parameters as discussed in unit 3 to handle the load better. Only after you are
reasonably sure that the hole has been plugged you should restore normal service.
• The last step is to analyze the attack and your response to it. Save all files that are
relevant, including the output from tcpdump and script, and start a chain of evidence, if
needed. Document the changes made to the system, document the attack and carry on
with normal business.
Student Notebook
Deception
Emulate well-known services with security problems
Confuse and slow down attackers
Monitor attacker behavior
Retrieve information about attackers
Various tools available:
Deception ToolKit (http://all.net/dtk)
Honeynet Project:
http://project.honeynet.org/
Collection of honeypots for trend analysis
tcpdump traces of real-life attacks on their honeypots
are put up as challenges for people interested in
gaining proficiency in analyzing attacks
Figure 12-23. Deception LX243.0
Notes:
Deception is something you can use if you have a very persistent hacker on your system. It
requires you to simulate a system with a number of vulnerability problems (which in reality
don't exist) so as to deceive the hacker. All the while, you can study his behaviors and his
tools and possible gather evidence. In any way, it will most likely confuse and certainly slow
down a hacker.
One of the toolkits that is available to set up deception is the Deception ToolKit, which can
be downloaded from http://all.net/dtk.
If you’re interested in deception techniques, make sure you visit the HoneyNet Project at
http://project.honeynet.org. Their “honeynet” is a collection of honeypots running different
versions of different operating systems, for the purpose of collecting information and trend
analysis.
As part of this project they also make actual tcpdump traces of attacks on their servers
available to people who are interested in gaining proficiency in analyzing attacks. These
challenges typically last about a month or so, after which the best analysis is made public

V3.0
Student Notebook
Uempty as well. Past challenges and their solution are available as well. This makes this a great
website for learning how to do attack analysis.
Student Notebook
1. What is a baseline?
2. In which ways can you detect an attack on your system?
3. What are the steps when someone attacks your
system?
4. What is meant by deception?
Figure 12-24. Checkpoint Questions LX243.0
Notes:
1.
2.
3.
4.

V3.0
Student Notebook
Uempty
Summary
Making a baseline of your system.
Installing tools to detect attacks
React to attacks
Deception
Notes:
Student Notebook

V3.0
Student Notebook
Uempty Unit 13. Good Practices

This unit discusses some good practices in designing and maintaining
a firewall.

• Discuss some good practices in maintaining computer security.
© Copyright IBM Corp. 2000, 2003 Unit 13. Good Practices 13-1
Student Notebook
Objectives
Discuss some good practices in maintaining computer
security
Notes:

V3.0
Student Notebook
Uempty
Computer Security is a Way of Life
Computer Security is not a project, it's a way of life
A firewall alone does not make your network secure
Should be implemented everywhere
User education
Administrator education
Program design/development/test/implementation
Network and system setup
Day-to-day production
Figure 13-2. Computer Security is a Way of Life LX243.0
Notes:
Computer Security is not a project, it's a way of life. Computer Security should be in your
mind with whatever you do regarding computers. It's not just setting up a firewall which
keep your systems secure. In fact, computers are only as secure as the people who are
using and administering them.
This basically means that computer security starts with end user and administrator
education, and should also be an integral part of the design, development, test and
implementation of programs that run on your systems. And lastly, it should be something
that is an integral part of the day-to-day operations of the system.
Student Notebook
User Education
Use good passwords
At least six characters
Not a dictionary word, name, birthdate, license plate
Not easily guessable
Change frequently
Don't write them down
Don't tell anybody your password
Not even someone who claims to be an administrator
Don't download software from the internet
Don't run any program that was sent to you by mail
Beware of macro viruses
Don't leave computers/sessions unattended
Password-protected screensaver
Figure 13-3. User Education LX243.0
Notes:
A computer is only as secure as the users. That means that you need to educate your
users in computer security. The visual above shows a couple of simple things that users
need to know and do.

V3.0
Student Notebook
Uempty
Administrator Education
Follow relevant courses
Read relevant documentation/books/articles/magazines
See bibliography
Keep current on security developments
General mailing lists: CERT, Bugtraq, FBI, IBM, ERS
Specific mailing lists: Every application you use, Linux
distribution
Newsgroups: comp.security.*
IRC: fnet
Figure 13-4. Administrator Education LX243.0
Notes:
Even more important is administrator education, because the administrator has far more
privileges than a regular user. Apart from following all relevant courses (like this one) and
reading the documentation about the various products you use, it is important to keep up to
date on developments. This means subscribing to all relevant mailing lists, monitoring
newsgroups and, if time permits, joining the relevant channels on IRC.
Student Notebook
Custom Programs and Scripts

Design:
Can it run with just user privileges?
Can it run chrooted?
Can it bind to just one interface?
Authentication? Encryption?
Development:
Buffer overflows
Don't assume a file/message will be formatted
according to the specifications: check first
Use logging extensively (using syslogd)
Documentation
Test:
Test behavior under stress conditions
Implementation:
File/directory permissions
Figure 13-5. Custom Programs and Scripts LX243.0
Notes:
Special attention should be paid to custom programs and scripts that are created and
installed on your system. These should be designed, developed, tested and implemented
with security in mind. Some questions you can ask yourself are:
• Can the program run with just user permissions, or even as nobody, or is it required to
run it with root privileges? Can the program do an internal UID-switch to a user account
before it actually starts receiving data?
• Can the program run in a chrooted environment, effectively ensuring that if someone
breaks the program, the effects of this will be limited to a certain directory, instead of the
whole system.
• Can the program bind to just one interface on the system, or does it automatically listen
to all interfaces, both the internal and the external one?
• How do we authenticate the users? Are we designing our own system or can we use
PAM? Is password protection enough?

V3.0
Student Notebook
Uempty • Do we need encryption to protect the data? If so, do we create something ourselves or
are we using some industry-strength encryption scheme from, for instance, OpenSSL?
• Is the program protected from buffer overflows?
• Is the program protected from malicious or bad data? What if the configuration file or an
incoming message is not exactly formatted according to the specifications? What if it is
longer or shorter than expected?
• What and how do we log? Are we using the syslog daemon or are we writing our own
logging mechanism? To which files do we log? Are we using logrotate? Does the
program crash if the filesystem where we log to is full?
• What about documentation? What sort of documentation is needed? Is it complete and
accurate?
• What is the behavior of the program under stress conditions? Can the program handle a
large number of simultaneous users/connections? Will there be no race conditions? Will
there be no excessive memory usage? Is locking of files or shared memory in place?
• If implemented, are all the file and directory permissions set correctly?
Student Notebook
Network and System Setup

Do-it-yourself or preinstalled?
Secure distributions
Hardening scripts
Add-on software
Documentation
Backups
Failover/fallback systems
Defense in depth
Disaster recovery plans
Figure 13-6. Network and System Setup LX243.0
Notes:
The visual lists some considerations when setting up your network and systems in general:
• Although we've done it in the course to maximize the learning experience, using a
regular distribution might not be the best solution. There are a lot of distributions
available which aim it is just to implement a firewall. They contain no unneeded
services, and some of these can even run from a CD-ROM or write-protected floppy
disk.
Here's a list of these types of distributions:
FREESCO (Free ciSCO) http://www.freesco.org
Gibraltar http://www.vianova.at/products/gibraltar/
gibraltar.php?home
Linux Embedded Appliance Firewall http://leaf.sourceforge.net/
Floppy Firewall http://www.zelow.no/floppyfw/
Linux Router Project http://www.linuxrouter.org

V3.0
Student Notebook
Uempty Astaro Security Linux http://www.astaro.com

SuSE Firewall http://www.suse.com/us/products/
suse_business/firewall/index.html
Coyote Linux http://www.coyotelinux.com
NSA Secure Linux http://www.nsa.gov/selinux
SmoothWall http://www.smoothwall.org
Another approach is to take a regular distribution and secure it automatically, using
special scripts. Examples:
Bastille-Linux http://www.bastille-linux.org
LIDS (Linux Intrusion Detection System) http://www.lids.org
And a third approach is to install additional software on your firewall, which typically
does not add any core functionality, but typically helps you in managing multiple
firewalls. Examples of this include:
Checkpoint Firewall-1 http://www.checkpoint.com
• What documentation do you have/write? Is all documentation easily accessible?
• How about backups? Is your scheme really watertight? Do you change media (tapes)
frequently?
• How about failover/fallback systems? If something breaks, like a hard disk, is there
another system available that can handle the additional load? How fast can you replace
the hardware? Do you have spare components available? Do you have a contract with
a 24-hour supplier?
• Consider defense in depth: If a hacker manages to break through one layer of defense,
like your firewall, are there any other layers he needs to break through, like the security
on individual systems?
• Do you have plans for when disaster strikes?
Student Notebook
Day-to-Day Operations
Monitor system behaviour
Logfiles
top
baseline
Test security regularly
Prepare for attacks
Prioritize services
Who needs to be informed, when and how?
Don't rely on any service that might be compromised
E-mail
SSH
Think about the worst-case scenario
Don't chase windmills
99% of attacks are script kiddies who discovered
Nessus and nmap
Figure 13-7. Day-to-Day Operations LX243.0
Notes:
Security is also something that is part of the day-to-day operations of your systems. Here
are some tips:
• Monitor the logfiles regularly, and use top (despite the CPU load). In fact, top has a
special flag which allows you to run it in "secure" mode, meaning no user interaction is
allowed. This means that you can start it from a shell, and redirect the output to a
separate terminal (for instance a vt100 or ibm3151). This terminal can then be located
in a public place (like your office) without the danger of somebody exploiting this to log
in.
Obviously, you also need to compare your systems with your baseline regularly,
preferably from the scheduler (although this can be compromised), and update your
baseline if needed.
• Test your security regularly. Keep current on tools like Nessus and nmap, and use them
against your systems every now and then. Not only because new exploits may be
found, but also because a misconfiguration of your system can usually be detected this
way.

V3.0
Student Notebook
Uempty • You also need to prepare for attacks. One of the most important things is to prioritize
your services, so if your system is attacked, you know what service is the most
important. This is the service that gets the most of your attention then.
Equally important is to decide who needs to be informed if an attack is happening, how
you inform these people, and when. It is unlikely that your manager will need to know
about every network scan you detect. But your manager will need to know the details of
a full-scale DDoS attack, and you need to at least tell your users that service is
temporarily interrupted when something like that happens. And think about this: If a
hacker breaks into your system, can you safely use e-mail to alert your manager? Or
will the hacker monitor that too?
• The last thought: You will be port-scanned. There's nothing you can do about it. A lot of
wannabe hackers even scan whole ranges of PC's that are known to be connected
through cable-modems, just to see if they can hack something. But the vast majority of
these scans are simply nmap and/or nessus scans. If you know you can withstand
these scans, don't pay a lot of attention to it.
Student Notebook
Summary
Computer Security is not a project, it's a way of life
Notes:

V3.0
Student Notebook
AP Appendix A. Introduction to Cryptography
History of cryptography
Cryptography, or "the art of secret writing" is as old as the road to
Rome. Literally, because Julius Caesar was the first person known to
use cryptography to protect his messages to his troops from his
enemies.
Ever since that time, cryptography has been used, broken and
improved in a never ending battle. It is only since the 1970s that
cryptosystems were designed of which we can prove that it takes at
least a certain amount of (computer) time before they can be broken.
Terminology
There are four terms that are always used when talking about
cryptography: plaintext (or cleartext), ciphertext, cipher (or encryption
algorithm) and key. Let's introduce these by a century-old example.
Suppose Julius Caesar wants to send the message ATTACK to his
troops. He'd then encrypt this and send the message DWWDFN to his
troops. Obviously this would be complete gibberish to his enemies, but
his troops could easily decipher this (do you see how?) and attack the
unsuspecting enemies.1
Now back to our terminology:
• ATTACK is known as the plain- or cleartext message. This is the
message you are trying to protect.
• DWWDFN is known as the ciphertext. This is the message that is
actually transferred.
• The procedure "add or subtract n letters" is known as the cipher or
encryption algorithm.
• The number "3" is known as the key.
Random numbers
Random numbers are an integral part of cryptography. A lot of
algorithms presented later rely on truly random numbers for their
secure operation.
Since a computer is completely deterministic, it is really hard to
generate random numbers automatically. The best that most
1
This encryption mechanism has actually been invented by Julius Caesar and is therefore known as Caesar's encryption.
© Copyright IBM Corp. 2000, 2003 Appendix A. Introduction to Cryptography A-1

Student Notebook
computers can do is use pseudo-random numbers. Knowing the

algorithm that generates these pseudo-random numbers is a great
help, since it generally allows a hacker to predict precisely which
"random" numbers will be used.
Linux has solved this with the inclusion of a /dev/random device. This
device gathers randomness (in the cryptography world, this is called
entropy) from the environment and uses that to generate truly random
numbers. If there is not enough randomness in the environment, the
device just stops producing random numbers.
To illustrate that, execute the following command:
cat /dev/random | hexdump
You will see some ten lines of random data, and then everything
blocks. Now start moving your mouse...
One way encryption

One-way encryption, sometimes also called hashing, is an encryption
algorithm where decryption is not possible, and a key is not being
used. These algorithms seem useless, but they are used a lot. There
are two main uses for these kinds of encryptions:
• Protection of passwords. When a user sets his own password, the
password is encrypted using a one-way encryption scheme such
as crypt (the default Unix algorithm based on DES) or MD5. The
encrypted password is then stored on disk. Should this user try to
login again, then the password he typed is encrypted again and the
encrypted passwords are compared to each other. If the encrypted
passwords match, the original plaintext passwords must have been
the same.2
• Message digests/checksums. In this case, a large data block (for
instance a downloadable file or e-mail message) is encrypted with
a one-way encryption algorithm. This algorithm usually leads to a
ciphertext which is considerably smaller than the original data and
can easily be posted on a web site for instance. If someone
downloads the package or gets the e-mail, he or she encrypts the
data again and compares the result with the posted ciphertext. If
they are the same, you can be sure that the package has not been
tampered with.
Most one-way encryption mechanisms use the modulus function
extensively. Remember the modulus function from school? It is the
remainder when you do a long division. So 10 mod 3 equals 1.
2
To be honest, there is a very low chance (in the order of 1 in 2100 ) that they were not the same but coincidentally encrypt to the same
ciphertext.
A-2 Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
AP Secret or Private key encryption

Secret or Private key encryption systems are systems where the
algorithm of encryption is essentially reversible, using the same key.
So if you possess a certain key, you can use this key both for
encryption and decryption of messages. An example of such a
scheme is the Caesar's encryption we already talked about. Other
examples are DES, 3DES and Blowfish.
Secret or Private key encryptions require that the key be kept an
absolute secret. Anybody who has the key has the ability to encrypt
and decrypt messages.
Public key encryption

Public key encryption is a very recent invention. The first example of
this was the RSA encryption mechanism, invented around the 1970's.
These encryption mechanisms all require two keys to be generated.
These keys should always be generated simultaneously. The
encryption algorithm then uses one of these keys for encryption, while
only the other key can be used for decryption.
Suppose that our key generation algorithm generated two keys, called
Kp and Ks. If we have a piece of plaintext and encrypt it with Kp, we
can only decrypt it with Ks. If we have a piece of plaintext and encrypt
it with Ks, we can only decrypt it with Kp.
Now comes the ingenious part: One of these keys is not kept secret,
but is published to everyone who wants it. Maybe on an Internet page
or on a special key server. This key is usually called Kp, for Public Key.
The other key is kept secret, hence the notation Ks.
What if someone wants to send me a private message? He then takes
the plaintext and encrypts it with my public key. Since the message is
encrypted with my public key, it can only be decrypted with my secret
key. And I am the only one who knows that key, so my message is
safe.
But surprisingly, this scheme can also be used the other way around: I
send someone a message and I encrypt that message with my secret
key. The message can then only be read by someone who uses my
public key to decrypt it. And since they needed my public key for the
decryption, they can be sure the message was encrypted with my
secret key. In other words: They know the message came from me.
Both schemes are usually used together to make sure the message
does not fall into the wrong hands and the recipient can verify that the
message is authentic.
© Copyright IBM Corp. 2000, 2003 Appendix A. Introduction to Cryptography A-3

Student Notebook
There is one disadvantage in using public-key algorithms: they’re

extremely slow when compared to secret-key algorithms. This is not a
problem for e-mail and other low-volume high-latency applications, but
is a problem in high-volume, low-latency communications such as
VPNs. In that case, public key algorithms are typically only used for
authentication and secure transfer of a random number, which is then
used as the key for a secret-key algorithm. This scheme is used for
instance in SSL/TLS and IPSec.
Key length considerations

Most cryptographic algorithms today are based on the principle that
the product of two primes cannot easily be factored back into the two
primes, or similarly hard mathematical problems. The only method to
crack these problems is essentially a brute-force attack (just try every
prime there is). This means we can pretty accurately predict how long
it will take for a certain keylength to be cracked. In short: Any
keylength of 64 bits and less is considered insecure, and should be
used for data that is not really important, or expires quickly. A strong
algorithm will use key lengths of 128 bits or more.
Additional documentation
http://www.garykessler.net/library/crypto.html is an excellent document
about cryptography. It has a well-written overview and covers all the
main protocols in sufficient detail.
In addition to that, good cryptography overviews are available at
http://www.ssh.fi/tech/crypto and
http://www.hill.com/library/staffpubs/crypto.html.
The standard reference book on cryptography is “Applied
Cryptography” (2nd edition) by Bruce Schneier (John Wiley and Sons,
Inc., 1996. ISBN 0-471-11709-9)
A-4 Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
AP Appendix B. Checkpoint Solutions

Unit 1
1. A Hacker means no harm, but might accidentally cause it.
A Cracker means to harm you.
2. No.
3. A firewall is a combination of components which implements and
enforces the security policy.
4. Filtering Router
DMZ (DeMilitarized Zone) or Screened Subnet
Network Address Translation or IP Masquerading
Socks Server
Proxy Server
Mail Gateway
DNS Server
Tunneling Device
5. Misuse of allowed connections
Malicious users/administrators
Data in transit on the internet
Connections that bypass the firewall
Physical theft, breakin, bribery
Unit 2
1. Install as few services as possible
Set a good root password
Apply all available patches
Possibly recompile the kernel
2. Configure BIOS as securely as possible
Set a LILO password
Configure as few user accounts as possible
Run as few services as possible
Make filesystems as secure as possible
© Copyright IBM Corp. 2000, 2003 Appendix B. Checkpoint Solutions B-1

Student Notebook
Disable Ctrl-Alt-Del
Edit /etc/issue, /etc/issue.net and /etc/motd to reveal as little
information as possible
Set the $TMOUT variable
Unit 3
1. IP
ICMP
UDP
TCP
2. IP: ID, FLG, Fragment Offset, TTL, Source and Destination IP
address
ICMP: Type, code, data
UDP: Source and destination port
TCP: Source and destination port, Sequence number, Urgent flag
and pointer, SYN and ACK flags.
Unit 4
1. Network interface
Protocol
Source and/or destination IP address
Source and/or destination port
Direction of TCP connection setup
ICMP Packet type
2. The packet filtering code itself is integrated in the Linux kernel with
a user space tool (iptables) to manage it.
3. A chain is a set of rules that are tested in a given situation.
4. A rule is a statement which contains criteria that may match a
packet and an action that is to be performed if there is a match.
5. Network Address Translation is the translation of source IP packets
and port on forwarded packets so that they seem to originate from
the router instead of from the real host.
B-2 Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
AP Unit 5
1. They require plain text passwords to be transferred over the
network.
They allow the user to configure authentication based on source IP
address.
2. By disabling IP based authentication and by using strong
encryption for authentication and data transmission.
3. Various, including implementations from http://www.ssh.fi and
//www.openssh.org.
4. Host certificates
User certificates
5. The host public key is transferred the first time a user connects to a
host.
It is used for host authentication, to prevent against a
man-in-the-middle attack.
6. The user public key is transferred when the user wants to and is
used to authenticate a user without a password.
Unit 6
1. The client connects to the socks server and sends the requested IP
address and port number over this connection.
The socks server then opens a connection to this IP address and
port number and passes all data back and forth.
2. Advantages: TCP aware, transparent, secure.
Disadvantages: Only works well with TCP, client needs to do DNS
lookup.
3. Nec Socks server
Dante Socks server
4. Unpack, configure, compile, install
Create Dante config file
Create Dante init script.
Unit 7
1. The proxy protocol requires the client to open a TCP connection to
the proxy server, and to specify the request as a HTTP request.

Student Notebook
The proxy server then fulfils this request (even if this requires
starting an FTP session) and sends the data back to the client.
2. Advantages: Proxy does DNS lookup, very granular logging and
access control, Caching possible.
Disadvantages: Only works for specific protocols, generally slower
than NAT.
3. Apache
Squid
Various proxy servers in the TIS Firewall Toolkit
4. Basically by setting ProxyRequests on in the Apache configuration
file.
5. Unpack, configure, compile and install
Create config file, create log and cache directories
Do squid initial setup
Unit 8
1. Do not give away internal information to Internet users
Allow internal users to retrieve Internet DNS information
Ensure that regular and inverse DNS queries match
Do not allow dynamic updates
Do not allow large transfers
2. If you are using proxies, no.
If you are using socks or NAT, yes.
3. One or two on the DMZ
One or more on the Intranet
4. On the DMZ: information about the DMZ and a forward statement
to the Internet.
On the Intranet: information about the Intranet and DMZ, and a
forward statement to the DMZ DNS server.
5. Query from the Intranet: Intranet, DMZ, Internet DNS
Query from the DMZ: DMZ, Internet DNS
Query from the internet: Internet, DMZ DNS

V3.0
Student Notebook
AP Unit 9
1. Sendmail
Qmail
Postfix
2. Allow internal users to send mail to Internet users
Allow Internet users to send mail to internal users
Do not allow your server to be used as a relay
Block incoming junk E-mail (spam)
Block certain attachments
Block messages with viruses
Do not give away internal information
Unit 10
1. PPP over telnet or ssh
PPTP
IPSec
2. Klips: Kernel IPSec patches
Pluto: Key negotiating daemon
Various utilities
3. Unpack the freeswan package and build freeswan executables
Patch kernel with freeswan patches and rebuild and install kernel
Verify IP forwarding is on and rp_filter is off
Verify that Pluto is started automatically
Decide on keying method and authentication method
Configure FreeS/WAN and start ipsec service
4. Manual keying
Automatic keying
Automatic keying requires authentication
5. Manual
Automatic through RSA

Student Notebook
Unit 11
1. Conduct a port scan to watch for open services
Connect legitimately to each service and retrieve as much
information as possible
2. Make port scans as hard as possible
Give away as few pieces of information as possible
Unit 12
1. A baseline is an accurate picture of the pristine system which can
be used to detect that something in the system has changed.
2. Filesystem changes
Network packet monitoring
Logfile monitoring
3. Start a network trace and start script
Determine source and target of attack
Block source address and/or disable target service
Check for damage on the system
Plug the hole
Analyze and document the attack
4. Setting up an environment which to the hacker seems to be full of
vulnerabilities in order to study the hacker’s behavior and gather
information about the hacker.

V3.0
Student Notebook
AP Appendix C. Certification Information

As mentioned in this course, Linux is not a product which is owned by a single company.
Instead, it is developed by a loose team of volunteers on the Internet. As such, there is no
"natural" body responsible for Linux certification. At this moment, at least four organizations
have tried to fill this void and have come up with their own Linux certification program. IBM
supports three of these organizations:
• The Linux Professional Institute (http://www.lpi.org) is an organization run by
volunteers with the sole purpose of implementing a vendor-neutral certification program
for Linux. They are sponsored by a number of Linux-related companies, among which
IBM. The certification tests are delivered by VUE (Virtual University Enterprises)
(http://www.vue.com). LPI aims to implement three levels of certification, of which the
first two levels are currently ready.
UnitedLinux (the consortium of Linux distributors SuSE, SCO, TurboLinux and
Conectiva, http://www.unitedlinux.com) has announced a UnitedLinux certification,
which will be an extension of the LPI certification.
• CompTIA (http://www.comptia.org) is the organization that has, in the past, already
developed a number of certifications that are aimed mostly at helpdesk personnel and
hardware engineers. Recently CompTIA introduced the Linux+ exam, which is aimed
at Linux Professionals with 6 months of experience with Linux. CompTIA tests are also
delivered by VUE, and by Prometric (http://www.prometric.com).
• Red Hat (http://www.redhat.com) is the distributor of Red Hat Linux, one of the leading
commercial Linux distributions. As part of their service organization they have
developed their own education leading to the Red Hat Certified Technician and Red
Hat Certified Engineer exams. In contrast to the other Linux exams, the RHCT and
RHCE exams are performance based, which means that the examinee takes place
behind an actual Red Hat Linux system and needs to demonstrate his/her skills on this
system. The practical components of the RHCT exam takes about 2.5 hours, while the
practical components of the RHCE exam take about five hours.
For all three certification programs, the support of IBM extends to the following:
1. Involvement and/or active support in developing the certification program, the exam
objectives and test questions.
2. Where appropriate: sponsoring the certification program.
3. Developing courseware and teaching courses to prepare students for certification, and
where possible certifying this course material for the exams involved.
4. Exam delivery.
© Copyright IBM Corp. 2000, 2003 Appendix C. Certification Information C-1

Student Notebook
IBM IT Education Services Courseware

IBM IT Education Services started developing courseware for Linux at the end of 1998,
when no certification programs for Linux existed. The Linux curriculum was heavily
modeled after the AIX curriculum, but has changed since to reflect the different ways Linux
and AIX are being used today. IBM's Linux course material is not tied to any particular
distribution, and is also not tied to any particular certification.
The total curriculum consists of more than fifteen courses that cover the Linux Operating
System, and an even larger number of courses that cover IBM middleware that runs on
Linux (such as DB2, MQSeries, Lotus Domino and so forth) and IBM hardware. For the
purpose of certification though, only seven courses are important:
LX02 (Linux Power User) is the entry course in the IBM/Linux curriculum. Its aim is to
teach a Linux novice to install and configure Linux so that he/she is able to run Linux on
his/her personal workstation or home system in an environment that is mostly based on
MS-Windows.
LX03 (Linux System Administration I: Implementation) is the main system
administration course. Its aim is to teach a Linux user the techniques and practices used in
installing, configuring, running and maintaining a Linux-based server.
LX07 (Linux Network Administration I: TCP/IP and TCP/IP Services) is the main
network administration course. Its aim is to teach a Linux system administrator how to
configure TCP/IP and various TCP/IP services that run on Linux.
LX22 (Linux Perl Programming) is the course that covers Perl programming.
LX23 (Linux Bash Programming) is the course that covers Bash shell programming and
the various programs that are typically used in shell programs, such as grep, awk and sed.
LX24 (Linux Network Administration II: Network Security and Firewalls) covers the
configuration of a full-function firewall under Linux. As such, it also covers a number of
security aspects of Linux that are not particularly related to firewalls, but apply to any
networked system.
LX25 (Linux as a Web server - Apache) is the course which covers Apache, the most
commonly used web server on Linux and other UNIX platforms.
LX26 (Linux integration with Windows - Samba) is the course which covers Samba, the
product which emulates a networked Windows NT server to the network.
All these courses are available from IBM IT Education Services and selected business
partners (pricing and availability may differ from country to country). For information on
pricing and scheduling, contact your local IBM IT Education Services representative.
IBM IT Education Services has developed these courses so that they can be taken in a
logical order. Furthermore, the organization of topics into courses is such that at the end of
a course, a student is able to fully grasp a topic, and is able to apply this successfully on his
Linux system(s).
C-2 Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
AP From Education to Certification

IBM’s arrangements of topics into IBM’s Linux courses is not always consistent with the
requirements of the supported certifications. This leads to a problem when determining
which courses are needed for which certification. A certain test might require "installation
and basic configuration" of a product. This is covered by a certain IBM/Linux course, but
that very same course also covers "advanced configuration", which might be the subject of
an entirely different test.
As an example, IBM has one, two-day course about Samba (the LX26), which fully covers
the whole Samba product and its possibilities. Samba knowledge is tested by the LPI in two
places though: Test 102 (topic 1.13, objective 4) requires the examinee to "install and
configure Samba using the included GUI tools or direct edit of the /etc/smb.conf file" (which
is covered in the first two units of the LX26), while test 201 (topic 2.9, objective 1) requires
that "the candidate should be able to set up a Samba server for various clients, including
setting up a login script and setting up and nmbd WINS server" (which is the end objective
of the LX26).
This problem is too fundamental to solve by simply changing or rearranging the course
material, apart from the fact that we think that it is not desirable to specifically write courses
for certification. One of the purposes of this attachment is therefore to identify the areas
where IBM's course material does not match with certification objectives.
© Copyright IBM Corp. 2000, 2003 Appendix C. Certification Information C-3

Student Notebook
Education/Certification Matrix
The following table lists the required and recommended courses for each of the supported
certification programs:
CompTIA LPI Red Hat
Course
Linux+ Test 101 Test 102 Test 201 Test 202 RHCT RHCE
LX02 Required Required Required Required Required Required Required
LX03 Required Required Required Required Required Required Required
LX07 Required Required Required Required
LX22 Recomm.
LX23 Recomm. Recomm.
LX24 Required Recomm.
LX25 Recomm. Required Recomm.
LX26 Recomm. Required Recomm.
Remarks to the table:
1. Required means: the subjects covered in this course are essential knowledge to pass
the exam.
Recommended means that a small portion of the exam (less than 5%) is covered in the
course listed. It is possible to pass the exam without this knowledge. Students do so
however at their own risk and should compare their knowledge with the exam
objectives.
2. CompTIA Linux+ also requires intimate knowledge of PC hardware in general (Domain
7) which accounts for 19% of the exam. This includes knowledge of the BIOS, IRQs, I/O
ports, DMA, ATA devices, SCSI devices, IEEE 1394 devices, PCMCIA devices, ISA
devices, PCI devices, APM and the ability to configure and replace them, were
applicable. This part of the exam is not related to Linux and thus not covered in any of
IBM’s Linux courses. CompTIAs own education (and other education) that leads to
CompTIA A+ certification may be used to obtain this knowledge.
3. ProCert (http://www.procert.com) has certified these courses as appropriate course
material for preparing for LPI certification tests. This certification is only valid if all
courses, including the courses that are listed here as “recommended” are taken before
attempting an LPI certification test.
4. IBM IT Education Services is a Red Hat Authorized Training Partner and as such
allowed to teach the Red Hat courses RH033, RH133 and RH253. These courses can
be used as an alternative to LX02, LX03 and LX07, respectively, to prepare for
RHCT/RHCE certification. They cannot be used for other certifications though, and
these courses are not scheduled in all countries.
C-4 Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
bibl Bibliography
Books:
ISBN 0735709009 Robert L. Ziegler, Firewalls. New Riders, First Edition, 1999.
ISBN 1565928717 Elizabeth D. Zwicky et al., Building Internet Firewalls. O'Reilly &
Associates, Second Edition, 2000
ISBN 0672316706 Anonymous, Maximum Linux Security: A Hacker's Guide to
Protecting Your Linux Server and Workstation. Sams Publishing,
1999.
ISBN 0130201308 Martin Murhammer et al., TCP/IP Tutorial & Technical Overview.
Prentice Hall, First Edition, 1999
ISBN 1565921488 Simson Garfinkel, Gene Spafford, Practical Unix and Internet
Security. O'Reilly & Associates, Second Edition, 1996
ISBN 1565922220 Bryan Costales, Eric Allman, Sendmail. O'Reilly & Associates,
Second Edition, 1997
ISBN 1565925122 Cricket Liu et al., DNS and BIND. O'Reilly & Associates, Third
Edition, 1998
ISBN 0471253111 Bruce Schneier, Secrets and Lies; Digital Security in a Networked
World. John Wiley and Sons, 2000
ISBN 0471117099 Bruce Schneier, Applied Cryptography. John Wiley and Sons, 1996
WEB URLs:
http://www.securityportal.com Generalizing Ethics in an
Information-based Society
http://www.openna.com Open Network Architecture
http://www.insecure.org Computer Security, Nmap, Port
Scanner, Exploit World, Exploits,
Hacking, Hacker, Linux etc.
http://www.mcafee.com Virus scanner
http://amavis.org A Mail Virus Scanner
http://www.linux-firewall-tools.com Linux Firewall Tools
http://www.freeswan.org FreeS/WAN
http://www.sophos.com Sophos Anti-Virus
http://www.socks.nec.com Socks reference implementation
http://www.openssl.org OpenSSL project
http://sniffit.rug.ac.be Sniffit
http://www.ethereal.com Ethereal
http://www.packetfactory.net The Packetfactory
http://www.2600.org The Hacker Quarterly
http://grc.com Gibson Research Corporation
http://www.iss.net Internet Security Systems
http://www.snort.org Snort
© Copyright IBM Corp. 2000, 2003 Bibliography X-1

Student Notebook
X-2 Linux Network Administration II © Copyright IBM Corp. 2000, 2003

V3.0
Student Notebook
IX Index
Symbols ARP storm 11-4
$DISPLAY 5-6, 5-16 Authentication 1-4, 1-8, 10-23
$HOME/.bash_profile 2-19 Authorization 1-4
$LANG 9-23 automatic keying 10-17
automatically keyed connection 10-22, 10-23
$LD_PRELOAD 6-11
$TMOUT 2-19
/boot/grub/menu.lst 2-10 B
/etc/fstab 2-15 backups 1-6
/etc/hosts 9-7 base of operations 1-13
/etc/hosts.allow 1-33 baseline 12-4
/etc/hosts.deny 1-33 Bayesian Filter 9-16
/etc/hosts.equiv 5-3 biometrics 1-9
/etc/init.d/boot.ipconfig 3-32 BIOS 2-9
/etc/init.d/boot.sysctl 3-32 BIOS password 2-9
/etc/inittab 2-16 blackmail 1-13
/etc/issue 2-17 blueprint 12-4
/etc/issue.net 2-17 Boot Loader 2-10
/etc/lilo.conf 2-10 break-in 1-14
/etc/mail/access 9-7 brute-force 1-15
/etc/mail/mailertable 9-7
/etc/modules conf 4-29
/etc/motd 2-18 C
/etc/profile 2-19 CDMF 10-9
/etc/rc.d/init.d/iptables 4-31 chain 4-6
/etc/rc.d/rc.sysinit 3-32 Challenge 1-12
/etc/rc.local 2-17, 4-29 CHAP 10-5
/etc/sysconfig/sysctl 3-32 checksum 2-4
/etc/sysctl.conf 3-32 Cheops 11-19
/etc/xinetd.conf 2-13 chkconfig 2-13, 3-32, 6-9
/etc/xinetd.d 2-13 choke point 1-19
/proc 3-32 CIDR 3-9
/proc/sys 3-32 Cisco PIX 4-34
/proc/sys/net/ipv4/conf 3-36 Classless InterDomain Routing 3-9
~/.rhosts 5-3 clear text 5-3
CMOS 2-9
Comprehensive Perl Archive Network 9-22
Numerics CompTIA C-1
3DES 10-9, 10-18, 10-21 connection setup 1-22
connectionless 3-4
A CPAN 9-22, 9-23, 12-21
accept_redirects 3-36 cracker 1-10
accept_source_route 3-36 credit card 1-13
ACK 3-23, 3-25 cron 12-25
acknowledgement number 3-23 Ctrl-Alt-Del 2-16
AH 3-12, 10-6, 10-8 Curiosity 1-12
AIDE 12-8
air conditioning 1-6
AMaViS 9-21
D
DaemonPortOptions 9-8, 9-10
Apache 7-6 Dante 6-6, 6-7
APM 2-9 Data offset 3-23
arc 9-24 datagram 3-4
© Copyright IBM Corp. 2000, 2003 Index X-3

Student Notebook
DDoS 1-13, 3-21 Firewalk 11-19

DDoS attack 12-30 firewall 1-19, 1-20
Deception 12-32 Flags 3-12
de-masquerading 4-25 flooding 1-4
Demilitarized Zone 1-22 Follow TCP Stream 11-7
Denial of Service 1-16 FORWARD chain 4-6
Denial-of-Service 1-13 fragment 3-12
DES 10-9 Fragment offset 3-12
destination IP addres 3-12 FreeS/WAN 2-7, 10-11
Destination NAT 4-4 FTP 1-24, 7-3
destination port 3-21, 3-23, 3-27 ftp 5-3
Destination unreachable 3-16 ftp server 8-9
destination unreachable 3-18 fuser 2-14
DHCP 8-4 FWBuilder 4-34
Diffie-Hellman 10-10
Distributed Denial of Service 1-16
Distributed Denial-of-Service 1-13 G
DMZ 1-22, 1-24, 1-25, 1-27, 8-5, 8-7, 9-4, 9-13 Gene Kim 12-10
DNAT 4-4 GNU Public License 5-5
DNS 1-26, 7-4, 8-3, 9-13, 10-25 Gopher 7-3
DNS server 1-26 GPG signature 2-4
DoS 1-13, 2-6, 3-18, 12-30 GRUB 2-10
DoS attack 8-4 GSM 12-21
DSA 5-13 gunzip 9-24
dynamic updates 8-4
H
E hacker 1-10, 8-3
Echo reply 3-16 half-open 3-28
echo reply 3-18 header 3-4
Echo request 3-17 header checksum 3-12
echo request 3-18 Header Length 3-11
EICAR 9-24 HLEN 3-11
e-mail 1-25 HoneyNet Project 12-32
encryption 1-28 honeynet project 12-15
ESP 3-12, 10-6, 10-9 honeypot 12-32
espauthkey 10-21 host key 5-9
espenckey 10-21 HTTP 7-3, 11-5
espionage 1-12 httpd.conf 1-33
Ethereal 3-29, 11-5, 11-6, 11-7 HTTPS 7-3
ethereal 12-29
ettercap 11-4
Eugene Spafford 12-10
I
IAB 5-4
Exim 9-5, 9-6
IANA 3-6, 4-16, 8-9
exploit 11-20
ICMP 3-12, 3-15, 3-18
Extranet 10-3
icmp_echo_ignore_broadcasts 3-33
ICP 7-6
F Identd 4-20
feedfacedeadbeef 10-30 Identification 3-12
file transfer 5-3 IETF 6-3, 7-3
filesystems 2-3 IKE 10-6, 10-10
filter table 4-10 IMAP 9-4, 9-11, 9-12
FIN 3-24 init 2-16
fingerprint 1-9, 11-8 INPUT chain 4-6
fire 1-4 Internet Addressing and Naming Agency 3-6

Student Notebook
Internet Architecture Board 5-4 Linux Professional Institute C-1

Internet Cache Protocol 7-6 log_martians 3-36
Internet Draft 5-4 logging 7-4
Internet Protocol 3-4 loopback 3-7
Intranet mail server 9-4 LPI. See Linux Professional Institute
Intrusion scan 11-13 LX02 C-2
IP 3-4 LX03 C-2
IP address 1-22 LX07 C-2
IP addresses 3-5 LX22 C-2
IP forwarding 10-15 LX23 C-2
IP Masquerading 4-4, 4-25, 7-10 LX24 C-2
IP packet 1-22 LX25 C-2
IP spoofing 5-3 LX26 C-2
ip_conntrack_ftp 4-29
ip_default_ttl 3-34
ip_local_port_range 3-34 M
ip_nat_ftp 4-29 m4 9-14
ip_no_pmtu_disc 3-34 mail client 1-25
ipchains 4-8 mail exchanger 9-13
ipfilter 4-34 mail gateway 1-25, 9-4
ipfrag_high_thresh 3-34 mail relay 1-25
ipfrag_low_thresh 3-34 make 9-7
ipfrag_time 3-34 mangle table 4-10
ipfwadm 4-8 man-in-the-middle 1-15
IPSec 10-5, 10-6 manual keying 10-16
ipsec_spi 10-18 manually keyed connection 10-20
ipt_LOG 4-23 maximize throughput 3-11
ipt_REJECT 4-21 maximum reliability 3-11
iptables 4-8, 4-9, 4-10, 4-13, 4-32, 4-34, 8-19 MD5 2-4, 10-8, 10-18, 10-21
iptables-restore 4-9, 4-30, 4-32 md5crypt 2-10
iptables-save 4-9, 4-30 md5sum 12-6
IPv6 10-5 milter interface 9-17
ISP 8-9 minimize delay 3-11
minimize monetary cost 3-11
MIT Magic Cookie 5-16
J modprobe 4-29
Java applets 7-4 Morris Worm 9-5
multicast 3-7
MX record 9-13
K
kernel modules 2-7
kernel recompile 2-6 N
Klips 10-11, 10-18 NAT 6-5, 7-5, 8-3
klipsdebug 10-18 nat table 4-10
Nec 6-6
Nessus 11-13
L netcat 11-9
L5 12-9 netmask 3-10
layering 3-3 netstat 2-14
leased lines 1-28 Network Address Translation 4-4, 7-10
leftnexthop 10-20 Network Address Translators 1-24
leftsubnet 10-20 network administrator 3-5
liability 1-13 network identifier 3-10
libdsocks 6-10 Network Interface 4-3
libpcap 11-4, 12-15 Network Intrusion Detection System 12-15
LILO 2-10 Network security 1-4, 1-7

Student Notebook
NIDS 12-15 protocol 1-22

Nmap 11-9, 11-10 proxy 1-20
nmap 11-8, 12-30 proxy protocol 7-3
nodev 2-15 Proxy server 1-24
noexec 2-15 proxy server 7-3
nosuid 2-15 Proxy servers 7-10
ProxyRequests 7-7
ps 2-14
O PSH 3-23
OpenBSD PF 4-34 public key 5-9, 10-17
OpenSSH 5-5 Public key cryptography 1-8
OpenSSL 5-5 Purdue University 12-10
Opportunistic Encryption 10-29
OUTPUT chain 4-6
Q
Qmail 9-5, 9-6
P Queso 11-8
pacing 3-21
Packet Filtering 4-3
packet filtering router 1-22 R
Packet mangling 4-36 random 3-27
packet mangling 4-5 rcp 5-3, 5-4
pager 12-21, 12-27 rcSuSEfirewall2 4-32
Parameter problem 3-17 real-time blacklisting 9-20
partitions 2-3 Red Hat C-1
password 1-8 Red Hat Certified Engineer C-1
perl 9-17, 12-23 Red Hat Certified Technician C-1
PGP 1-8 Redirect 3-16
Physical security 1-4, 1-5 redirect 1-14
ping 4-17 Redirect ICMP 3-18
Pluto 10-11 regular expression 12-23
plutodebug 10-18 RELAY 9-7
plutoload 10-18 remote execution 5-3
plutostart 10-18 remote login 5-3
PMTU discovery 3-34 retina pattern 1-9
POP 9-4 reverse DNS lookup 8-3
POP3 9-11, 9-12, 11-5 rexec 5-3
PoPToP 10-5 RFC 5-4, 10-18
port forwarding 4-4, 4-35 1928 6-3
port number 1-22 2616 7-3
port numbers 3-19 RHCE. See Red Hat Certified Engineer
port scan 2-7 RHCT. See Red Hat Certified Technician
port scanner 11-9 rightnexthop 10-20
Postfix 9-5, 9-6, 9-9 rightsubnet 10-20
POSTROUTING chain 4-6 rlogin 5-3
PPP 10-4, 10-18 ro 2-15
PPTP 10-4 Road Warrior 10-28
Precedence 3-11 root password 2-3
PREROUTING chain 4-6 rp_filter 3-36
pre-shared key 10-17 RPM 2-4, 6-7, 7-8
pre-shared secret 10-17 rpm 2-5
Pretty Good Privacy 1-8 RSA 1-8, 5-8, 10-17, 10-24
private key 5-9 RSA Challenge-Response Authentication 5-12
private networks 3-7 rsh 5-3, 5-4
procmail 9-17 RST 3-23
Protocol 3-12 ruleset 12-19

Student Notebook
S ssh 5-4, 5-6, 10-4

SA 10-10 SSH protocol 5-4
Saint 11-13 SSH Tunnel 5-18
sa-learn 9-17 SSH tunnel 5-16
Samba C-3 ssh-add 5-15
Satan 11-13 ssh-agent 5-14
scanning 1-14 sshd 5-4, 5-8
scp 5-4, 5-7 ssh-keygen 5-12
screened subnet 1-22 stacheldraht 1-13
script 12-29 stateful TCP inspection 4-36
script kiddie 1-10 StrictHostKeyChecking 5-9
secondary DNS 8-4 Strobe 11-9
secure port 3-21 strong encryption 5-4
Security Association 10-10 su 2-11
security parameter index 10-21 SuSEfirewall2 4-32
Security Policy 1-3 Swatch 12-21
security policy 1-20 switch 11-4
send_redirects 3-36 SYN 3-24, 3-25, 3-28
Sendmail 9-5 SYN attacks 3-28
sequence number 3-23, 3-27 SYN cookies 3-28
service security 1-32 sysctl 3-32
Service Type 3-11
session key 5-8, 10-16 T
SHA 10-8 TCP 3-12, 3-22
shared library loader 6-10 TCP/IP protocol suite 3-3
shared secret 10-17 tcp_fin_timeout 3-35
smart relay 9-12 tcp_keepalive_probes 3-35
Smartcards 1-8 tcp_keepalive_time 3-35
smb.conf 1-33 tcp_retries1 3-35
SMS 12-21, 12-27 tcp_syncookies 3-35
SMTP 9-13 tcpdump 3-29, 10-16, 10-30, 11-5, 12-15, 12-29
smurf attack 3-18 telnet 10-4, 11-5
smurf attacks 3-33 theft 1-4
SNAT 4-4 Time Exceeded 3-17
Sniffer 11-4 Time To Live 3-12
sniffer 5-3 TIS firewall toolkit 7-6
sniffing 1-14 Token Ring 11-4
Sniffit 11-5 top 13-10
Snort 12-15 traceroute 12-30
socks 1-20, 8-3 transparent caching 7-4
socks protocol 6-3 transparent proxying 4-5, 4-35
Socks server 1-24 transport mode 10-7
Socks servers 7-10
Tripwire 12-8, 12-10
socksified 6-10
tripwire 12-31
source IP address 3-12, 3-18
tripwire --check 12-13
Source NAT 4-4
Trojan horse 1-16
source port 3-21, 3-23, 3-27
tsocks 6-6
Source Quench 3-16, 3-18
TTL 3-12, 3-17
spam 9-15
tunneling 1-28
spam score 9-16
tunneling mode 10-7
spamc 9-17
twadmin 12-12
spamd 9-17
Type of Service 3-11
spare parts 1-6
Squid 7-6, 7-8
SSH 1-8, 11-5

Student Notebook
U
UDP 3-12, 3-19
Uninterruptible Power Supply 1-5
UnitedLinux C-1
UNIX socket 9-18
Urgent flag 3-23
user defined chain 4-6
userid 2-12
UUCP 9-6
V
VERS 3-11
Version 3-11
Virtual Private Network 10-3
Virtual Private Networking 1-28
Virus 1-16
virus protection 2-9
vlock 5-15
VPN 10-4
W
WAIS 7-3
warez 1-12
web server 1-27, 8-9
well-known port 1-26
whois 12-30
WinNuke 3-27
World Wide Web 1-24
Worm 1-16
wrapper program 6-10
X
X authentication 5-6, 5-16
X clients 5-6
X forwarding 5-16
xeyes 5-17
xinetd 2-13
xlock 5-15
Y
yast 4-32
Z
zone transfer 8-4
zoo 9-24

V3.0
backpg
Back page
®

Linux Network Administration II, Network Security and Firewalls - Student Notebook (IBM Learning, 2003, Course Code LX24)

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Linux Network Administration II, Network Security and Firewalls - Student Notebook (IBM Learning, 2003, Course Code LX24)

Încărcat de

Drepturi de autor:

Formate disponibile

V3.

Front cover

IBM Certified Course Material

October 2003 Edition

Course Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Certification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Unit 1. Introduction to Network Security and Firewalls . . . . . . . . . . . . . . . . . . . 1-1

Unit 2. Installing and Securing Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

© Copyright IBM Corp. 2000, 2003 Contents iii

Filesystem Hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-15

Unit 3. The TCP/IP Protocol Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Unit 4. Packet Filtering and Network Address Translation . . . . . . . . . . . . . . . . 4-1

iv Linux Network Administration II © Copyright IBM Corp. 2000, 2003

TOC iptables Basic Syntax (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12

Unit 5. Secure Shell and Secure Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Unit 6. Socks Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

© Copyright IBM Corp. 2000, 2003 Contents v

Socksifying Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-10

Unit 7. Proxy Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Unit 8. Securing DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Unit 9. Securing E-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

vi Linux Network Administration II © Copyright IBM Corp. 2000, 2003

TOC Installing SpamAssassin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18

Unit 10. Virtual Private Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Unit 11. Hackers’ Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

© Copyright IBM Corp. 2000, 2003 Contents vii

Nessus Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-14

Unit 12. Detecting and Countering Firewall Intrusions . . . . . . . . . . . . . . . . . . 12-1

Unit 13. Good Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1

viii Linux Network Administration II © Copyright IBM Corp. 2000, 2003

TOC Appendix A. Introduction to Cryptography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Appendix B. Checkpoint Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

Appendix C. Certification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1

© Copyright IBM Corp. 2000, 2003 Contents ix

x Linux Network Administration II © Copyright IBM Corp. 2000, 2003

© Copyright IBM Corp. 2000, 2003 Trademarks xi

xii Linux Network Administration II © Copyright IBM Corp. 2000, 2003

Uempty Course Description

© Copyright IBM Corp. 2000, 2003 Course Description xiii

xiv Linux Network Administration II © Copyright IBM Corp. 2000, 2003

© Copyright IBM Corp. 2000, 2003 Agenda xv

xvi Linux Network Administration II © Copyright IBM Corp. 2000, 2003

Uempty Certification Information

Linux Professional Institute Statement

© Copyright IBM Corp. 2000, 2003 Certification Information xvii

xviii Linux Network Administration II © Copyright IBM Corp. 2000, 2003

Uempty Unit 1. Introduction to Network Security and

What This Unit Is About

What You Should Be Able to Do

How You Will Check Your Progress

Figure 1-1. Objectives LX243.0

1-2 Linux Network Administration II © Copyright IBM Corp. 2000, 2003

Figure 1-2. Security Policy LX243.0

1-4 Linux Network Administration II © Copyright IBM Corp. 2000, 2003

Figure 1-3. Physical Security LX243.0

1-6 Linux Network Administration II © Copyright IBM Corp. 2000, 2003

Figure 1-4. Network Security LX243.0

Authentication and Authorization

Figure 1-5. Authentication and Authorization LX243.0

1-8 Linux Network Administration II © Copyright IBM Corp. 2000, 2003

Hackers, Crackers and Script Kiddies

Figure 1-6. Hackers, Crackers and Script Kiddies LX243.0

1-10 Linux Network Administration II © Copyright IBM Corp. 2000, 2003

Uempty To a system administrator, there is no difference in approach to hackers, crackers and

_^% """

6"""$ 9"$