linux network administration ii, network security and firewalls - student notebook (ibm learning,...

V3.0

cover

��
Front cover
Linux NetworkAdministration II: Network Security and Firewalls (Course Code LX24)

Student NotebookERC 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:

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 United States, other countries, or both.

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.

AIX® DB2® Domino™Lotus® MQSeries

The information contained in this document has not been submitted to any formal IBM test and is distributed on an “as is” basis withoutany warranty either express or implied. The use of this information or the implementation of any of these techniques is a customerresponsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. Whileeach item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results willresult 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 restrictionsset forth in GSA ADP Schedule Contract with IBM Corp.

October 2003 Edition

Student NotebookV3.0

TOC
Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

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

Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

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

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

Unit 2. Installing and Securing Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2Installing Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Apply Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Kernel recompile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6Hardening Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8BIOS Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9Boot Loader Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10User Account Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11Disable Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

© Copyright IBM Corp. 2000, 2003 Contents iii

Student Notebook

Filesystem Hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-15Disable Ctrl-Alt-Del . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-16/etc/issue, /etc/issue.net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-17/etc/motd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-18$TMOUT Shell Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-19Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-20Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-21

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

Unit 4. Packet Filtering and Network Address Translation . . . . . . . . . . . . . . . . 4-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4Chains (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6Chains (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7Packet Filtering in Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8The iptables Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9iptables Basic Syntax (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10


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


TOC
iptables Basic Syntax (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14iptables Initial Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15Protect against Spoofed Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16Configure ICMP Echo Request/Reply Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17Configure other ICMP Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18Configure Outgoing TCP/UDP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19Identd Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20iptables Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22iptables Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23IP Masquerading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25Configuring IP Masquerading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26Configuring NAT for Difficult Situations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28Saving and Restoring iptables Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30Restoring iptables Rules on Startup (Red Hat) . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31SuSEfirewall2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32FWBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34Other iptables Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-37Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-38
Unit 5. Secure Shell and Secure Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Telnet, ftp, rexec, rsh, rcp Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3SSH Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4SSH Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5ssh Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6scp Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7sshd Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8ssh/sshd Host Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9sshd User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10RSA Challenge-Response Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12DSA Challenge/Response Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13Protecting Your Private Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14SSH X Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16SSH Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18SSH Firewall Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21

Unit 6. Socks Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2Socks Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3Advantages and Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4Linux Socks Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6Dante Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7Sample /etc/sockd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8Starting and Stopping sockd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9


© Copyright IBM Corp. 2000, 2003 Contents v

Student Notebook

Socksifying Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-10Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-12Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13

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

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

Unit 9. Securing E-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2E-mail Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3Mail Gateway and Mail Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4Mail Servers for Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5Configuring Sendmail as Mail Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7Configuring Postfix as Mail Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9Configuring Sendmail as Mail Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10Configuring Postfix as Mail Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12Configuring DNS for Mail Relaying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-13Limiting Message Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-14Blocking Junk E-mail (Spam) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15SpamAssassin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-16


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


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

Unit 11. Hackers’ Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2Categories of Hackers’ Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3Sniffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4Ethereal Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6Ethereal Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7Fingerprinters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8Port Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-9Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10Nmap Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11Nmap Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12Intrusion Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-13


© Copyright IBM Corp. 2000, 2003 Contents vii

Student Notebook

Nessus Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-14Nessus Installation (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-15Nessus Installation (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-16Nessus Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-17Nessus Output Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-18Other Hackers’ Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-19Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-21Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-22

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

Unit 13. Good Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-2Computer Security is a Way of Life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-3User Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-4Administrator Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-5Custom Programs and Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-6Network and System Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-8Day-to-Day Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-10Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-12


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

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


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:

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 United States, other countries, or both.

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.

AIX® DB2® Domino™Lotus® MQSeries


© Copyright IBM Corp. 2000, 2003 Trademarks xi

Student Notebook


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


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


Uempty
Agenda
Day 1

WelcomeUnit 1 - Introduction to Network Security and FirewallsUnit 2 - Installing and Securing LinuxExercise 2 - Installing and Securing LinuxUnit 3 - The TCP/IP Protocol SuiteExercise 3 - The TCP/IP Protocol Suite

Day 2

Unit 4 - Packet Filtering and Network Address TranslationExercise 4 - Packet Filtering and Network Address TranslationUnit 5 - Secure Shell and Secure CopyExercise 5 - Secure Shell and Secure Copy

Day 3

Unit 6 - Socks ServiceExercise 6 - Socks ServiceUnit 7 - Proxy ServiceExercise 7 - Proxy ServiceUnit 8 - Securing DNSExercise 8 - Securing DNS

Day 4

Unit 9 - Securing E-mailExercise 9 - Securing E-mailUnit 10 - Virtual Private NetworksExercise 10 - Virtual Private Networks

Day 5

Unit 11 - Hackers' ToolsExercise 11 - Hacker's ToolsUnit 12 - Detecting and Countering Firewall IntrusionsExercise 12 - Detecting and Countering Firewall IntrusionsUnit 13 - Good Practices


© Copyright IBM Corp. 2000, 2003 Agenda xv

Student Notebook


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


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


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

Figure 1-1. Objectives LX243.0

Notes:

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


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


Uempty

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 theydon't consider it as such. Bandwidth costs money. And there are plenty more examples.

Security Policy

Document describing the way computer equipment may/may not be used

Preventing unauthorized use of computer equipmentEnsuring uninterrupted service to legitimate users

Should be decided by management

Should be implemented and enforced by hardware/software setup

Different aspects:Physical securityNetwork securityAuthenticationAuthorization

Evolves over time



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.




Uempty

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

Physical Security

Ensure that nobody can access computer hardwareLocks on doorsAccess codesSigning-in of staffPhysical protection of cabling

Physical environmentUninterruptible Power Supply (UPS)Fire suppression systemAir Conditioning (heat, moisture)

Physical breakdown of computer hardwareSpare componentsBackups (consider off-site storage)



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).




Uempty

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.

Network Security

Ensure that no unauthorized user can access the system over the network

InternetModemother WANLAN

Needs to be done for every networked system



Student Notebook

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

Authentication and Authorization

Authentication: Establishing who you areUsername/PasswordPublic key cryptographySmartcardsBiometrics

Authorization: Determining what you may doUsually dependent on group membership




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

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.

Hackers, Crackers and Script Kiddies

A hacker is someone who wants to satisfy his curiosityMeans no harmMay cause harm accidentally

A cracker is someone who wants to gain somethingAccess to your system to use resourcesAccess to data (e.g. credit card numbers)PublicityRevenge

A Script Kiddie is someone who uses hackers tools without understanding what they do

To a firewall administrator, there is no differenceAll can cause harmFrom the type of activity you cannot distinguish them




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

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.

Motivation of Hackers and CrackersCuriosity

Challenge

Prestige

Corporate, political espionageConfidential information, intellectual propertyProprietary software

Access to resourcesDisk spaceCPU time

MonetaryCredit card numbers

Base of operation for attacks on other sitesDDoSUntraceable junk mail




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

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.

Types of Attack (1)

ScanningWhich services are enabledWhich software and version is used

SniffingMonitoring data (e.g. passwords) in transit

Break-inGain access to a computer, preferably as superuser

Brute ForceTry every possible combination until one works

Man-in-the-MiddleAct as the server to a clientAct as a client to the server




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

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.

VirusMalicious program that attaches itself to other programsA macro virus resides in a macro which is typically stored in a data file

WormSelf-replicating malicious program

Trojan HorseApparently useful program with a malicious component

Denial of Service (DoS)Prevent legitimate users from workingUsually done by crashing or overloading the system or network

Distributed Denial of Service (DDoS)DoS attack from many different sources simultaneously

Types of Attack (2)




Uempty

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.

What You Have to Lose

Loss of resourcesDisk spaceBandwidthCPU time

Loss or alteration of data

Loss or impairment of service

Loss of reputation, goodwill, trust

Disclosure of personal, proprietary or confidential information

Financial lossStolen credit card numbers

Legal, criminal action against you



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.




Uempty

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.

Forms of Protection

No internet connectionSafe but users will set up their own access

Choke point (firewall)One device where all traffic passes throughCan log activityCan limit activityNeeds careful setup

No central protectionRequires protection on every hostGives virtually unlimited internet access



Student Notebook

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.

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 RouterDMZ (DeMilitarized Zone) or screened subnetNetwork Address Translation or IP MasqueradingSocks ServerProxy ServerMail GatewayDNS ServerTunneling Device

Always customized to local environment and needs




Uempty

Figure 1-13. Position of a Firewall LX243.0

Notes:

The firewall usually sits between the company's network and the Internet.

Position of a Firewall

The Internet

Company Network

FirewallFiltering Router

DMZ/Screened Subnet

NAT/IP Masquerading

Socks Server

Proxy Server

Mail Gateway

DNS Server

Tunneling Device



Student Notebook

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 corridorbetween North and South Korea called the Demilitarized Zone. In this area every movement will be scrutinized and possibly shot at.

DMZ and Packet Filters

The Internet

DMZ

Company Network

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)

√

√

X

X X

Packet

Filtering

Router

Packet

Filtering

RouterPacket

Filtering

Router

Company Network

DMZ




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

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.

NAT, Socks and Proxies

The Internet

DMZ

Company Network

NAT

Socks

Proxy

Client

Webserver

A NAT, Socks or Proxy

accepts a client connection,

verifies it and sets up a

second connection to the

Internet to retrieve the data

Packet

Filtering

Router

Packet

Filtering

Router




Uempty

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 internetmail (SMTP) and Lotus Notes. A “mail relay” does not do a protocol conversion. In common speak however, the two terms areinterchangeable.

E-mail

The Internet

DMZ

Company Network

Mail

Gateway

Mail

ServerClient

SMTP

POP/IMAP

All email to and from the

Internet should pass through

the Mail Gateway.

All connections through the

it are SMTP connections.

Filtering based on IP address

and port number (SMTP=25).

POP and IMAP are only used

on the Company Network.

Packet

Filtering

Router

Packet

Filtering

Router



Student Notebook

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).

Domain Name System

The Internet

Company Network

DNS

Server

DNS

Server

The DNS server in the DMZ

resolves queries on the DMZ

and on the Internet.

The internal DNS resolves

queries for the Company

Network, and forwards all

other queries to the DNS

server on the DMZ.


and port number (DNS=53)

DMZ

Packet

Filtering

Router

Packet

Filtering

Router




Uempty

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.

The Company Webservers

The Internet

DMZ

Company Network

Company

Webserver

Intranet

Server

An internal client can

access both the Intranet

server and the Internet

server. An external client

can only access the

Internet Server.


and port number (HTTP=80)

Packet

Filtering

Router

Packet

Filtering

Router

Client



Student Notebook

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

Company Network

Virtual Private Networking

The Internet

DMZ

Intranet

Server

Customer Network

Client

With VPN, traffic between one network

and another is sent encrypted over

the Internet, creating one Virtual Network

Packet

Filtering

Router

Packet

Filtering

Router

Tunneling

Device

Firewall

with

Tunneling




Uempty

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.

The Complete Picture

The Internet

DMZ

Company Network

Packet

Filtering

Router

Packet

Filtering

Router

Company

Webserver

NAT

Socks

Proxy

Mail

Gateway Tunneling

Device

DNS

Server

Mail

Server

Intranet

ServerDNS

Server

Customer Network

Firewall

with

Tunneling

Client

Client

FirewallWebserver



Student Notebook

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

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 firewallModem connectionsSoftware/Data brought in/out on physical media

Connections to systems outside the firewallCompany web server

Physical theft, break-in attempts, bribery, fire, ...




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

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

Network Security Techniques Usage

Technique Intranet Server Internet Server Firewall

Physical security yes yes yes

Packet Filtering maybe yes yes

Encrypted communications

maybe yes yes

NAT N/A N/A yes

Socks N/A N/A yes

Proxies N/A N/A yes

Individual service security

maybe yes yes if fw runs 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




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

Figure 1-23. Checkpoint LX243.0

Notes:

Write down your answers here:

1.

2.

3.

4.

5.

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?




Uempty

Figure 1-24. Summary LX243.0

Notes:

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



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:

• Checkpoint questions • Machine exercises


© Copyright IBM Corp. 2000, 2003 Unit 2. Installing and Securing Linux 2-1

Student Notebook


Notes:

��

��

� ��

��




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

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

��

'��

�� !�� !��

'��

*��+'6��7�7��9�� ;��"��#��#�$�"�#%�&�*�*�+.0��;��"��#��$��#�$�"�#��+�3��!��4




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

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.

+�� %��"��

+�� 9��'�� < ��>�� < ��>��'��

@��9��J��$��&��9��9��9��

+�� 9��#��




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

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

5��$��

Q�<#��

Q��

X��

'��

'��Y��Y'��

��"��

��

#��[\+<X\

]�� 9��

��




Uempty

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.

6�7�8"��$��"�

��9��

�� ^��Q�<#��

'��+

#��Q�<#��

_��^�Q�<#� ��9��Q��+<#��Q��Q�<#��9� ��

_��^��%��"""



Student Notebook

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.

6""��"�$��9"�$

��<��7]XQ�� ]�� _��Y��$�"�"��&��`��

��<^��{ ��{��{��{��"��

7]XQ^��{ ��{��"�� Y��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��!��

"��!�#$#%&'($�#��)��(�*�+,-)./�01�2��

��3��

��

��

��$�

��#$#%&'($�#��)��(�*�+,-)./�01�2��

��

��




Uempty

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

:��"��8"��$��"�

!�� |X�� $��"""&'��

\�� _��X��

��{��{��



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.




Uempty

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.

;�� 7��

#��$

'��^X�� "��"��"��}��"��\��^��!��!�"�<��"

#��$^'��#��#��$��"�<��#��#��$�$#��

��!�"�<��$��

\��^��$�� &��$�� &



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.




Uempty

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.

�� 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��



Student Notebook

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.

;�� 8�� ;�

�� Y��Y'��

�� #��#��!� ��5:��=

'��^��




Uempty

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.

#��#��>�#��#��

]��9��

��

_��^�#��"��|

��

9�� 1��: ��

��1��5��



Student Notebook

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.

#��#�"�$

��

��

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

;��;

;�9�� 1��: ��;

;��1��5�� ;

;��;

;��;

;�)�� >��;

;��=��;

;��5��<=9��;

;��;

;�-��;

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

;��;

;��;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;




Uempty

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.

@B&�:B�7�� G��

#�� $��&

��

~��Y�� ^

~�� Y��[�<+!�"�� ^��"��B&�:BJR[\\



Student Notebook


Notes:


1.

2.

8��!�"��]��"�

�" _��"

�" @�� 9��J




Uempty


Notes:

7��

��

��



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


Notes:

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




Uempty

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.

TCP/IP Layering

TCP/IP Applications

TCP UDP

ICMP

IP

Network Interface



Student Notebook

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.

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"




Uempty

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.

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



Student Notebook

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.

IP Address Assignment

IP addresses assigned by IANAInternet Addressing and Naming Agencyhttp://www.iana.net

5 "classes":A: 8 bits assigned, 24 freeB: 16 bits assigned, 16 freeC: 24 bits assigned, 8 freeD: multicast - assigned individually by IANAE: experimental - not used any more

Reserved classes for private networks:A: 10.0.0.0B: 172.16.0.0 through 172.31.0.0C: 192.168.0.0 through 192.168.255.0

Other special:Class A 127.0.0.0 used for loopback interface




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

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.

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




Uempty

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.

IP Address Usage

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0 0 0 0 1 0 1 0| Network Identifier | Host ID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|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

Use "subnetmask" 255.255.255.0 to identify what part is network ID and what part is host ID



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.




Uempty

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.

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 |

. .

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



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.




Uempty

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.

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 attackto 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



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.




Uempty

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.

The ICMP Protocol

Internet Control Message Protocol

Defined in RFC 792 and 950

Used to report network errors back to senderexcept errors from ICMP itself

Used to discover information about another host

Uses IP for packet forwarding



Student Notebook

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.

ICMP Packet Format

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TYPE | CODE | Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ICMP Data (depending on type) |

| |

. .

. +-+-+-+-+-+-+-+-+-+-+-+

. | Padding |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




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

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.

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 firewallFrom 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 downCan be used for DoS attacks

Redirect (5): Use another router to route these packetsCan be used to redirect traffic over another route so that it can be sniffed




Uempty

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.

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



Student Notebook

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.

UDP Packet Format

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source port | Destination Port |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Length | Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| UDP data |

. .

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Uempty

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.

Important UDP Header Fields

Source Port: Port where packet originates fromCan be spoofed to simulate a "secure" port (<1024)Can be spoofed to simulate a well-known service

Destination Port: Port where packet goes toUsed 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



Student Notebook

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.

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




Uempty

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.

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 |

. .

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



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.




Uempty

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.

TCP Connection Setup

Initiator Server

First packet:

SYN bit set, Sequence number a (a should be random)

Third packet:

ACK bit set, Acknowledgment number b+1

May contain data

Second packet:

ACK bit set, Acknowledgment number a+1

SYN bit set, Sequence number b

(b should be random)



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.




Uempty

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.

Important TCP Header Fields

Source Port: Port where packet originates fromCan be spoofed to simulate a "secure" port (<1024)Can be spoofed to simulate a well-known service

Destination Port: Port where packet goes toUsed to select the target service

Sequence number: Which packet this is in the streamNeeds to be in window range

URG: Urgent dataCertain 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



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.




Uempty

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.

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>tcpudp



Student Notebook

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.

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




Uempty

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.

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

... ...



Student Notebook

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)

Kernel Configuration Options

Default options set at compile time

Can be changed in virtual /proc filesystemecho 1 > /proc/sys/net/ipv4/ip_forward

Should be configured before networking is startedSettings in /etc/sysctl.conf

net.ipv4.ip_forward = 1Red Hat: Activated by /etc/rc.d/rc.sysinitSuSE: Activated by /etc/init.d/boot.sysctl

Note: conflicts with /etc/init.d/boot.ipconfig

Extensive documentation in /usr/src/linux/Documentation/proc.txt




Uempty

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.

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 = 100net.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



Student Notebook

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.

Kernel Configuration Options (IP)

Default TTLnet.ipv4.ip_default_ttl = 255

Local port range for TCP and UDP connectionsnet.ipv4.ip_local_port_range = 1024 32000

No Path MTU Discoverynet.ipv4.ip_no_pmtu_disc = 1

IP fragmentation memory thresholds and timeouts:net.ipv4.ipfrag_high_thresh = 262144net.ipv4.ipfrag_low_thresh = 196608net.ipv4.ipfrag_time = 30




Uempty

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.

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



Student Notebook

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.

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 laterChanges to the "all" interface apply to all interfaces that are already configured

Do not accept/send ICMP redirectsnet.ipv4.conf.default.accept_redirects = 0

net.ipv4.conf.default.send_redirects = 0

Do not accept source-routed packagesnet.ipv4.conf.default.accept_source_route = 0

Log packets with source address with no known routenet.ipv4.conf.default.log_martians = 1

Source address validation:net.ipv4.conf.default.rp_filter = 1




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


Notes:


1.

2.


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.




Uempty


Notes:

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



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


Notes:

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




Uempty

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.

Packet Filtering

Packet Filtering: Filtering IP packets based onNetwork InterfaceProtocol (UDP, TCP, ICMP, ...)Source and/or Destination IP addressSource and/or Destination TCP or UDP PortDirection of TCP Connection SetupExistence of TCP connectionICMP Packet TypeMAC addressUser ID of sending/receiving process

Possible actions:Accept: Allow packetDrop: Don't allow packet

A "rule" is a statement which combines a set of criteria with an action to perform



Student Notebook

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.

Network Address Translation

Changing Source and/or Destination IP address and/or Port of packets in transit

Source NAT (SNAT): Change source IP addressIP Masquerading

Destination NAT (DNAT): Change destination IP addressPort ForwardingTransparent Proxying

Packet Mangling: Change TCP/IP optionsPriorityTTL




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

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.

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 hostOUTPUT: For packets send from this hostFORWARD: For packets send through this hostPREROUTING: For DNATPOSTROUTING: For SNAT

A user can add his own chainsA rule in a default chain then refers to this chain

Rules in a chain are checked in orderWhen a rule does not match, check nextWhen a rule matches, execute the action

Accept, Drop or go to user-defined chain




Uempty

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.

Chains (2)

PREROUTING

Sanity Check

Destination

= local?

INPUT

FORWARD

OUTPUT

POSTROUTING

Local Process

Incoming Packets

Outgoing Packets

ip_forward

on?

y n

y

Discard

packet

n



Student Notebook

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.

Packet Filtering in Linux

Packet Filtering done at kernel levelUsually compiled as kernel modules which are loaded automatically

Configuration done with user space toolsLinux 2.0 kernel: ipfwadmLinux 2.2 kernel: ipchainsLinux 2.4 kernel: iptables

Downwards compatibility ensured

Additional features:LoggingStatistics




Uempty

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.

The iptables Tool

User level tool for configuring kernel filter rules

Different modes of operation:Flush all rulesSet default action for a chainAppend, Insert, Replace, Delete rulesDisplay rulesDisplay, reset statisticsCheck packet against a chain

iptables-save and iptables-restore can be used to save and restore all rules to/from a file



Student Notebook

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.

iptables Basic Syntax (1)

iptables [-t table] command [chain] [parameters] [-j target]

Tables:filter (default): For filtering rulesnat: For NAT rulesmangle: 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




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

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.

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 typeUse ! to negate options

Targets:Basic: ACCEPT, DROPExtended (require kernel module): REJECT, LOG, ...




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

Figure 4-10. Scenario LX243.0

Notes:

This is the scenario that will be used in the following examples.

Scenario

The Internet

Company Network

10.0.0.0/24

Firewall

in-a-box

eth0: 10.0.0.1

ppp0: 62.186.134.70




Uempty

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.

iptables Initial Setup

# 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

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



Student Notebook

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.

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 networkYourselfAny reserved IP addressThe loopback interfaceUniversal 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




Uempty

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.

Configure ICMP Echo Request/Reply Filtering

Allow ICMP Echo Request/Reply (type 8/0)

Can be used in smurf DoS attacks thoughSending echo requests to a broadcast address with spoofed source address floods a server with repliesSo 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





Student Notebook

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.

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)












Uempty

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.

Configure Outgoing TCP/UDP Connections

Allow outgoing TCP and UDP connectionsSource 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\




Student Notebook

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

Identd Considerations

The IDENTD protocol (RFC 1413) identifies the owner of a connection

Used for FTPRequired for IRC

Uses TCP port 113

Incoming connections should not be denied but rejectedOtherwise: 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

ftp client

identd

ftp

daemon

ftp logon request1025 21

who is on port 1025?113tux is on port 1025

welcome, tux




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

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].

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]




Uempty

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

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 prefixFacility is always KERN

To limit the amount of logging, use -m limit extension (requires ipt_limit kernel module)

Use --limit to specify maximum averageUse --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:"



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.




Uempty

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.

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

Router

with

IP Masq.

Client Server

10.0.0.2 134.191.38.72

10.0.0.2:1287 -> 134.191.38.72:80 62.186.134.70:4011 -> 134.191.38.72:80

134.191.38.72:80 -> 10.0.0.2:1287 134.191.38.72:80 -> 62.186.134.70:4011

10.0.0.1

62.186.134.70

Intranet Internet



Student Notebook

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

Configuring IP Masquerading

Done with iptables in "POSTROUTING" chainTarget MASQUERADE used for dynamic IP addresses: Connections dropped when interface is downTarget 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




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

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

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 supportmodprobe ip_conntrack_irc ip_nat_ftp

And more...

Make permanent by adding this to /etc/rc.local or /etc/modules.conf




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_ftppost-install iptable_nat modprobe ip_nat_ftp



Student Notebook

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.

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




Uempty

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.

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/iptablesstop: Flush rules, delete user-defined chainsrestart: Same as stop/startsave: Save current rules in /etc/sysconfig/iptablespanic: Flush all rules, set all defaults to DROPstatus: Executes iptables -nL

Integrated in boot process before networking is startedchkconfig iptables on



Student Notebook

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.

SuSEfirewall2

SuSE comes with an elaborate firewall setup:yast: Configure internal/external interface and services offered - stored in /etc/sysconfig/SuSEfirewall2rcSuSEfirewall2: 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




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

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.

FWBuilder

GUI frontend that allows for easy creation/management of firewall rules

Supports other firewall rule types as well: ipfilter, OpenBSD PF and Cisco PIXhttp://www.fwbuilder.org




Uempty

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:

Other iptables Features

Transparent proxyingA packet that needs to be routed is sent to the local system (e.g. proxy) instead (DNAT)

Port forwardingA 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 inspectionOnly allows TCP packets through that belong to an existing connectionRequires ipt_state kernel module

Packet manglingChange IP and TCP options on packets in transit



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




Uempty


Notes:


1.

2.

3.

4.

5.


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?



Student Notebook


Notes:

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




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


Notes:

��

'��

'��##��

��##��

X��< ��##�




Uempty

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.

B� ��>�<��>��>��>��"� ��

��

�� #�� *��

��X��"�`��[�<+!�"��*�� '� ��'_#��



Student Notebook

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.

775��"�"�"

�� ^��"��"�#��'��$ ��Y]~��&

\�� ^��Y�� Y��

<�� ^��

!��

X�� # �� #��9��

X�� 9��Y�Y��Y��9




Uempty

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.

775�� "�

��^�� ^��"��"�

\�� ]��

�� ^��"� ��"��_�� 7_X��X��< ��##��

@��6��_\��^*�� "�#�� ^��"�� "��"��"



Student Notebook

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.

��:��

#��^��"��"��"��"��$�

�� ^��3��4^�!�� $��&��3�"��4^�]�� ^�X�� 8^�X��

]��[�<+!�"��

]��

��

��

��^��['�#�� 9��

!��$� ��&




Uempty

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.

��:��

#��^��"��"��"��<� ��$��"�<� ��

< ��^��3��4^�!�� $��&��^��^�]�� 8^�X�� 3�"��4^�]��

~�� ^��"��<� ��

\��Y �� ^��+��>!�� >��-!�� -



Student Notebook

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 isextremely hard to obtain it and thus decrypt the data. Also, because session keys change with each session, replay attacks and the likeare impossible.

�$�:��

'�� '��

#��"��"��

@��^]��]��Y� ��]#��9��9��Y� ��]#��9��$��9&

@��_��9��!�� 9�� $�&�




Uempty

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.

�#�$�5"��"�

!��9�� 9��9��9��9��" �

X �� 9��

X��^�X�9��"�� $��&J@�� 9��[�<+!�"��9��

X ��`��9�� "

@�� #��9�� 9��9��[�<+!�"��9��

��Y�Y��Y��9



Student Notebook

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.

�$�:��"�

~��^

�" "��$��&]�`��"��"�`��$��Y�� &

�" "��]#��$��&]�`��"��"�`��`��]#��$��Y��&

�" ]#��Y�� ]�`��]#��9�� $��&

�" ��]�`�� $��9&




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 isthat they have measured the amount of time that an experienced typist needs between keystrokes. This turns out not to be constant, butis 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 thesequence ’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 inpasswords that needed to be checked, compared to a brute-force attack. In practice, this meant that they would not need 65 days butonly 1.3 days to find the password of an arbitrary user.



Student Notebook

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.)

%7��8�� %��"��"�

X��]#��9�� !��9��[�<+!�"��9��[�<+!�"��" �

��

��

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

X��




Uempty

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.

;7��8�� %��"��"�

##��*��'#��]#�

\��'#��9��!��$��9��[�<+!�"��9��[�<+!�"��" �

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

X��



Student Notebook

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.

��"��0"��+��

�� 9��$��&��>��

�� Y �� 9��

'��^�_�� 9��

#��^��Y��9�� 9�� $$�� 9��

X��$$��3<� ��4��9��X��$$�� 9��X��$$��$��3<� ��4��9��




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

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

775��"�9��$��

@��##��

]�`��]�`��==�"�9��$��




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

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.

775�B��

##��$Y�&��$Y]&�� \��"�"�� """

~��^X�� X��^��3 "�� "��4�3��"��4�3��"��"��4�3<��9� 4

]��^X�� X��^��%�3��"��"��4�3 "�� 4�3 "�� "��4�3<��9� 4




Uempty

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.

775��9� �8"��$��"�

##�� +��

##��

+�� ^

��4>��4��4��4��44��$�%&!�4��%�$7��$.&�6��44��%%�42�>++" 9

��4>��4��4��4��%�$7��$.&�6��44��%%�4��44��$�%&!�42�>++" 9



Student Notebook


Notes:


1.

2.

3.

4.

5.

6.

8��!�"��]��"�

�" @�� J

�" ��##�� 9��J

�" @��##�� J

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

6" @�� 9��J

�" @�� 9��J




Uempty


Notes:

7��

\��

*�� *��

\��##�� 9��9�

#�� ^��"��"�� ^��"� ��"��

~�� ##�� ^�� ^�� ^��Y��9��$$^�� Y��9��$^��Y��



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


Notes:

��

'��#��9��

_��9��

��'��9��




Uempty

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.

7"�!��"�"�"

]~��

��9�� "�~��`�� "#��9�� "

#��9�� #��

��"�"�"� ��"��"��"��

��"�"�"�^��Y��"�"�"�^�� "��"��"��^��Y��"��"��"��^��

��"�"�"�

��"��"��"��

��

��"��"��"��^��



Student Notebook

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

�$��$�;��$��

��^\��Y��^��#�_�� \��

��{��9��{�� *��^��

'��^'��9��X'�'��9��+�<��9��^��'_#��7��_�\




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

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".

��7"�!�7��

_��#��9�^�� ^��"��9�"��"��<�� ]��

'��^�� ^��"��"��~�� #��9��9��

\��9�^�� ^��"�� 9��'��

+��"""




Uempty

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.

'�� ^�$�#��#��<�#�""�#$��$�$��#�"�<��<��J#��!��!��!��!��

_��^�'��$��]�+��^

�� $��$��

;�� "��$�8"�<��"�



Student Notebook

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.

7�� #��#"�!$��"�<

��!��?��

��!�$��$��$�7��=��

��!��%�$7��$.&�6��=��

��!��)��

��!��)��

��!��)��

��!�.��9��

��!�7�&��9��

��+��

��!�$��%&��!��: ��$��%&

�!��?��

�

��/��-�/��3��

��!��!�$%6��7��/��

�!��

�

��>��3��

��!�$��%&��!��$��%&��

��!��

�




Uempty

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.

7��$�7�"��"�!$

#�� 9��/��/��/��/��/��/��/��/��



Student Notebook

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

7"�!�<�� "�

!�� \��X'��{��9��{!��\��X'�� 9��

��^��9�"�� !��!�$��%&��!�� !��!��!�$��$��$�7��!��!��/��&��/��!��

�

!�� ^��/��

\��9�� ^��?,� �"?=>,��/��




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


Student Notebook


Notes:


1.

2.

3.

4.

8��!�"��]��"�

�" ��9�� 9J

�" @��9�� J

�" @��9��J

�" �� '��9��J




Uempty


Notes:

7��

\��9�� 9��

\��

\��9��

\��9��^�_!��'��\��9��

'��



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:

��

'��

��

_��

��

��#`��




Uempty

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.

��"��"�"�"

]~��

�� "�~��`��X]�� "

�� #��

��"�"�"� ��"��"��"��

��"�"�"�^��Y��"�"�"�^�� "��"��"��^��Y��"��"��"��^��

��"�"�"�

��"��"��"��

��

7!\�� ^��"��"��"�� 7!\��



Student Notebook

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.

�$��$�;��$��

��^��'_#��9 *��*��

Q��$� �� &Q��Q��Q��

��

'��^<��9�� 7��_�\




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

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.

��"��7��

� ��^�� ^��"� ��"��+�� # ��\\��~\�� *�� ]��

#`�^�� ^��`�"��"��\\��~\��*�� # ��$��&��]��

\�#�~��\��9��$�� ^��"��"��&*�� ~\�� """




Uempty

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.

8"�<��<"��"��7��

� ��"�� "��^?��$��$!7�7�?��0��>��0��: 0�� 3��=��,��!;��=��5��,�� >�� $��%&��,��: 0��

� ��"�� "��^?��$��$!7�7�?��0��: 0�� 3��=�� ;��=��5��,�� >�� $��%&�� : 0��



Student Notebook

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.

�� >�8"�<��$�7��7��$

��#`�^��$��

��#`��`�"��$��&

#��#`��$��$��




Uempty

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.

#��#��$��"�<

��$��$!7�7�

��

��7�0-

�� 3��$��$��%��

��3��

��3��

�� 3��

��

��$��%��%��%��

��

��

��

��

�� 3��

�� 3��

��



Student Notebook

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.

7��G�� B>�7"�!>��"��

_�\��+��`��

#��9� ��

�� J

_� _� ��

# �� ~�� #�� #��

�� 9�� \��

�� $��&

�� J _� _� X��>��

��

�� 9��

@�� J \��X'��+� \��X'� '� �� \��

'_#��9 ��J �� #��\�� J

�� 9��9��

_�� "




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 allapplications, if it exists.



Student Notebook


Notes:


1.

2.

3.

4.

5.

8��!�"��]��"�

�" �� 9J

�" @�� J

�" @�� J

�" �� J

6" �� #`�J




Uempty


Notes:

7��

\�� $��&

\��X]��

\�� X]�

\�� #`�



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


Notes:

Objectives

List DNS consideration on firewalls

Configure DNS on firewalls




Uempty

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.

DNS Considerations

Don't give away internal information to internet usersMight be used by hackersMight contain reserved IP addresses

Allow internal users to retrieve internet DNS informationNeeded when using NAT or SocksNot strictly needed when using Proxies (the proxy resolves the IP address)

Ensure that regular and reverse DNS queries match

Don't allow dynamic updatesMight be used to insert malicious data

Don't allow large transfers to anybody (e.g. zone transfer, dig)

Might be used for DoS attacks



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 theInternet 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.




Uempty

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 Internetdomain to all /etc/resolv.conf files. Users can then use the hostname w3, which resolves to w3.intranet.acme.com, and www, whichresolves to www.acme.com

DNS Name Considerations

One name registration:www.acme.com: internet serverw3.acme.com: intranet server

One registration, two domains:www.acme.com: internet serverwww.intranet.acme.com: intranet server

Two registrations:www.acme.com: internet serverwww.acme.net: intranet server

Made-up Top-Level Domain (TLD)www.acme.com: internet serverwww.servers.acme: intranet server



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.




Uempty

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.

DNS Servers

The Internet

DMZ

Company Network

DMZ

DNS

Server

Intranet

DNS

Server

Authoritative for the DMZ

Authoritative for the intranet and DMZ

Forwards internet queries to DMZ DNS Server

Packet

Filtering

Router

Packet

Filtering

Router



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.




Uempty

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.

Scenario (DMZ Situation)

The InternetDMZ

62.186.134.0/24

Company Network10.0.0.0/24

Packet

Filtering

Router

Packet

Filtering

Router

DMZ

Pr. DNS

Server

Intranet

DNS

Server

DMZ

Sec. DNS

Server

62.186.134.70

62.186.134.71

62.186.134.1

62.186.134.2

10.0.0.1

10.0.0.40

foo.acme.com

bar.acme.com

widget.acme.com

Company

Webserver

www.acme.com

Company

FTP server

ftp.acme.com

62.186.134.21

62.186.134.20

Intranet

Webserver

w3.acme.com

10.0.0.60



Student Notebook

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.

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; };

};




Uempty

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.

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



Student Notebook

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.

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.




Uempty

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.

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; };

};



Student Notebook

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.

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";

};




Uempty

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.

Intranet DNS Server Name Zone File

# cat /var/named/named.acme.com

$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



Student Notebook

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.

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.




Uempty

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.

DNS Query Resolving

Intranet client:Client asks widgetwidget forwards query to foo or bar for internet queriesfoo or bar resolve query on internet

DMZ client:Client asks foo or barfoo or bar resolve query on internetFor intranet queries: store in /etc/hosts

Internet client:Client asks foo or barfoo or bar answer query



Student Notebook

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).

DNS Packet Characteristics

Regular client -> Server DNS queryInitially done through UDP, source port > 1023, destination port 53If 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 transferOnly done through TCP, source port > 1023, destination port 53




Uempty

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.

DNS iptables Rules

# 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 the DNS server itself:

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



Student Notebook


Notes:


1.

2.

3.

4.

5.


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?




Uempty


Notes:

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



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


Notes:

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




Uempty

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.

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



Student Notebook

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.

Mail Gateway and Mail Server

The Internet

DMZ

Company Network

Mail

Gateway

Mail

Server ClientSMTP

POP/IMAP

Packet

Filtering

Router

Packet

Filtering

Router




Uempty

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.

Mail Servers for Linux

Sendmail (http://www.sendmail.org)Traditional implementation70% market shareLarge security historyVery flexibleAvailable by default in Red Hat Linux

Postfix (http://www.postfix.org)Developed as a secure replacement for SendmailWell thought outDefault in SuSE Linux

Qmail (http://www.qmail.org)Developed as a secure replacement for SendmailModular designGNU Public License

Exim (http://www.exim.org)



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.




Uempty

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.

Configuring Sendmail as Mail Gateway

Allow relaying of email to/from acme.com domaincd /etc/mailvi access

Add: acme.com RELAYvi mailertable

Add: acme.com smtp:mail.acme.commake

Allow connections via all interfacesvi /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 Sendmailservice sendmail restart



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.




Uempty

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.

Configuring Postfix as Mail Relay

Allow relaying of mail to/from acme.com domaincd /etc/postfixvi access

Add: acme.com OKpostmap access

vi transportAdd: acme.com smtp:mail.acme.compostmap transport

vi main.cfmyhostname = mailrelay.acme.commydomain = acme.commyorigin = $mydomaininet_interfaces = allmynetworks = 192.168.1.0/24relay_domains = $mydestination, $mydomain

rcpostfix restart



Student Notebook

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.

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’)

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

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 RELAYmakeservice sendmail restart

Enable POP3 serverchkconfig ipop3 on

Add local users

Configuring Sendmail as Mail Server




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

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.

Configuring Postfix as Mail Server

Add local domain and gateway info to config filevi /etc/postfix/main.cf

myhostname = mail.acme.commydomain = acme.commyorigin = $mydomaininet_interfaces = allmydestination = $myhostname, $mydomainrelayhost = fw.team1.com

Allow relaying from local clients:vi /etc/postfix/access

acme.com RELAY

Restart Postfixrcpostfix restart

Allow POP3chkconfig qpopper on




Uempty

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.

Configuring DNS for Mail Relaying

DMZ DNS MX records should point to the mail relay# cat /var/named/named.acme.com.@ IN MX 10 mailrelay.acme.com..mailrelay IN A 62.186.134.80

.

Intranet DNS MX record should point to the mail server# cat /var/named/named.acme.com.@ IN MX 10 mail.acme.com.mail IN A 10.0.0.80.



Student Notebook

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.

Limiting Message Size

Sendmail: Configure MAX_MESSAGE_SIZE in sendmail.mc

vi /etc/mail/sendmail.mcdefine(‘confMAX_MESSAGE_SIZE’, ‘50000’)

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Postfix: Set message_size_limit in main.cfvi /etc/postfix/main.cf

message_size_limit = 50000




Uempty

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.

Blocking Junk E-mail (Spam)

Add spamming domain to /etc/mail/access or /etc/postfix/access with keyword:

REJECT: Bounces messages as undeliverableOK: 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



Student Notebook

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:

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 tooLearns 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




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

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

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’)dnldefine(‘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=spamfilterspamfilter unix - n n - - pipe flags=Rq argv=/usr/bin/postfixfilter -f ${sender} -- ${recipient}




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

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.

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

Real-Time Blacklisting




Uempty

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.

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 attachments20+ 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)



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.




Uempty

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.

Installing AMaViS

Install a commercial virus scanner

Install amavisdRequired a large number of perl modules which might not be included with your distributionRequires 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=vscanvscan 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



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.)




Uempty

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.

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



Student Notebook


Notes:


1.

2.

3.


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.




Uempty


Notes:

Summary

There are several e-mail servers available for Linux:SendmailQmailPostfix

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



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


Notes:

Objectives

Describe Virtual Private Networks concepts

List different VPN protocols

List different VPN solutions for Linux

Install, configure FreeS/WAN




Uempty

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.

Virtual Private Networks Concepts

The Internet

DMZ

Company NetworkIntranet

Server

Customer Network

Client

Packet

Filtering

Router

Packet

Filtering

Router

Tunneling

DeviceFirewall

with

Tunneling



Student Notebook

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

Virtual Private Network Solutions

PPP over telnet or ssh

PPTP (Point to Point Tunneling Protocol)IETF Standard (RFC 2637)PPP over IPPAP, CHAP authenticationRC4 encryption (max 128 bits)Supported in Microsoft Windows 95/98/NT/2000

IPSec (IP Security Protocol)IETF Standard (RFC 2411)IP encapsulated over IPIntegral part of IPv6, ported back to IPv4Encryption, Authentication, Integrity protection, Replay protection, Non-repudiationKey management protocolWidely supported




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

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.

IPSec Overview

RFC 2411 (Documentation Roadmap)

Uses three subprotocolsIKE (Internet Key Exchange)ESP (Encapsulation Security Protocol)

Authentication and EncryptionAH (Authentication Header)

Only Authentication

Uses any encryption algorithm that is available (automatic negotiation at startup)

Allows two modes:Transport mode: host-to-hostTunneling mode: router-to-router




Uempty

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.

IPSec Modes

Transport mode: host-to-host security

H1 H2

Tunnel mode: router-to-router security

H1 H2R1 R2



Student Notebook

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.

Authentication Header Protocol (AH)

Integrity checking

Authentication through MD5 or SHA

Protocol number 51

AH Header

IP Header IP Payload


AH HeaderIP Header IP Header IP Payload

Regular IP packet:

IP packet, transport:

IP packet,

tunneled:




Uempty

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.

Encapsulating Security Payload (ESP)

Integrity checking

Authentication through MD5 or SHA

Encryption through DES, 3DES, CDMF

Protocol number 50


IP Header IP Payload (encrypted)

ESP HeaderIP HeaderIP Header

(encrypted) IP Payload (encrypted)

Regular IP packet:

IP packet, transport:

IP packet,

tunneled:

ESP Header



Student Notebook

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.

Internet Key Exchange (IKE)

Uses UDP/IP as transport protocolUDP Port 500 on both sides

Automated connection setup between two IPSec hostsInitial phase: cleartextNegotiate session key using Diffie-HellmanRest of communication is encrypted

Automated negotiation of Security AssociationsUnique, one-way session between two IPSec systemsNeed two SA's for two-way communication

Automated refresh of cryptographic keys




Uempty

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 applythough. For more information, see http://www.whitehouse.gov/OMB/legislative/sap/2000/HR2086-h.html.

FreeS/WAN

http://www.freeswan.org

Open Source implementation of IPSec for LinuxGNU Public License

Components:Klips: Kernel IPSec patchesPluto: Key negotiation daemonVarious utilities

Config files:/etc/ipsec.conf/etc/ipsec.secrets



Student Notebook

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.

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 modulesetc...# reboot




Uempty

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.

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 kernelUserland programs: freeswan.rpm



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.




Uempty

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.

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 ipsecredhat# service ipsec startsuse# rcipsec start



Student Notebook

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.

Session Key Exchange and Authentication

Session Keys

Manually keyed:

Session key stored in

/etc/ipsec.conf

(Same on both machines,

does not need authentication)

Automatically keyed:

Session key negotiated and refreshed automatically

(Needs authentication)

Authentication

Shared secret:

Stored in /etc/ipsec.secrets

(same on both machines)

Public key (RSA):

Public keys in /etc/ipsec.conf or DNS

Private key in /etc/ipsec.secrets




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

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.

/etc/ipsec.conf Global Options

config setup

interfaces="ipsec0=ppp0"

klipsdebug=none

plutodebug=none

plutoload=%search

plutostart=%search

conn %default

keyingtries=0

esp=3des-md5-96

Interfaces to use

Do not log debug messages

for klips and pluto

Search through this file

for connections to load

and/or start

Connection defaults

Try keying forever

Use ESP with 3DES

encryption and MD5

authentication

version 1.x:

version 2.x: Use "version 2"; plutoload and plutostart no

longer allowed (default behavior is same as %search)




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

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.

/etc/ipsec.conf Manual Keyed Connection

Configure connection information (on both machines):

conn team1-team2

left=62.186.134.70

leftsubnet=192.168.1.0/24

#leftnexthop=62.186.134.1

right=62.186.134.71

rightsubnet=192.168.2.0/24

#rightnexthop=62.186.134.1

auto=add

spi=0x200

espenckey=0x1234567...

espauthkey=0x01234...

IP address of "left"

Intranet of "left"

IP address of "right"

Load automatically

Security Parameter Index

192 bit hex 3DES key

Intranet of "right"

128 bit hex MD5 key

To start, run on both machines:# ipsec manual --up team1-team2




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

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.

Automatically Negotiated Session Key

conn team1-team2

left=62.186.134.70


#leftnexthop=62.186.134.1

right=62.186.134.71


#rightnexthop=62.186.134.1

auto=add

authby=secret

IP address of "left"

Intranet of "left"

IP address of "right"

Load automatically

Intranet of "right"

Configure connection information (on both machines)

Configure Authentication

On both machines, run:# ipsec auto --add team1-team2# ipsec auto --up team1-team2

Use shared secret

authentication




Uempty

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.

Manual Authentication

Add a common secret to both /etc/ipsec.secrets filesSecret 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..."



Student Notebook

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.

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

conn team1-team2

authby=rsasig

auto=start

left=10.0.0.1

[email protected]


leftrsasigkey=0sAQOB3aR6V1...

right=10.0.0.2

[email protected]


rightrsasigkey=0sAQNruF0ig...

@fw.team1.com: RSA {

#pubkey=0sAQOB3aR6V1...

#IN KEY 0x4200 4 1 AQOB3aR...

Modulus: 0x81dda47...

PublicExponent: 0x03

PrivateExponent: 0x15a4f0b...

Prime1: 0xcc464225...

Prime2: 0xa2bff86...

Exponent1: 0x882ed6c...

Exponent2: 0x6c7ffaec...

Coefficient: 0x3a78add...

}

/etc/ipsec.conf of left: /etc/ipsec.secrets of left:




Uempty

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 hierarchicalsystem of public keys. Not many implementations support DNSSec, and an even smaller number of sites actually use it.

Storing Public Keys in DNS

Instead of storing public keys in /etc/ipsec.conf, you can also store keys in DNS

Advantages:Easier setupEasier 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 entryfw.team1.com. IN KEY 0x4200 4 1 AQOB3aR...

Other side can now refer to DNS in /etc/ipsec.conf:[email protected]=%dns



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.




Uempty

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 othersubnet.6 This traffic is not handled by FreeS/WAN and thus unencrypted.

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

left=10.0.0.1


right=10.0.0.2


...

conn team1net-team2fw

left=10.0.0.1


right=10.0.0.2

...

conn team1fw-team2net

left=10.0.0.1

right=10.0.0.2


...

conn team1fw-team2fw

left=10.0.0.1

right=10.0.0.2

...



Student Notebook

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 [email protected] leftrsasigkey=0xAQNruF0ig... right=10.0.0.1 [email protected]

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 thisAuthentication via reverse DNS lookup




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 [email protected] leftsubnet=192.168.1.0/24 leftrsasigkey=0sAQ0B3aR6V1... right=%any # We don’t know the IP beforehand rightnexthop=%defaultroute [email protected] 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

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.

Verifying Connections With tcpdump

On the workstation:ping -p feedfacedeadbeef 192.168.2.2

On the firewall:tcpdump -i eth0 -x -l -ntcpdump -i ppp0 -x -l -n




Uempty

Figure 10-23. Useful Commands LX243.0

Notes:

The visual shows some commands you might need to use with FreeS/SAN.

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



Student Notebook

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.

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




Uempty


Notes:


1.

2.

3.

4.

5.


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.



Student Notebook


Notes:

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




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


Notes:

��

��9��%��

��

��

��_��




Uempty

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.

8��"��"<�5��!��B""

#��

~��

��#��

��#��

<��



Student Notebook

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 willreact to this situation by going into hub mode, which forwards every packet to every port. Programs such as ettercap make use of this“feature”.

7��<<��

+�� '��]�+��

]�`�� { ��{]�� 9��9'��9��

X��

*��^�� $'��&!��$�� ^��">��"��&#��$�� ^��"��"��"��&!�� $�� ^�� "��"��&

��Y��

#��+��$�� ^��"�� "��&




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

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.

.�� "�

'��Y��"��"�>�� ^��"��"��

��!��^�$�#��#��#��<�#�""�#�� $�� #�"�<��!��!��

]��!��

!��




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

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.

��

��\��X'�� 9��<#��

X��

�� 9��

!�� ^©��$�� ^�� "�� >�`��&




Uempty

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.

�"��7��

��Y9��$��&� �� $��&��

��9

��

!�� ^��$��&�$'��&#��$�� ^��"�� &_�� $�� ^��"��"�� "��&



Student Notebook

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.

��

~��

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

# ��9��




Uempty

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.

�� "�

'�� Y��"��"�>�� ^��"��"�� "��

\��^�$�#��#��<�#�""�#��$�#��#��#��#�"�<��!��!��

\��^��

_��



Student Notebook

Figure 11-10. Nmap Example LX243.0

Notes:

The visual shows a screen dump of the GUI of nmap.

��.��




Uempty

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.

��"��7��

\��9��

X��

+��

!�� ^#��$�� ^��"��"��ª>��"��&#��$�� ^��"��"��&_��$�� ^��"��"��&



Student Notebook

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.

��9

��#��~��Q#'��_��Q#'��#��@��«�¬��Y#��

# ��^��$��«�9��Y�&

��Y��




Uempty

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.

�� "��=�

'�� ^��"��"��^��Y��Y��"��"�>��Y��"��"�>��Y��Y��"��"�>��Y ��Y��"��"�>

\��^<"��!�� "�� $"��$�#��#��<�#�""�#@��!��$�@��!��#�"�<��<��J#��!��!�� $"��

_��



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.

�� "��

��_��$$��

��_��!��

#��_�� $��;

#��_��




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.

��.��




Uempty

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

��5��!��B""

~��9�$�� ^��" ��9��"�� ~��9&^�� $ ��&�� X�� 9��

�� $�� ^��"��9�"�� &^#��9��{_��9�_��#��{\��

!� �� \� ��9�� ^��"��"�� ^��"��"��



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.




Uempty


Notes:


1.

2.

8��!�"��]��"�

�" ��9�� J

�" ��9��J



Student Notebook


Notes:

7��

*��9��^��

#��9��>��

��

��9��

*��




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


Notes:

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




Uempty

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

Detecting Attack Attempts

Filesystem ChangesAdded/deleted/changed filesChanged file permissions

Network packet monitoringMonitor network packets, try to detect pattern

Logfile monitoringLook for strange entries in logfiles



Student Notebook

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.

Baseline

Baseline is a "blueprint" of your firewall in pristine state

Saved to secure mediaCD-RecordableTapeRead-only floppy

Used to figure out what has changedafter system administrationafter a break-inafter a while

Various possibilitiesFull system backupDo It YourselfFile system monitoring




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

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.

Do-It-Yourself Baseline

Save the following files/etc/*/boot/*

Save output of following commandsps -auxnetstat -annetstat -rnfreedfdu /vmstatls -lR /mountrpm -qa

Save md5sum of all executables and libraries




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

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.

Filesystem Integrity Checking

Save characteristics of every important file:User, groupPermissionsctime, mtimelengthlink countchecksum...

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




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

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

Tripwire

Popular File Integrity Checking tool

Originally written as academic research project in 1992No development until 1997 when one of the authors continued development as a commercial product rangeCore 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




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

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

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




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

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.

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)




Uempty

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.

Snort

"Open Source Network Intrusion Detection System"

Three modes:SnifferPacket capture on diskIntrusion 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



Student Notebook

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.)

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)




Uempty

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.

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



Student Notebook

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.

Snort NIDS mode

Logs interesting packets and sends alerts

Managed by configuration file /etc/snort.confsnort variablespreprocessors (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 22Rules may list packet dataRules 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




Uempty

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.

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



Student Notebook

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).

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)




Uempty

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.

Swatch

Can analyze log files in batch or real-time

Can output to any scriptable interfaceSMS, Pager!

Installation instructions:Download from http://swatch.sourceforge.netperl Makefile.PLmakemake install

Need selected modules from CPAN (Comprehensive Perl Archive Network)

Usually included in distribution



Student Notebook

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.

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




Uempty
S
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

Swatch Configuration Options

ignore <regex>: Ignore these log lines

watchfor <regex>: Watch for these log lines and execute actions:

echo [<color>]: Echo on stdoutbell: Ring a bellexec <command>: Execute a commandmail addresses=<recip>,subject=<subject>: Send e-mailpipe <command>: Pipe to commandwrite <user>: Use write to alert userthrottle <limit>: Limit invocation amountcontinue: Don't stop after match; continue searching through config file for more matches



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.




Uempty

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.

Swatch Batch Mode

ignore /test/

ignore /modprobe/

ignore /this too, and more/

watchfor /.*/

echo

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):



Student Notebook

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.

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




Uempty

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.

Swatch Daemon Mode

watchfor /panic/

mail addresses=joe,pete,subject=panic

watchfor /snort/

exec "call_pager 7654321 NIDS Alert: $*"

throttle 00:05

ignore /.*/

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:



Student Notebook

Figure 12-21. General Logging Tips LX243.0

Notes:

The visual lists some general logging tips.

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




Uempty

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!

Countering Attacks

Start a network trace (preferably on another system)tcpdump -i eth0 -w file

Start scriptscript 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



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 thatby blocking the top-50 of client IP addresses you can probably counter a DDoS attack. You might consider writing a small shell script (ona 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 15minutes or so.




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

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

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 analysistcpdump traces of real-life attacks on their honeypots are put up as challenges for people interested in gaining proficiency in analyzing attacks




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

Figure 12-24. Checkpoint Questions LX243.0

Notes:


1.

2.

3.

4.


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?




Uempty


Notes:

Summary

Making a baseline of your system.

Installing tools to detect attacks

React to attacks

Deception



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


Notes:

Objectives

Discuss some good practices in maintaining computer security




Uempty

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.

Computer Security is a Way of Life

Computer Security is not a project, it's a way of lifeA firewall alone does not make your network secure

Should be implemented everywhereUser educationAdministrator educationProgram design/development/test/implementationNetwork and system setupDay-to-day production



Student Notebook

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.

User Education

Use good passwordsAt least six charactersNot a dictionary word, name, birthdate, license plateNot easily guessableChange frequentlyDon't write them down

Don't tell anybody your passwordNot 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 mailBeware of macro viruses

Don't leave computers/sessions unattendedPassword-protected screensaver




Uempty

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.

Administrator Education

Follow relevant courses

Read relevant documentation/books/articles/magazinesSee bibliography

Keep current on security developmentsGeneral mailing lists: CERT, Bugtraq, FBI, IBM, ERSSpecific mailing lists: Every application you use, Linux distributionNewsgroups: comp.security.*IRC: fnet



Student Notebook

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?

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 overflowsDon't assume a file/message will be formatted according to the specifications: check firstUse logging extensively (using syslogd)Documentation

Test:Test behavior under stress conditions

Implementation:File/directory permissions




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

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

Network and System Setup

Do-it-yourself or preinstalled?Secure distributionsHardening scriptsAdd-on software

Documentation

Backups

Failover/fallback systems

Defense in depth

Disaster recovery plans




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

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.

Day-to-Day Operations

Monitor system behaviourLogfilestopbaseline

Test security regularly

Prepare for attacksPrioritize servicesWho needs to be informed, when and how?Don't rely on any service that might be compromised

E-mailSSH

Think about the worst-case scenario

Don't chase windmills99% of attacks are script kiddies who discovered Nessus and nmap




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


Notes:

Summary

Computer Security is not a project, it's a way of life




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 sameciphertext.


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


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


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


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




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.




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


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:

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.

CourseCompTIA LPI Red Hat

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.


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


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 Systemshttp://www.snort.org Snort


© Copyright IBM Corp. 2000, 2003 Bibliography X-1


IX
Index
Symbols$DISPLAY 5-6, 5-16$HOME/.bash_profile 2-19$LANG 9-23$LD_PRELOAD 6-11$TMOUT 2-19/boot/grub/menu.lst 2-10/etc/fstab 2-15/etc/hosts 9-7/etc/hosts.allow 1-33/etc/hosts.deny 1-33/etc/hosts.equiv 5-3/etc/init.d/boot.ipconfig 3-32/etc/init.d/boot.sysctl 3-32/etc/inittab 2-16/etc/issue 2-17/etc/issue.net 2-17/etc/lilo.conf 2-10/etc/mail/access 9-7/etc/mail/mailertable 9-7/etc/modules conf 4-29/etc/motd 2-18/etc/profile 2-19/etc/rc.d/init.d/iptables 4-31/etc/rc.d/rc.sysinit 3-32/etc/rc.local 2-17, 4-29/etc/sysconfig/sysctl 3-32/etc/sysctl.conf 3-32/etc/xinetd.conf 2-13/etc/xinetd.d 2-13/proc 3-32/proc/sys 3-32/proc/sys/net/ipv4/conf 3-36~/.rhosts 5-3

Numerics3DES 10-9, 10-18, 10-21

Aaccept_redirects 3-36accept_source_route 3-36ACK 3-23, 3-25acknowledgement number 3-23AH 3-12, 10-6, 10-8AIDE 12-8air conditioning 1-6AMaViS 9-21Apache 7-6APM 2-9arc 9-24

Course materials may not be rwithout the prior writte

© Copyright IBM Corp. 2000, 2003

ARP storm 11-4Authentication 1-4, 1-8, 10-23Authorization 1-4automatic keying 10-17automatically keyed connection 10-22, 10-23

Bbackups 1-6base of operations 1-13baseline 12-4Bayesian Filter 9-16biometrics 1-9BIOS 2-9BIOS password 2-9blackmail 1-13blueprint 12-4Boot Loader 2-10break-in 1-14brute-force 1-15

CCDMF 10-9chain 4-6Challenge 1-12CHAP 10-5checksum 2-4Cheops 11-19chkconfig 2-13, 3-32, 6-9choke point 1-19CIDR 3-9Cisco PIX 4-34Classless InterDomain Routing 3-9clear text 5-3CMOS 2-9Comprehensive Perl Archive Network 9-22CompTIA C-1connection setup 1-22connectionless 3-4CPAN 9-22, 9-23, 12-21cracker 1-10credit card 1-13cron 12-25Ctrl-Alt-Del 2-16Curiosity 1-12

DDaemonPortOptions 9-8, 9-10Dante 6-6, 6-7Data offset 3-23datagram 3-4

eproduced in whole or in part n permission of IBM.

Index X-3

Student Notebook

DDoS 1-13, 3-21DDoS attack 12-30Deception 12-32de-masquerading 4-25Demilitarized Zone 1-22Denial of Service 1-16Denial-of-Service 1-13DES 10-9destination IP addres 3-12Destination NAT 4-4destination port 3-21, 3-23, 3-27Destination unreachable 3-16destination unreachable 3-18DHCP 8-4Diffie-Hellman 10-10Distributed Denial of Service 1-16Distributed Denial-of-Service 1-13DMZ 1-22, 1-24, 1-25, 1-27, 8-5, 8-7, 9-4, 9-13DNAT 4-4DNS 1-26, 7-4, 8-3, 9-13, 10-25DNS server 1-26DoS 1-13, 2-6, 3-18, 12-30DoS attack 8-4DSA 5-13dynamic updates 8-4

EEcho reply 3-16echo reply 3-18Echo request 3-17echo request 3-18EICAR 9-24e-mail 1-25encryption 1-28ESP 3-12, 10-6, 10-9espauthkey 10-21espenckey 10-21espionage 1-12Ethereal 3-29, 11-5, 11-6, 11-7ethereal 12-29ettercap 11-4Eugene Spafford 12-10Exim 9-5, 9-6exploit 11-20Extranet 10-3

Ffeedfacedeadbeef 10-30file transfer 5-3filesystems 2-3filter table 4-10FIN 3-24fingerprint 1-9, 11-8fire 1-4

Firewalk 11-19firewall 1-19, 1-20Flags 3-12flooding 1-4Follow TCP Stream 11-7FORWARD chain 4-6fragment 3-12Fragment offset 3-12FreeS/WAN 2-7, 10-11FTP 1-24, 7-3ftp 5-3ftp server 8-9fuser 2-14FWBuilder 4-34

GGene Kim 12-10GNU Public License 5-5Gopher 7-3GPG signature 2-4GRUB 2-10GSM 12-21gunzip 9-24

Hhacker 1-10, 8-3half-open 3-28header 3-4header checksum 3-12Header Length 3-11HLEN 3-11HoneyNet Project 12-32honeynet project 12-15honeypot 12-32host key 5-9HTTP 7-3, 11-5httpd.conf 1-33HTTPS 7-3

IIAB 5-4IANA 3-6, 4-16, 8-9ICMP 3-12, 3-15, 3-18icmp_echo_ignore_broadcasts 3-33ICP 7-6Identd 4-20Identification 3-12IETF 6-3, 7-3IKE 10-6, 10-10IMAP 9-4, 9-11, 9-12init 2-16INPUT chain 4-6Internet Addressing and Naming Agency 3-6



Student Notebook

Internet Architecture Board 5-4Internet Cache Protocol 7-6Internet Draft 5-4Internet Protocol 3-4Intranet mail server 9-4Intrusion scan 11-13IP 3-4IP address 1-22IP addresses 3-5IP forwarding 10-15IP Masquerading 4-4, 4-25, 7-10IP packet 1-22IP spoofing 5-3ip_conntrack_ftp 4-29ip_default_ttl 3-34ip_local_port_range 3-34ip_nat_ftp 4-29ip_no_pmtu_disc 3-34ipchains 4-8ipfilter 4-34ipfrag_high_thresh 3-34ipfrag_low_thresh 3-34ipfrag_time 3-34ipfwadm 4-8IPSec 10-5, 10-6ipsec_spi 10-18ipt_LOG 4-23ipt_REJECT 4-21iptables 4-8, 4-9, 4-10, 4-13, 4-32, 4-34, 8-19iptables-restore 4-9, 4-30, 4-32iptables-save 4-9, 4-30IPv6 10-5ISP 8-9

JJava applets 7-4

Kkernel modules 2-7kernel recompile 2-6Klips 10-11, 10-18klipsdebug 10-18

LL5 12-9layering 3-3leased lines 1-28leftnexthop 10-20leftsubnet 10-20liability 1-13libdsocks 6-10libpcap 11-4, 12-15LILO 2-10

Linux Professional Institute C-1log_martians 3-36logging 7-4loopback 3-7LPI. See Linux Professional InstituteLX02 C-2LX03 C-2LX07 C-2LX22 C-2LX23 C-2LX24 C-2LX25 C-2LX26 C-2

Mm4 9-14mail client 1-25mail exchanger 9-13mail gateway 1-25, 9-4mail relay 1-25make 9-7mangle table 4-10man-in-the-middle 1-15manual keying 10-16manually keyed connection 10-20maximize throughput 3-11maximum reliability 3-11MD5 2-4, 10-8, 10-18, 10-21md5crypt 2-10md5sum 12-6milter interface 9-17minimize delay 3-11minimize monetary cost 3-11MIT Magic Cookie 5-16modprobe 4-29Morris Worm 9-5multicast 3-7MX record 9-13

NNAT 6-5, 7-5, 8-3nat table 4-10Nec 6-6Nessus 11-13netcat 11-9netmask 3-10netstat 2-14Network Address Translation 4-4, 7-10Network Address Translators 1-24network administrator 3-5network identifier 3-10Network Interface 4-3Network Intrusion Detection System 12-15Network security 1-4, 1-7


© Copyright IBM Corp. 2000, 2003 Index X-5

Student Notebook

NIDS 12-15Nmap 11-9, 11-10nmap 11-8, 12-30nodev 2-15noexec 2-15nosuid 2-15

OOpenBSD PF 4-34OpenSSH 5-5OpenSSL 5-5Opportunistic Encryption 10-29OUTPUT chain 4-6

Ppacing 3-21Packet Filtering 4-3packet filtering router 1-22Packet mangling 4-36packet mangling 4-5pager 12-21, 12-27Parameter problem 3-17partitions 2-3password 1-8perl 9-17, 12-23PGP 1-8Physical security 1-4, 1-5ping 4-17Pluto 10-11plutodebug 10-18plutoload 10-18plutostart 10-18PMTU discovery 3-34POP 9-4POP3 9-11, 9-12, 11-5PoPToP 10-5port forwarding 4-4, 4-35port number 1-22port numbers 3-19port scan 2-7port scanner 11-9Postfix 9-5, 9-6, 9-9POSTROUTING chain 4-6PPP 10-4, 10-18PPTP 10-4Precedence 3-11PREROUTING chain 4-6pre-shared key 10-17pre-shared secret 10-17Pretty Good Privacy 1-8private key 5-9private networks 3-7procmail 9-17Protocol 3-12

protocol 1-22proxy 1-20proxy protocol 7-3Proxy server 1-24proxy server 7-3Proxy servers 7-10ProxyRequests 7-7ps 2-14PSH 3-23public key 5-9, 10-17Public key cryptography 1-8Purdue University 12-10

QQmail 9-5, 9-6Queso 11-8

Rrandom 3-27rcp 5-3, 5-4rcSuSEfirewall2 4-32real-time blacklisting 9-20Red Hat C-1Red Hat Certified Engineer C-1Red Hat Certified Technician C-1Redirect 3-16redirect 1-14Redirect ICMP 3-18regular expression 12-23RELAY 9-7remote execution 5-3remote login 5-3retina pattern 1-9reverse DNS lookup 8-3rexec 5-3RFC 5-4, 10-18

1928 6-32616 7-3

RHCE. See Red Hat Certified EngineerRHCT. See Red Hat Certified Technicianrightnexthop 10-20rightsubnet 10-20rlogin 5-3ro 2-15Road Warrior 10-28root password 2-3rp_filter 3-36RPM 2-4, 6-7, 7-8rpm 2-5RSA 1-8, 5-8, 10-17, 10-24RSA Challenge-Response Authentication 5-12rsh 5-3, 5-4RST 3-23ruleset 12-19



Student Notebook

SSA 10-10Saint 11-13sa-learn 9-17Samba C-3Satan 11-13scanning 1-14scp 5-4, 5-7screened subnet 1-22script 12-29script kiddie 1-10secondary DNS 8-4secure port 3-21Security Association 10-10security parameter index 10-21Security Policy 1-3security policy 1-20send_redirects 3-36Sendmail 9-5sequence number 3-23, 3-27service security 1-32Service Type 3-11session key 5-8, 10-16SHA 10-8shared library loader 6-10shared secret 10-17smart relay 9-12Smartcards 1-8smb.conf 1-33SMS 12-21, 12-27SMTP 9-13smurf attack 3-18smurf attacks 3-33SNAT 4-4Sniffer 11-4sniffer 5-3sniffing 1-14Sniffit 11-5Snort 12-15socks 1-20, 8-3socks protocol 6-3Socks server 1-24Socks servers 7-10socksified 6-10source IP address 3-12, 3-18Source NAT 4-4source port 3-21, 3-23, 3-27Source Quench 3-16, 3-18spam 9-15spam score 9-16spamc 9-17spamd 9-17spare parts 1-6Squid 7-6, 7-8SSH 1-8, 11-5

ssh 5-4, 5-6, 10-4SSH protocol 5-4SSH Tunnel 5-18SSH tunnel 5-16ssh-add 5-15ssh-agent 5-14sshd 5-4, 5-8ssh-keygen 5-12stacheldraht 1-13stateful TCP inspection 4-36StrictHostKeyChecking 5-9Strobe 11-9strong encryption 5-4su 2-11SuSEfirewall2 4-32Swatch 12-21switch 11-4SYN 3-24, 3-25, 3-28SYN attacks 3-28SYN cookies 3-28sysctl 3-32

TTCP 3-12, 3-22TCP/IP protocol suite 3-3tcp_fin_timeout 3-35tcp_keepalive_probes 3-35tcp_keepalive_time 3-35tcp_retries1 3-35tcp_syncookies 3-35tcpdump 3-29, 10-16, 10-30, 11-5, 12-15, 12-29telnet 10-4, 11-5theft 1-4Time Exceeded 3-17Time To Live 3-12TIS firewall toolkit 7-6Token Ring 11-4top 13-10traceroute 12-30transparent caching 7-4transparent proxying 4-5, 4-35transport mode 10-7Tripwire 12-8, 12-10tripwire 12-31tripwire --check 12-13Trojan horse 1-16tsocks 6-6TTL 3-12, 3-17tunneling 1-28tunneling mode 10-7twadmin 12-12Type of Service 3-11


© Copyright IBM Corp. 2000, 2003 Index X-7

Student Notebook

UUDP 3-12, 3-19Uninterruptible Power Supply 1-5UnitedLinux C-1UNIX socket 9-18Urgent flag 3-23user defined chain 4-6userid 2-12UUCP 9-6

VVERS 3-11Version 3-11Virtual Private Network 10-3Virtual Private Networking 1-28Virus 1-16virus protection 2-9vlock 5-15VPN 10-4

WWAIS 7-3warez 1-12web server 1-27, 8-9well-known port 1-26whois 12-30WinNuke 3-27World Wide Web 1-24Worm 1-16wrapper program 6-10

XX authentication 5-6, 5-16X clients 5-6X forwarding 5-16xeyes 5-17xinetd 2-13xlock 5-15

Yyast 4-32

Zzone transfer 8-4zoo 9-24



V3.0

backpg
Back page

��®

linux network administration ii, network security and firewalls - student notebook (ibm learning,...

Documents

copyright ibm

united states

ip packet format

udp protocol

tcp protocol

icmp protocol

ip protocol3

security policy