SuSE Linux Firewall on CD — VPN Editionleotardi.ddns.info/html/lan/download/USE Linux Firewall VPN...

Michael Calmer, Rebecca Ellis, Uwe Gansert, Dennis Geider, Viviane Glanz,Roland Haidl, Edith Parzefall, Peter Reinhart, Ulrich Schairer,Thomas Schraitle, Martin Sommer, Marius Tomaschewski, Steve Tomlin,Rebecca Walter

SuSE Linux Firewall on CD— VPN Edition

SuSE Inc.580 2nd Street, #210Oakland, CA 94607USAToll free phone numberwithin the US and Canada: 1-888-UR-LINUX (1-888-875-4689)Phone: +1-510-628-3380Fax: +1-510-628-3381e-mail: [email protected]

[email protected]@suse.com

WWW: http://www.suse.com

Europe:

SuSE Linux Ltd.The Kinetic CentreTheobald StreetBorehamwood, WD6 4PJ UKPhone: +44-20-8387-4088Fax: +44-20-8387-4010WWW: http://www.suse.co.uk

SuSE GmbHSchanzäckerstr. 10D-90443 NürnbergGermanyTel.: +49-911-740-53-0Fax: +49-911-740-479e-mail: [email protected]: http://www.suse.de

[email protected]

[email protected]

[email protected]

http://www.suse.com

http://www.suse.co.uk

[email protected]

http://www.suse.de

Michael Calmer, Rebecca Ellis, Uwe Gansert, Dennis Geider, Viviane Glanz,Roland Haidl, Edith Parzefall, Peter Reinhart, Ulrich Schairer, Thomas Schraitle,Marius Tomaschewski, Steve Tomlin, Rebecca Walter

SuSE Linux Firewall on CD — VPN Edition1st edition 2001(c) SuSE GmbH

CopyrightThis work is copyrighted by SuSE GmbH.You may copy it in whole or in part as long as the copies retainthis copyright statement.

Registered trademarks:Linux of Linus Torvalds, XFree86™ ofThe XFree86 Project, Inc., MS-DOS, Windows, Windows 95,Windows 98, andWindows NTof theMicrosoft Corporation,UNIX of X/Open Company Limited, T-Onlineof DeutscheTelekom, SuSEandYaST of SuSE GmbH. All trade names areused without the guarantee for their free use and may be registeredtrademarks. The corporation SuSE GmbH essentially follows tothe notations of the manufacturers. Other products mentioned heremay be trademarks of the respective manufacturer.

Contents

Contents

1 Preface 9

2 Introduction and General Overview 11

2.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 SuSE Linux Firewall on CD . . . . . . . . . . . . . . . . . . . 12

2.2.1 Network Planning . . . . . . . . . . . . . . . . . . . . 13

2.3 An Overview of Typical Firewall Setups. . . . . . . . . . . . . 13

3 SuSE Linux Adminhost for Firewall 15

3.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1 Update with YaST2. . . . . . . . . . . . . . . . . . . . 16

3.2.2 Update with YaST. . . . . . . . . . . . . . . . . . . . 17

3.2.3 Closing Update. . . . . . . . . . . . . . . . . . . . . . 18

3.3 New Installation of theSuSE Linux Adminhost for Firewall . . 18

3.3.1 Language Selection. . . . . . . . . . . . . . . . . . . . 19

3.3.2 Selecting the Mouse. . . . . . . . . . . . . . . . . . . 19

3.3.3 Keyboard and Time Zone. . . . . . . . . . . . . . . . . 19

3.3.4 Preparing the Hard Disk. . . . . . . . . . . . . . . . . 20

3.3.5 Boot Manager Configuration. . . . . . . . . . . . . . . 22

3.3.6 Setting the‘root’ Password . . . . . . . . . . . . . . 22

3.3.7 Confirming Settings and Starting the Installation. . . . 22

3.3.8 Preparing the Graphical Interface. . . . . . . . . . . . 23

3.3.9 Configuring the Network with YaST2. . . . . . . . . . 24

3.3.10 Manual Network Configuration. . . . . . . . . . . . . 25

3.3.11 The User‘fwadmin’ for the FAS . . . . . . . . . . . . 31

4 Firewall Administration System (FAS) 33

4.1 Logging In as‘fwadmin’ . . . . . . . . . . . . . . . . . . . . 33

4.2 Starting the Firewall Administration System. . . . . . . . . . . 33

4.3 Creating a New Firewall Configuration. . . . . . . . . . . . . . 33

4.3.1 Configuration of the Base Module. . . . . . . . . . . . 36

3

Contents

4.3.2 Syslog Configuration. . . . . . . . . . . . . . . . . . . 39

4.3.3 DNS Configuration. . . . . . . . . . . . . . . . . . . . 40

4.3.4 IP Filter Configuration withipchains . . . . . . . . . . 41

4.3.5 Configuration of the SuSE Firewall Module. . . . . . . 41

4.3.6 Configuring the Mail Relay (Postfix). . . . . . . . . . . 47

4.3.7 SSH Configuration. . . . . . . . . . . . . . . . . . . . 49

4.3.8 FTP Access — External to Internal. . . . . . . . . . . 50

4.3.9 Configuring the FTP Proxy — Internal to External. . . 51

4.3.10 Configuring the HTTP Proxy: Internal to External. . . 52

4.3.11 Configuring the HTTP Proxy: External to Internal. . . 58

4.3.12 The FAS Keyring Module. . . . . . . . . . . . . . . . 59

4.3.13 Configuring a Time Server with xntpd (NTP Module). . 63

4.3.14 rinetd . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.3.15 VPN Connections (IPSEC Module). . . . . . . . . . . 66

4.3.16 Saving the Configuration. . . . . . . . . . . . . . . . . 72

4.4 Editing an Existing Firewall Configuration. . . . . . . . . . . . 72

4.5 Testing the Configuration. . . . . . . . . . . . . . . . . . . . . 72

4.6 Documenting the Configuration, the Tests, and the Results. . . 73

4.7 Monitoring the Firewall. . . . . . . . . . . . . . . . . . . . . . 73

4.8 Configuration of syslog-ng. . . . . . . . . . . . . . . . . . . . 74

5 SuSE Linux Live CD for Firewall 75

5.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2 Description of the SuSE Linux Live CD for Firewall. . . . . . 76

5.3 Services on the Firewall. . . . . . . . . . . . . . . . . . . . . . 76

5.3.1 ipchains. . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.3.2 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.3.3 MAIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.3.4 HTTP Proxy . . . . . . . . . . . . . . . . . . . . . . . 89

5.3.5 FTP Proxy . . . . . . . . . . . . . . . . . . . . . . . . 90

5.3.6 SSH. . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.3.7 chroot, secumod, compartment, kernel capabilities. . . 91

5.4 The Configuration Disk. . . . . . . . . . . . . . . . . . . . . . 92

5.4.1 Creating the Configuration Disk. . . . . . . . . . . . . 92

5.4.2 The Configuration Files. . . . . . . . . . . . . . . . . 92

5.5 Boot Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . 95

4

Contents

6 Implementing the Firewall 97

6.1 Booting the Firewall Host. . . . . . . . . . . . . . . . . . . . . 97

6.2 Testing the Firewall. . . . . . . . . . . . . . . . . . . . . . . . 98

6.3 Testing Operation. . . . . . . . . . . . . . . . . . . . . . . . . 98

6.3.1 Internal testing. . . . . . . . . . . . . . . . . . . . . . 98

6.3.2 External testing. . . . . . . . . . . . . . . . . . . . . . 99

6.3.3 “Really” going online . . . . . . . . . . . . . . . . . . 99

7 Help 101

7.1 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . .101

7.1.1 Problems Installing the Adminhost. . . . . . . . . . . . 101

7.1.2 Problems Booting the Live CD. . . . . . . . . . . . . . 101

7.1.3 Problems Integrating the Network. . . . . . . . . . . . 101

7.2 Security Policy and Communication Analysis. . . . . . . . . . 102

7.2.1 Security Policy. . . . . . . . . . . . . . . . . . . . . . 102

7.2.2 Communication Analysis. . . . . . . . . . . . . . . . . 103

7.3 Services Offered by SuSE Linux AG. . . . . . . . . . . . . . . 103

7.4 Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104

7.5 Detecting Attacks. . . . . . . . . . . . . . . . . . . . . . . . .105

7.5.1 Intrusion Detection and Event Display. . . . . . . . . . 105

7.5.2 External Attacks. . . . . . . . . . . . . . . . . . . . . 107

7.5.3 Advantage of the Live File System. . . . . . . . . . . . 108

7.6 Professional Help and Support. . . . . . . . . . . . . . . . . . 108

7.6.1 Installation Support. . . . . . . . . . . . . . . . . . . . 108

7.6.2 Professional Services. . . . . . . . . . . . . . . . . . . 109

7.6.3 Training. . . . . . . . . . . . . . . . . . . . . . . . . .111

7.6.4 Feedback. . . . . . . . . . . . . . . . . . . . . . . . .111

7.6.5 Further Services. . . . . . . . . . . . . . . . . . . . . 111

7.7 Recommended Reading. . . . . . . . . . . . . . . . . . . . . . 112

A DNS — Domain Name Service 113

A.1 Starting the Name Server BIND. . . . . . . . . . . . . . . . . 113

A.2 The Configuration File /etc/named.conf. . . . . . . . . . . . . 114

A.2.1 The Most Important Configuration Options. . . . . . . 114

A.2.2 The Configuration Section “Logging”. . . . . . . . . . 116

A.2.3 Zone Entry Structure. . . . . . . . . . . . . . . . . . . 116

A.2.4 Structure of Zone Files. . . . . . . . . . . . . . . . . . 117

A.3 DNS Sample Configuration. . . . . . . . . . . . . . . . . . . . 120

A.3.1 For More Information . . . . . . . . . . . . . . . . . . 124

5

Contents

B Proxy Server: Squid 125

B.1 What is a Proxy Cache?. . . . . . . . . . . . . . . . . . . . . . 125

B.2 Some Facts About Cache Proxying. . . . . . . . . . . . . . . . 126

B.2.1 Squid and Security. . . . . . . . . . . . . . . . . . . . 126

B.2.2 Multiple Caches . . . . . . . . . . . . . . . . . . . . . 126

B.2.3 Caching Internet Objects. . . . . . . . . . . . . . . . . 127

B.3 System Requirements. . . . . . . . . . . . . . . . . . . . . . .127

B.3.1 Hard Disk. . . . . . . . . . . . . . . . . . . . . . . . .127

B.3.2 RAM . . . . . . . . . . . . . . . . . . . . . . . . . . .128

B.3.3 CPU. . . . . . . . . . . . . . . . . . . . . . . . . . . .129

B.4 Starting Squid. . . . . . . . . . . . . . . . . . . . . . . . . . .129

B.5 The Configuration File /etc/squid.conf. . . . . . . . . . . . . . 130

B.6 Transparent Proxy Configuration. . . . . . . . . . . . . . . . . 134

B.6.1 Kernel Configuration. . . . . . . . . . . . . . . . . . . 134

B.6.2 Configuration Options in /etc/squid.conf. . . . . . . . . 134

B.7 Squid and Other Programs. . . . . . . . . . . . . . . . . . . . 135

B.7.1 cachemgr.cgi. . . . . . . . . . . . . . . . . . . . . . .135

B.7.2 SquidGuard. . . . . . . . . . . . . . . . . . . . . . . .136

B.7.3 Cache Report Generation with Calamaris. . . . . . . . 137

B.8 More Information on Squid. . . . . . . . . . . . . . . . . . . . 138

C Network Security 139

C.1 SSH — Secure Shell, the Safe Alternative. . . . . . . . . . . . 139

C.1.1 The OpenSSH Package. . . . . . . . . . . . . . . . . . 139

C.1.2 The ssh Program. . . . . . . . . . . . . . . . . . . . . 139

C.1.3 scp — Secure Copy. . . . . . . . . . . . . . . . . . . . 140

C.1.4 sftp — Secure File Transfer. . . . . . . . . . . . . . . 141

C.1.5 The SSH Daemon (sshd) — Server-Side. . . . . . . . . 141

C.1.6 SSH Authentication Mechanisms. . . . . . . . . . . . 142

C.1.7 X, Authentication, and Other Forwarding Mechanisms. 143

C.2 Security and Confidentiality. . . . . . . . . . . . . . . . . . . 144

C.2.1 Basic Considerations. . . . . . . . . . . . . . . . . . . 144

C.2.2 Local Security and Network Security. . . . . . . . . . 144

C.2.3 Some General Security Tips and Tricks. . . . . . . . . 153

C.2.4 Using the Central Security Reporting Address. . . . . . 155

D YaST and SuSE Linux License Terms 157

6

Contents

7

1 Preface

1 Preface

Many thanks to Jürgen Scheiderer, Carsten Höger, Remo Behn, Thomas Biege,Roman Drahtmüller, Marc Heuse, and Stephan Martin.

The SuSE Linux Firewall on CD — VPN Edition

TheSuSE Linux Firewall on CD — VPN Edition is a tool package allowing setup of a firewall solution for your network. It helps with the related configuration,monitoring, and administration chores. The complete functionality of theSuSELinux Firewall on CD is based on Open Source programs specially selected andenhanced for this purpose.

TheSuSE Linux Firewall on CD protects your local network from illegal access,manages authorized use of your resources, and provides a controlled channelthrough which users on your local network are enabled to communicate with theInternet.

To reduce the likelihood of the firewall being misconfigured, we recommendusing theFirewall Administration System (FAS), which corrects most user mis-takes by performing a number of sanity checks. FAS ensures a consistent con-figuration without limiting the available options.

Total security cannot be achieved by any firewall, not even by theSuSE LinuxFirewall on CD . This package is not intended to serve as a substitute for a propersecurity policy and does not eliminate the need to administer, maintain, and mon-itor the firewall. It provides a number of tools to make these tasks much easierto perform.

� �

�

NoteAlthough every effort has been made to make SuSE Linux Firewall on CD asecure firewall product, SuSE is unable to guarantee the security of yoursystem. SuSE cannot be held responsible for any damages caused byinsufficient security measures.

9

1 Preface

10

2 Introduction and General Overview


2.1 Introduction

The importance of the Internet, the communication possibilities provided, andthe information-gathering options offered seem to grow every day. The numberof companies and individuals with access to this worldwide network is growingsteadily.

However, connecting to the Internet often introduces some security concerns thatshould not be underestimated. Most companies rely on their own networks toexchange and process mission-critical information for in-house purposes, such asan intranet, databases, and e-mail. Without the proper protection mechanisms inplace, all this data would be widely available to the outside world as soon as thelocal network was connected to the Internet — something that could obviouslycause a lot of damage, especially for companies.

It’s easy to run a secure computer system. You just have to disconnectall dial-up connections and permit only direct-wired terminals, put themachine and its terminals in a shielded room, and post a guard at thedoor.

F.T. Grampp and R.H. Morris

We all know that, in the real world, it is impossible to run a computer systemin this way. If you are an administrator, you will know all too well about theproblems arising from the increasing number of networked machines. After all,you are the person who has to deal with the situation on a daily basis. Up to now,your network may have been quite manageable. It was once possible to knowthe users on a network and provide network functionality to your users mainlyon the basis of trust relationships. All that kept the administrative overhead ata reasonable level. Now, with connections to the Internet commonplace, thingshave changed dramatically as have the duties of the administrator. All at once,there are users who are completely unknown who can use resources on yournetwork, like the web server.

These users need to be handled in a totally different manner than your company’sinternal employees. On the other hand, it has been proven that eighty percent ofall attacks on corporate networks are not carried out from the Internet. There areother reasons to protect the corporate network and to restrict access to it: crack-ers, or intruders, are always on the lookout for places to store pirated software,or, even worse, contents prohibited by law. Not taking any measures against thiscould not only mean that the company could open itself up to legal prosecution,but could also put your company’s good reputation at stake.

11


Today, there are a number of different mechanisms available to prevent unautho-rized access to corporate networks and resources (i. e., disk space or CPU capac-ity), from IP packet filters on routers to multiple-level firewall solutions completewith a demilitarized zone (DMZ). In a general sense, of course, the word “fire-wall” is used for a device prevent the spreading of fires. Firewalls made of bricksare found in buildings where they are used to isolate whole sections from eachother and in cars a special metal plate shields the passenger compartment fromthe engine compartment. Similarly, the purpose of Internet firewalls is to fendoff attacks directed at your intranet, as well as to regulate and protect clients onyour LAN by imposing an access policy.

The first firewall was a non-routing UNIX host connected to two different net-works: one network interface was connected to the Internet and the other oneto a private LAN. To reach the Internet from within the private network, usershad to log in to the UNIX firewall server before they could access any outsidehost. To do so, they would start, for example, an X Window–based browser onthe firewall host then export the window to the display of their workstation. Withthe browser hosted on the firewall, users had access to both systems at the sametime. However, you should not consider this kind of setup (called “dual homedsystem”) for your own network unless you really trust all the users on it. Tounderstand why, remember that ninety-nine percent of all break-ins on computersystems start with an attempt to obtain a user account on the targeted system.

The scope of your firewall solution will depend on the required degree of protec-tion, which may need to be in line with legal regulations in some cases and whichshould be determined through a communication analysis. Information about con-ducting a communication analysis yourself or obtaining consulting, training, orsupport services is available in Chapter7 on page101.

Another factor affecting the operation of a firewall is the state of its documen-tation. There should be a way to determine “who has changed what, when, andhow” to trace back whether changes were made by an authorized party. This willalso be quite helpful when it comes to dealing with things like certifications andaudits.

TheSuSE Linux Firewall on CD is a product covering the whole range of theseissues in all its details, from packet filtering to setting up a multiple-level firewall.Because the package is based on Open Source programs, it is also possible toaudit the source code without too much difficulty.

2.2 SuSE Linux Firewall on CD

TheSuSE Linux Firewall on CD consists of two basic product components:

1. the SuSE Linux Live CD for Firewall

2. the SuSE Linux Admin CD for Firewall

For the sake of simplicity, we will mostly refer to these in this manual as “LiveCD” and “Admin CD”. The Live CD contains the firewall package proper, which,in our case, is based on the concept of an application-level gateway combined

12

2.3 An Overview of Typical FirewallSetups

with IP packet filtering. The firewall’s routing and gateway capabilities areturned off by default, but can be enabled as required. All requests accepted andprocessed by the firewall are handled at the application level. The package sup-ports the most important Internet protocols: SMTP, FTP, HTTP, HTTPS, DNS,and VPN.

With the Admin CD, install theSuSE Linux Adminhost for Firewall , which takescare of the configuration, monitoring, and administration of theSuSE Linux Fire-wall on CD . To properly manage these tasks, the CD includes a special selectionof software packages and the necessary installation routines.

Connecting an internal company network to the Internet will certainly require agood deal of planning, including a security concept based on a communicationanalysis and a demand analysis. Furthermore, there should be a concept describ-ing how to deal with emergencies, such as break-ins or data loss. Also make surethe firewall machine is protected from unauthorized physical access. The bestway to achieve that is to lock the machine in a separate server room.

2.2.1 Network Planning

Before beginning the installation of the firewall, consider your network layout.The diagrams in the following section can provide some ideas for layout options.The most important thing to do before you begin installing the software is toconsider what hardware to use for each part of the system.

The firewall host is a very special server.SuSE Linux Firewall on CD shouldnot be installed on your main server or another computer used in the network.It is best if the firewall host does not have a hard disk, although on is requiredfor usingSquid and similar programs. It needs, however, a floppy disk drive forthe configuration disk, a bootable CD-ROM drive for booting the Live CD, andnetwork interfaces. TheSuSE Linux Firewall on CD can serve as a gateway foryour system.

The Adminhost should be a dedicated machine. It is used to create the configu-ration floppy for the firewall host. It should be possible to run a graphical userinterface on this machine so you can use the Firewall Administration System(FAS) to configure the firewall and create the configuration disk. All neededprograms are included on the Admin CD. It can also be used as the log host.

The log host is a machine used to log the events on the firewall. It needs a largehard disk for storing information. This does not have to be a dedicated machine.It is recommended to make it a dedicated machine for reasons of security andalso use it as the Adminhost. It should never be unavailable to the firewall host.

2.3 An Overview of Typical Firewall Setups

This section gives a brief overview of the most typical firewall setups. All theconfigurations presented below can be implemented with theSuSE Linux Fire-wall on CD .

13


Figure 2.1: Very Basic Setup

Figure2.1shows a firewall with three network interfaces: an external one to con-nect to the Internet and two internal ones connecting with the corporate networkvia LAN or HUB and with the DMZ (demilitarized zone) using another HUB.

With this setup, the firewall has to perform all the functions of the default gate-way (router) and the packet filter. The internal network would be left completelyopen if the firewall were infiltrated.

Figure 2.2: Simple Setup

The setup shown in Figure2.2 is still a relatively simple one. The DMZ is onlyprotected by a packet filter on the router (screening router).

Figure 2.3: Effective and Manageable Setup

The setup shown in Figure2.3 is still not very complicated, but provides muchbetter protection than the previous ones. A “screening router” stops any ille-gal requests at the packet level. Packets allowed through are passed to the firstfirewall host, which operates at the application level and uses packet filteringrules to control access to the DMZ, to the second firewall host, and to the in-ternal network beyond. This second firewall is a packet filtering proxy machineprotecting the internal network. In addition to that, it controls access from theinternal network to the Internet and the DMZ.

14

3 SuSE Linux Adminhost for Firewall


It is no easy task to administer, maintain, and monitor a firewall. Above all,the importance of monitoring the firewall should not be underestimated. This iswhy theSuSE Linux Firewall on CD includes theSuSE Linux Adminhost forFirewall , which will help with configuring, administering, and maintaining theSuSE Linux Firewall on CD .

3.1 Introduction

After installing theSuSE Linux Adminhost for Firewall , theFirewall Adminis-tration System (FAS), a tool with a graphical administration interface, will beavailable, allowing a menu-driven configuration of theSuSE Linux Firewall onCD .

Configurable tools are available for monitoring the firewall that can perform testsof the firewall, evaluate the log files, and monitor network traffic. In the case ofan attack, there is the possibility of informing system administration by e-mail,pager, or another means, so suitable counter measures can be taken as quicklyas possible (for example, cutting off the network connection to the Internet orintranet).

A firewall without any monitoring cannot provide any real protection. Also, allchanges made to the firewall configuration should always be thoroughly docu-mented. By means of this documentation, errors can be found more easily ormodifications made by unauthorized parties can be changed back again.

After installing theSuSE Linux Adminhost for Firewall , choose between a newinstallation of the host reserved for this purpose or an update if SuSE Linux 7.2or the SuSE Linux Enterprise Server 7 is already installed on this host. In thefollowing section, we will describe updating, followed by instructions for thenew installation of theSuSE Linux Adminhost for Firewall .

3.2 Update

If you have already installed SuSE Linux 7.2, SuSE Linux Enterprise Server 7,or an olderSuSE Linux Firewall on CD on the computer that will serve asthe Adminhost for the firewall, you will not need to carry out a new installa-tion, but, rather, only install the required packages at a later point. While doingthis, choose between the graphical installation programYaST2 or the text-basedYaST.

15


� �

� NoteIf you are already running SuSE Linux Firewall on CD and want to updateto the VPN Edition, you only need to replace the fas packages with the fas2packages listed in the following section on update with YaST or YaST2.

Unfortunately, the configuration generated by the previous version was createdin a form not compatible with FAS2 configuration. However, you can convertthe existing configuration using a script.

As ‘root’ , run this script withfas_convertconfig.pl and follow the pro-gram’s instructions. The converted configurationtar archive will retain thesame name and location as the original one.

3.2.1 Update with YaST2

1. Log in to the graphical console as user‘root’ .

2. Start the YaST2 Control Center and select the ‘Software ’ module.

3. Insert the CD with the labelSuSE Linux Adminhost for Firewall.

4. Under ‘Change Source Media ’, select ‘Install from CD ’ for the sourcemedium.

5. Save and close the dialog.

6. Select the menu item ‘Software ’ and activate the checkbox ‘Show pack-age series ’.

7. Select the serieszfw then the packages:

• fas2

• fas2-flc-base

• fas2-flc-dns

• fas2-flc-ftp

• fas2-flc-http

• fas2-flc-ntp

• fas2-flc-mail

• fas2-flc-rinetd

• fas2-flc-ipchains

• fas2-flc-ipsec

• fas2-doc

• fasd2

• yast2-config-fwcdadmin

16

3.2 Update

• yast2-trans-fwcdadmin

The package dependencies will be resolved automatically.

8. To use this host as a log host as well, install the packagesyslog-ng fromthe seriesn.

3.2.2 Update with YaST

1. Log in to a console as user‘root’ .

2. Insert the CD labeledSuSE Linux Adminhost for Firewall.

3. Start YaST.

4. In the YaST menu, select the item ‘Package management ’.

5. Select ‘Change/create configuration ’.

6. Switch to serieszfw1 .

7. Select installation of all packages except packagefas-devel :

• fas2-flc-dns

• fas2-flc-base

• fas2

• fas2-flc-ftp

• fas2-flc-ntp

• fas2-flc-mail

• fas2-flc-http

• fas2-flc-rinetd

• fas2-flc-ipchains

• fas2-flc-ipsec

• fas2-doc

• fasd2

• yast2-config-fwcdadmin

• yast2-trans-fwcdadmin

8. The package dependencies will be shown. Resolve them by pressing�� F10

inside the ‘Unresolved dependencies ’ dialog.

17


Figure 3.1:YaST2 Control Center

3.2.3 Closing Update

After an update from SuSE Linux 7.2 or Enterprise Server 7 — regardless ofwhether you have installed the packages with YaST or YaST2 — you will stillneed to start the YaST2 module for theSuSE Linux Adminhost for Firewallusing the following command:

root@adminhost: # /sbin/yast2 fwcdadmin

Alternatively, start the YaST2 Control Center in KDE2 and, under ‘Network/-Base ’, start the ‘SuSE Firewall Adminhost ’ module (see Figure3.1).

After extending an existingSuSE Linux Firewall on CD to the VPN Edition, thisis not necessary. Instead, restart the fasd daemon as‘root’ with the commandrcfasd restart . Also convert old configurations as described in Section3.2on page15.

3.3 New Installation of the SuSE LinuxAdminhost for Firewall

To install theSuSE Linux Adminhost for Firewall for the first time, insert thisCD into the CD drive of the computer then reboot the machine. If the computerdoes not boot from the CD, change the boot sequence in the BIOS accordingly.

The linuxrc welcome screen will appear. Simply press�� ←↩ and the automatic

hardware detection will start.YaST2 will lead you through the rest of the instal-lation. All the necessary programs for administration, configuration, and main-tenance will be installed.

18


3.3.1 Language Selection

The first decision to make in the installation process is the language. Either usethe mouse or the keyboard. All entry fields, selection lists, buttons, and switchescan be selected by clicking with the mouse. To use the keyboard, the followingrules apply:

•�� Tab moves the focus forward to a field, an entry or selection field, or abutton.�� Shift +�� Tab moves the focus to the previous item. With

��↑ and��↓ , depending on which area is activated, make a selection or cycle througha list.

• With�� ←↩ , the selected command is carried out — the action shown on the

active button.

• With�� Space , entries can be marked.

• In addition, most actions can be started with the key combination�� Alt + the

underlined letter.

� �

�

TipHere and in the following dialogs, YaST2 is just collecting information. Later,YaST2 will display the information it has collected. In Section 3.3.7 onpage 22, you still have the chance, by means of the ‘Back ’ button, to re-turn to the previous dialogs and correct details.

Select your preferred language. When you have chosen a language, select ‘Ap-ply ’ to switch all texts to the selected language.

3.3.2 Selecting the Mouse

This dialog will only appear ifYaST2 was not able to detect the mouse automat-ically. A dialog window with a long list of mouse types appears from which toselect the appropriate mouse type.

Once you have found the right mouse type, move with�� Tab to the ‘Test ’ button

and press�� ←↩ . Now move the mouse. If the mouse cursor moves normally,

everything is working properly and you can click with the mouse on ‘Next ’. Ifthe mouse does not work, return to the selection list using

�� Tab and change thesettings.

If no mouse type functions or if you do not want to use a mouse, activate theentry ‘No mouse’. The rest of the installation will be carried out using only thekeyboard.

3.3.3 Keyboard and Time Zone

Select the keyboard layout and time zone.

19


Figure 3.2:YaST2: Keyboard Layout and Time Zone

• Now test your keyboard. By clicking with the mouse or using�� Tab , activate

the entry line and type in letters there. Especially test‘y’ , ‘z’ , and specialcharacters.

• The second item is a list of countries in a tree structure (continent/country/-region). Select your country or region from these.YaST2 will find the ap-propriate time zone.

Use ‘Next ’ to proceed to the next dialog window.

3.3.4 Preparing the Hard Disk

In the following steps, select the hard disk or disks and prepare them for theSuSE Linux installation. Depending on your computer’s hardware, there may beslight differences from the dialogs appearing here.

Step 1

If more than one hard disk exists, decide which one to use for the installation.The disks found will be listed. See Figure3.3 on the next page. Select the lastoption (‘Custom Partitioning ’) to “partition” them by hand. In this dialog,it is also possible to continue using existing partitions by specifying formattingand allocating mount points directly.

Normally, chooseonehard disk then click ‘Next ’.

Step 2

One of the following situations could occur:

20


Figure 3.3:YaST2: Preparing the Hard Disk

• If the hard disk isnot empty,YaST2 will show all existing partitions on thehard disk as well as the item ‘Use whole hard disk ’. Free, unpartitionedstorage space at the “end” of the hard disk is also displayed and is automat-ically preselected.YaST2 can use further space for SuSE Linux, but onlyif it is contiguous — partitions can only be released for further use “frombehind”. For example, if three partitions exist, partitions 1 and 2 will remainand you must select partition 3. To make the entire hard disk available forSuSE Linux, select ‘Entire Hard Disk ’.

• For anemptyhard disk, the entire hard disk will be used for SuSE Linux.

If you have other requirements, press ‘Back ’ to return to the previous dialog,as mentioned on the facing page, for manual partitioning with the help of ‘Ex-tended Settings ’.

� ��

NoteSince the partitions made available for SuSE Linux will be formatted, allexisting data there will be irretrievably lost.

Once the installation starts and all requirements have been fulfilled,YaST2 willpartition and format the necessary hard disk space on its own. The entire harddisk or the available partitions will be split up for SuSE Linux into the three stan-dard partitions: a small partition for/boot (about 16 MB) as close as possibleto the beginning of the hard disk, a partition for swap (128 MB), and all the restfor / (root partition).

21


3.3.5 Boot Manager Configuration

For Linux to be bootable after the installation, a boot mechanism must be in-stalled. Specify how the boot managerLILO “LInux LOader” should be installedor if another boot procedure should be used.

3.3.6 Setting the ‘root’ Password

The user‘root’ has special privileges in Linux. He can, for instance, startand stop system processes, create and remove users, and manipulate importantsystem files — in other words, perform the duties of the system administrator.

Figure 3.4:YaST2: Entering the‘root’ Password

Provide a password for the user‘root’ .

� �

� NoteYou must remember the ‘root’ password very carefully, as you access itlater to have a look at it. You will always need this password whenever youperform administrative tasks on the system.

If you press ‘Next ’, the installation will start.

3.3.7 Confirming Settings and Starting the Installation

Review all the settings made until now. To make changes, cycle through thewindows with the ‘Back ’ button, all the way back to the first window.

If you press ‘Next ’, you are asked again for confirmation (in green) to start theinstallation with the settings as shown. After confirming with ‘Yes -- in-stall ’, YaST2 will begin setting up the system. With ‘No’, you have the option

22


of checking data again and changing items where necessary by pressing ‘Back ’to reach the relevant window.

You now still have the option of aborting the installation completely. All settingsmade and details supplied will be lost. If you select ‘Abort installation ’,your computer, after asking for confirmation, will shut down and you can switchoff the computer or reboot without any problem. Up to this point, no changeshave been made to your computer.

With the option ‘Save Settings to Floppy Disk ’, save all details to floppydisk and use them again for other installations. This can only be selected if it issupported by your hardware.

After selecting ‘Yes -- install ’, partitions will be created and formatted.Depending on your system’s capacity and the size of the hard disk, this couldtake some time. Avoid aborting here, as this would put the hard disk into anundefined condition.

Afterwards, the packages from the CD are loaded and the SuSE Linux base sys-tem is installed. After you have confirmed this with ‘OK’, the text-oriented basesystem is started.YaST2 continues the installation of software and, if necessary,requests additional CDs. If you ‘Abort ’ the installation at this stage, the systemwill be unusable.

Configure the graphical interface, then try out SuSE Linux.

3.3.8 Preparing the Graphical Interface

To provide, even at the first login, a graphical user interface,YaST2 will now tryto find out all the information it needs for the monitor and graphics card.

If this is successful, a sensible screen resolution, color resolution, and repetitionrate frequency will be selected for the monitor and a test screen is displayed.

� ��

NoteCheck the settings before accepting. If you are not sure, consult the docu-ments for your graphics card and monitor.

If the monitor is not detected, select your model from the list provided. If youhave an unknown model, enter the settings by hand or have the data loaded froma “driver disk” provided with your monitor. Consult the documentation for yourmonitor.

Set up the required screen resolution and a color depth of16 bpp . Check thesettings by choosing ‘Test ’ and make fine adjustments if necessary.

� ��

TipIn rare cases, it may be necessary to configure the X server “by hand.” Todo this, run the program SaX at a later time.

23


3.3.9 Configuring the Network with YaST2

Have the following data on hand when configuring the network: IP address,network mask, and default gateway.

Figure 3.5:YaST2: Network Configuration

If you are managing a DHCP server, you can also configure theSuSE LinuxAdminhost for Firewall as a DHCP client. Youmustassign a static IP addressto the SuSE Linux Adminhost for Firewall . You will be provided with a se-lection of the network cards detected by the hardware recognition. Activate thenetwork card and enter the IP address and network mask. Enter all the requiredinformation if a name server already exists, as shown in Figure3.7 on the nextpage.

Figure 3.6:YaST2: Configuring the Network Address

24


Figure 3.7:YaST2: Configuring the Name Server

3.3.10 Manual Network Configuration

Manual configuration of the network software is a last resort. We recommendthat you useYaST, but YaST cannot cover all aspects of network configuration,requiring, in some cases, a bit of manual fine-tuning.

Configuration Files

This section provides an overview of the network configuration files and explainstheir purpose as well as the format used.

/etc/rc.configThe majority of the network configuration takes place in this central config-uration file. When making changes viaYaST or when calling upSuSEconfigafter the file has been modified manually, most of the following files will beautomatically generated from these entries. Even the boot scripts are config-ured via these file entries.

� �

� TipIf you modify this file by hand, you will always have to run SuSEconfigseparately afterwards so the modified configurations are entered intothe correct files.

/etc/hostsIn this file (see File3.3.1on the following page), IP addresses are assignedto host names. If no name server is implemented, all hosts to which an IPconnection will be made must be listed here. For each host, a line consisting

25


of the IP address, the fully qualified host name, and the host name (e. g.,earth ) is entered into the file. The IP address must be at the beginning ofthe line. The entries should be separated by blanks and tabs. Comments arealways preceeded by the‘#’ sign.

## hosts This file describes a number of host name-to-address# mappings for the TCP/IP subsystem. It is mostly# used at boot time when no name servers are running.# On small systems, this file can be used instead of a# "named" name server. Just add the names, addresses,# and any aliases to this file.#127.0.0.1 localhost192.168.0.1 sun.cosmos.com sun192.168.0.20 earth.cosmos.com earth# End of hosts

File 3.3.1:/etc/hosts

/etc/networksHere, network names are converted to network addresses. The format is sim-ilar to that of thehosts file, except the network names preceed the addresses(see File3.3.2).

## networks This file describes a number of netname-to-address# mappings for the TCP/IP subsystem. It is mostly# used at boot time, when no name servers are running.#loopback 127.0.0.0localnet 192.168.0.0# End of networks.

File 3.3.2:/etc/networks

/etc/host.confName resolution — the translation of host and network names via there-solverlibrary — is controlled by this file. This file is only used for programslinked to the libc4 or the libc5. For current glibc programs, refer to the set-tings in/etc/nsswitch.conf . A parameter must always stand alone in itsown line and comments preceeded by a‘#’ sign. Table3.1 on the facingpage shows the parameters available.

orderhosts, bind Specifies in which order the services are ac-cessed for the name resolution. Available ar-guments are (separated by blank spaces or com-mas):hosts: Searches the/etc/hosts filebind: Accesses a name server

Table3.1: continued overleaf...

26


nis: Via NISmulti on/off Defines if a host entered in/etc/hosts can

have multiple IP addresses.nospoofonalerton/off

These parameters influence the name serverspoofing, but, apart from that, do not exert anyinfluence on the network configuration.

trim <domainname> The specified domain name is separated fromthe host name following the host name resolu-tion (as long as the host name includes the do-main name). This option is useful if only namesfrom the local domain are in the/etc/hostsfile, but should still be recognized with the at-tached domain names.

Table 3.1: Parameters for/etc/host.conf

An example for/etc/host.conf is shown in File3.3.3.

## /etc/host.conf## We have named runningorder hosts bind# Allow multiple addrsmulti on# End of host.conf

File 3.3.3:/etc/host.conf

/etc/nsswitch.confWith the GNU C Library 2.0, the “Name Service Switch” (NSS) becamemore important. See the man page fornsswitch.conf or, for more details,The GNU C Library Reference Manual, Chap. "System Databases and NameService Switch". Refer to packagelibcinfo , seriesdoc ).

In the /etc/nsswitch.conf file, the order of certain data is defined. Anexample ofnsswitch.conf is shown in File3.3.4on the following page.Comments are preceeded by‘#’ signs. Here, for instance, the entry under“database”hosts means that a request is sent to/etc/hosts (files ) viaDNS (see SectionA on page113).

The “databases” available over NSS are listed in Table3.2 on the followingpage. In addition,automount , bootparams , netmasks , andpublickeyare expected in the near future.

27


## /etc/nsswitch.conf#passwd: compatgroup: compat

hosts: files dnsnetworks: files dns

services: db filesprotocols: db files

netgroup: files

File 3.3.4:/etc/nsswitch.conf

aliases Mail aliases implemented bysendmail ; see also the manpage foraliases .

ethers Ethernet addresses.group For user groups, used bygetgrent ; see also the man

page forgroup .hosts For host names and IP addresses, used by

gethostbyname and similar functions.netgroup Valid host and user lists in the network for the purpose of

controlling access permissions; see also the man page fornetgroup .

networks Network names and addresses, used bygetnetent .passwd User passwords, used bygetpwent ; see also the man

page forpasswd .protocols Network protocols, used bygetprotoent ; see also the

man page forprotocols .rpc “Remote Procedure Call” names and addresses, used by

getrpcbyname and similar functions.services Network services, used bygetservent .shadow “Shadow” user passwords, used bygetspnam ; see also

the man page forshadow .

Table 3.2: Available “Databases” via/etc/nsswitch.conf

The configuration options for NSS “databases” are listed in Table3.3on thenext page.

28


files directly access files, for example, to/etc/aliases .db access via a database.nis NISnisplusdns Only usable byhosts andnetworks as an extension.compat Only usable bypasswd , shadow , andgroup as an ex-

tension.also it is possible to trigger various reactions with certain

lookup results; details can be found in the man page fornsswitch.conf .

Table 3.3: Configuration Options for NSS “Databases”

/etc/nscd.confThe nscd (Name Service Cache Daemon) is configured in this file (see theman pages fornscd andnscd.conf ). This affects the data resulting frompasswd , groups , andhosts . The daemon must be restarted every time thename resolution (DNS) is changed by modifying the/etc/resolv.conffile. The following command serves this purpose:earth: # rcnscd restart

� �

� CautionIf, for example, the caching for passwd is activated, it will usually takeabout fifteen seconds until a newly added user is recognized by thesystem. By resarting nscd, reduce this waiting period.

/etc/resolv.confAs is already the case with the/etc/host.conf file, this file, by way oftheresolverlibrary, plays a role in host name resolution.

The domain to which the host belongs is specified in this file (keywordsearch ) and the status of the name server address (keywordname server )to access. Multiple domain names can be specified. When resolving a namethat is not fully qualified, an attempt is made to generate one by attaching theindividual search entries. Multiple name servers can be made known byentering several lines, each beginning withname server . Comments arepreceeded by‘#’ signs.

An example of/etc/resolv.conf is shown in File3.3.5on the followingpage.

YaST enters the given name server here.

Some services like pppd (wvdial), ipppd (isdn), dhcp (dhcpcd and dhclient),pcmcia, and hotplug modify the file/etc/resolv.conf . To do so, theyrely on the scriptmodify_resolvconf .

29


# /etc/resolv.conf## Our domainsearch cosmos.com## We use sun (192.168.0.1) as name servername server 192.168.0.1# End of resolv.conf

File 3.3.5:/etc/resolv.conf

Now if the file /etc/resolv.conf has been temporarily modified by thisscript, it will contain a predefined comment giving information about the ser-vice by which it has been modified, about the location where the original filehas been backed up, and hints on how to turn off the automatic modificationmechanism.

If /etc/resolv.conf is modified several times, the file will include mod-ifications in a nested form. These can be reverted in a clean way even if thisreversal takes place in an order different from the order in which modifica-tions where introduced. Services that may need this flexibility include isdn,pcmcia, and hotplug.

If it happens that a service was not terminated cleanly,modify_resolvconfcan be used to restore the original file. Also, at system boot a check willbe performed to see whether there is an uncleaned, modifiedresolv.conf(e. g., after a system crash), in which case the original (unmodified)resolv.conf will be restored.

YaST uses the commandmodify_resolvconf check to find out whetherresolv.conf has been modified and will subsequently warn the user thatchanges will be lost after restoring the file.

Apart from this,YaST will not rely on modify_resolvconf , which meansthat the impact of changingresolv.conf throughYaST is the same as thatof any manual change. In both cases, changes are made on purpose and witha permanent effect, while modifications requested by the above-mentionedservices are only temporary.

/etc/HOSTNAMEHere is the host name without the domain name attached. This file is readby several scripts while the machine is booting. It may only contain oneline where the host name is mentioned. This file will also automatically begenerated from the configuration in/etc/rc.config .

Start-Up Scripts

Apart from the configuration files described above, there are also various scriptsthat load the network programs while the machine is booted. This will be startedas soon as the system is switched to one of themultiuser runlevels(see alsoTabel3.4on the next page).

30


/etc/init.d/network This script takes over the configuration forthe network hardware and software during thesystem’s start-up phase. During this process,the IP and network address, netmask, andgateway specifications entered byYaST in the/etc/rc.config file will be evaluated.

/etc/init.d/route Serves the purpose of setting static routesover the network.

/etc/init.d/inetd Starts inetd, as long as it is specified in/etc/rc.config . This is only necessary ifyou want to log in to this machine over thenetwork.

/etc/init.d/portmap Starts the portmapper needed for the RPCserver, such as an NFS server.

/etc/init.d/nfsserver

Starts the NFS server.

/etc/init.d/sendmail Controls thesendmail process depending onthe configuration in/etc/rc.config .

/etc/init.d/ypserv Starts the NIS server depending on the con-figuration in/etc/rc.config .

/etc/init.d/ypbind Starts the NIS client depending on the config-uration in/etc/rc.config .

Table 3.4: Some Start-Up Scripts for Network Programs

3.3.11 The User ‘fwadmin’ for the FAS

Figure 3.8: The User for the Firewall Administration System (FAS)

31


In the ‘fwcdadmin ’ configuration mask (see Figure3.8on the preceding page),set up a user with which to configure the SuSE Firewall CD. Enter a user name.The default name is‘fwadmin’ . Also specify a home directory for the user.The default for this is/var/lib/fwadmin .

In the next configuration mask, assign a password for the firewall admin user.This password must be at least five characters long. In addition, you must definea “pass phrase” and repeat this in the next field to confirm it (see Figure3.9).

Figure 3.9: SSH Passphrase for the Admin User

32

4 Firewall Administration System (FAS)


Following installation, the system will boot to the graphical login. Log in here asuser‘fwadmin’ with your password. In all cases, FAS will only function afterthe system has been rebooted.

4.1 Logging In as ‘fwadmin’

After login, the user desktop for‘fwadmin’ opens with an icon that starts theadministration desktop for direct configuration of theSuSE Linux Firewall onCD . The icon is shown in Figure4.1.

Figure 4.1: FAS Icon

4.2 Starting the Firewall Administration System

FAS is the graphical administration interface for creating the configuration diskfor theSuSE Linux Firewall on CD . FAS supports multiple users and is able tomanage several configurations.

FAS is a client and server system made up of the GUI and thefasd serverdaemon. The fasd (fas daemon) manages the different configurations, makeschanges, and checks the entries for accuracy. The front-end receives the userdata and forwards it to the server. In this version, communication between thefront-end and back-ends takes place over Unix domain sockets.

There are several ways to start the Firewall Administration System:

1. Icon on desktop (see Figure4.1)

2. Menu selection

3. Enter the commandFASat the command line (e.g., xterm).

4.3 Creating a New Firewall Configuration

Once you have started the configuration program FAS, create a new user accountin FAS. To do this, select the item ‘Create Login ’ in the ‘File ’ menu. A

33


Figure 4.2: Desktop with FAS and Help Window

dialog will emerge where you can enter a new user name and password. The username must be at least five characters long. The password must be between fiveand eight characters long. This password protects the configuration of theSuSELinux Firewall on CD , so the password will be authenticated by the programcracklib.Good passwords should not be able to be guessed by others, so do not use yourbirth date, street address, or the name of your favorite celebrity. They should notbe too short, but still should be able to be typed quickly, so no one can see whatyou are typing. Use a mixture of numbers and uppercase and lowercase letters.Of course, in any case, it is important that you can also remember your passwordand not have to write it down. Good methods of coming up with a password areabbreviations of sentences or expressions that are easy to memorize. Here aresome examples:

• NE14TenS (anyone for tennis?)

• AuaEGC (all UNIX admins eat green cheese)

• Me1st (Me first)

• IwIhagp (I wish I had a good password)

The configuration of theSuSE Linux Firewall on CD is saved to a.tar.gzarchive. To edit a configuration already created, give this password again.After logging in, select ‘Configuration ’ → ‘New Config ’. A new windowwill appear in which to define a name for the configuration. Also enter a descrip-tion of the configuration. This description can be used to explain the purposeof the configuration and to document who, when, and what has changed. Thedescription of the configuration can be expanded later or changed at any time.Use this option, because good documentation is essential. Confirm with ‘OK’.You will now see the name of your new configuration in the left window panel.If you click the name once, the configuration description will appear to the right.

34

4.3 Creating a New FirewallConfiguration

Edit your description. To save changes to your configuration description, click‘Save the changes ’. Double-click the configuration name or on the button‘Open Configuration ’ to begin creating your configuration.

In the left window panel, a list will appear with the configuration modules — theservices you can use to configure your firewall — along with the status of eachmodule. The first thing to do is configure the base module (‘Base module ’ and‘Syslog Module ’). As long as these modules are unconfigured (symbolized bya cross), you cannot choose any of the other modules.

The following FAS modules are available:

• Base Module for basic configuration of network interfaces, host name, androot password

• DNS Module (Name Server)

• External FTP (Configuration of FTP Proxies: External to Internal or DMZ)

• External HTTP (Configuration of HTTP Proxies: External to Internal orDMZ)

• IPCHAINS Module (Import of a selfgenerated ipchains rule set)

• IPSEC Module (Configuration of IPsec tunnels)

• Internal FTP

• Internal HTTP

• Mail Module

• NTP Module (Configuration of xntpd to synchronize the computer time witha time server)

• SSH Module

• SuSE Firewall Module (Creating a Packet Filter with the SuSE FirewallScript)

• Syslog Module (Configuration of syslogd on the Firewall)

• rinetd Module (Configuration of the TCP proxy rinetd)

35


4.3.1 Configuration of the Base Module

The base configuration takes place in five steps:

1. ‘root’ password for the firewall:

Figure 4.3: Define‘root’ Password

In this dialog (see Figure4.3), the‘root’ password is set for the firewall. Ifyou do not give a‘root’ password (use the ‘Disable ’ checkbox), no onewill be able to directly log in to the firewall host as‘root’ during futureoperation. Access is only possible viaSSH and RSA key, ifSSH is config-ured. The checkbox ‘Enable serial console ’ activates the connectionof a serial console that can be used to control the firewall.

2. Setup of the optional hard disk (see Figure4.4):

Figure 4.4: Hard Disk Setup

36


If you activate ‘Use hard disk ’, make the following settings:

Disk Device: Sets the hard disk to integrate, for example,/dev/hda (firsthard disk on the first IDE controller)

Disk Swap Space: Size of the swap partition, for example, 128 MB or 64MB

Use /var on Disk: Should the directory/var be located on the hard diskdevice?

Enable IDE DMA: Activates DMA for IDE

If you use the e-mail proxy, enable the caching for the HTTP proxy, or wantto save log messages to the hard disk, the hard disk must be configured and/var activated.

3. Network interfaces (see Figure4.6on the following page):

Figure 4.5: Network Interfaces

In this dialog, find a list with network interfaces already created. Up to teninterfaces can be given, with a minimum of one internal and one external.

‘Add’ adds a new network interface. A window will appear with the ‘In-terface Dialog ’. (see Figure4.6on the next page). The following data isrequired:

Network Type: ethernet is the “default” (this version only supports ether-net).

Device Name: give in consecutive order

IP Address: IP addresses to assign to the interface

Netmask: the netmask of the IP address

Direction: internal or external — is the interface connected to the intranet,the DMZ, or the Internet?

37


Figure 4.6: Adding a New Network Interface

‘OK’ confirms the settings. ‘Cancel ’ aborts the dialog. The newly configuredinterface will now appear in the list. ‘Edit ’ reconfigures an already exist-ing interface. Select an interface from the list and choose ‘Edit ’ to makechanges. ‘Delete ’ deletes the selected interface.

4. Routing (see Figure4.7)

Figure 4.7: Routing Configuration

Here, set specific routes. ‘Add’ creates a new route. ‘Edit ’ edits an alreadyexisting one.

In the dialog box ‘Configure Routing ’ (see Figure4.8on the next page),the following settings can be made:

Destination: Which network or host should be the routing destination? En-ter the network address (e. g.,192.168.0.0 ).

Gateway: If a gateway is necessary, what IP address does it have?

Netmask: The corresponding network mask.

Interface: Over which interface should the route run?

Save the settings with ‘OK’ as before. Abort the configuration with ‘Cancel ’.With ‘Delete ’, delete an existing route.

38


Figure 4.8: Routing

Figure 4.9: Host and Domain Configuration

5. Host name and name server settings (see Figure4.9):

Firewall Host Name: Specify the name of the firewall host. Avoid namessuch asgateway or firewall .

Firewall Domain: Specify the name of the domain where the firewall is.

Name Server: For proper configuration of the resolver, specify the nameserver IP addresses and the search lists, for example,your-company-inc.com.

4.3.2 Syslog Configuration

In this dialog (see Figure4.10on the next page), configure the behavior of thesyslog daemon.You have the option of directing the output of syslogd to the hard disk or to a loghost. Specify a list of IP host addresses where you want the logs written. Thesehosts must also be configured to receive the logs. TheSuSE Linux Adminhostfor Firewall is already geared toward these tasks.The configuration of the syslog-ng on theSuSE Linux Adminhost for Firewallis explained more thoroughly in Section4.8on page74.

39

your-company-inc.com

your-company-inc.com


Figure 4.10: Syslog Configuration

4.3.3 DNS Configuration

In this menu, the name serverBIND8 will be configured. Detailed descriptionsof DNS andBIND8 can be found in AppendixA on page113.

Figure 4.11: DNS Configuration

Forwarder IP Addresses: Here, specify whether to forward DNS requests toone or more different name servers. To do this, enable the checkbox ‘For-warder IP Addresses ’. This will activate the list box. Now, specify a listof name servers to which DNS requests should be forwarded. If you activatethe checkbox ‘Forwarder only ’, the name server requests will only be for-warded to the name server set. If it is disabled, the other “root” name servers

40


will be contacted (commonly recognized name servers in the Internet) (seeFigure4.11on the facing page).

Listen to selected IP Addresses: Normally, theBIND8 name server acceptsrequests from all available network interfaces — from the internal as well asfrom the external network interfaces and the loopback interface. In the listbox, select the interfaces on which DNS requests can be accepted.

4.3.4 IP Filter Configuration with ipchains

In the FAS ipchains module (see Figure4.12), specify a file to which you saved apacket filter configuration usingipchains-save (see alsoman 8 ipchains ).This file will be loaded and subsequently saved to the configuration disk. Thisconfiguration can be adopted in this manner by the firewall.

Figure 4.12: IP Packet Filter Configuration withipchains

4.3.5 Configuration of the SuSE Firewall Module

This module allows configuration of the SuSE Firewall Script step by step.

1. First, specify which of the network interfaces configured in the base moduleis designated for the DMZ (Demilitarized Zone) or for your internal network.The interfaces specified as internal in the base configuration will appear here.Select from the list by clicking with the mouse (see Figure4.13on the fol-lowing page). The interfaces specified as external in the base module willautomatically show up in the text field ‘Internet Device ’.

2. Routing filter: Here, enable direct routing from IP packets by specifying asource and destination address a well as a destination port (see Figure4.14on page43). You will need this for services that do not have proxies.

41


Figure 4.13: Selecting Devices

In this dialog, also specify whether masquerading should be used. This mightbe necessary if you only have a small number of official IP addresses soneed to assign private IP addresses that are not routed in the Internet to thehosts in your local network. Activate the checkbox ‘Masqueraded ’ for theconnection.

To route IPsec connections through the firewall, select50 in ‘Protocol ’,the port number for the IPsec family.

� ��

NoteThe port for isakpm (UDP) for these connections also needs to be routedthrough the firewall.

3. Redirection: To enable transparent proxying, reroute the packets, for ex-ample, if you want to carry out transparent configurations of the internalHTTP proxy. The IP packets have an internal IP address as a source addressand, as a destination address, an Internet IP address. These IP packets haveport 80 (www) as the destination port. Your HTTP proxy, however, waits onport 3128 for the packets on your firewall. This rerouting procedure froma destination address with destination port 80 to the required localhost port3128 can be configured in this screen (see Figure4.15on page44).

4. Release of ports for internal access to the firewall. Which firewall servicesdo you want to make available for the internal network? Select from the listprovided (see Figure4.16on page44).

The checkbox ‘Allow internal crypted IPSEC connection ’ must beactivated, if a VPN tunnel from the internal network to the firewall hostshould be possible.

42


Figure 4.14: Routing Filter

5. Release of external ports to the firewall: Select from the list the ports torelease for this purpose — those that can be accessed from the Internet (seeFigure4.17on page45).

The checkbox ‘Allow external crypted IPSEC connection ’ needsto be activated if a VPN tunnel from the Internet to the firewall host shouldbe possible.

6. Release the ports to access the firewall from the DMZ by selecting, onceagain, from the list provided (see Figure4.18 on page45). If you did notchoose a DMZ interface (in item 1), this screen will be disabled.

The checkbox ‘Allow crypted IPSEC connection from DMZ ’ needsto be activated if a VPN tunnel from the DMZ to the firewall host should bepossible.

7. Logging and kernel modules

• Select the log level for the packet filters from the series of checkboxes. Indoing so, be aware that log files can grow very quickly if you are loggingall the packets together.

• In the selection field pertaining to the kernel modules, choose the mod-ules needed if using certain applications that operate independently of thefirewall (see Figure4.19on page46).

43


Figure 4.15: Packet Redirection

Figure 4.16: Releasing Internal Ports to the Firewall

44


Figure 4.17: Releasing External Ports to the Firewall

Figure 4.18: Releasing Ports from the DMZ to the Firewall

45


Figure 4.19: Logging and Kernel Modules

46


4.3.6 Configuring the Mail Relay (Postfix)

This module can only be used if a hard disk was configured during the baseconfiguration.

Figure 4.20: Configuration of the Mail Relays — Dialog 1

Internal mail server: Specify the IP address or the name of your internal mailserver (see Figure4.20).

Relay the following domains: Can be used to specify the domain names toreceive relayed mail and forward mail to your mail server.

ISP relay: Activate this checkbox if you forward all outgoing e-mail to theSMTP server of your Internet Service Provider (ISP). Specify the name (FQHN)or the IP address of the SMTP server of your provider.

Local networks: List of local networks. Postfix decides by means of this list ifa network can send e-mails over the firewall. Enter your networks here (e. g.,192.168.0.0/24 ) (see Figure4.21on the following page).

Listen to selected IP addresses: Here, enter the IP addresses where the mailrelay receives requests.

47


Figure 4.21: Configuration of the Mail Relays — Dialog 2

48


4.3.7 SSH Configuration

Figure 4.22: Adding and Deleting SSH Keys

SSH keys: Here, you have the option of saving your “ssh public key” for ac-cessing the firewall as‘root’ so that you can, if necessary, log on to thefirewall host. You have two options here (see Figure4.22):

• Import a key. An “ssh key” normally is located in the user’s home direc-tory in the.ssh/ directory asidentity.pub . Select this file. The keywill then appear in the list (see Figure4.23).

Figure 4.23: Importing the Key

• You can also enter a key by way of copying and pasting. If you click ‘Addkey ’, a dialog will open (see Figure4.24on the next page). In the textfield, specify your “ssh public key” and confirm with ‘OK’. This key willnow appear in the list below.

Delete key: Select the key to delete. Click ‘delete key ’. The selected keywill be deleted.

49


Figure 4.24: Adding the Key

Enable fallback password authentication: If this checkbox (see Figure4.25)is activated, you can log in to the firewall using your password. Do not dothis. We advise only allowing access via RSA keys.

Listen to selected IP address: On which network interface shouldssh acceptrequests? Enter the IP addresses in the list field.

Figure 4.25: SSH Configuration

4.3.8 FTP Access — External to Internal

If you are administrating your own FTP server, make the following settings here(see Figure4.26on the next page):

FTP Server IP Address: The IP address of your FTP server in the intranet orDMZ

FTP Proxy Port: The port where your FTP server is listening, normally port21. With this, your firewall is seen externally as an FTP server. Requestan alias entry in the DNS for your firewall from your provider, for example,ftp.mycompany.com.

Maximum No. of Clients: Maximum number of FTP clients that can be simul-taneously connected to the FTP server

50


Figure 4.26: Configuration of the FTP Server

Listen to selected IP address: IP address of the interface where the FTP serveraccepts connections

4.3.9 Configuring the FTP Proxy — Internal to External

Figure 4.27: Configuration of the FTP Proxy

FTP Proxy Port: 10021Port to which the FTP proxy responds.

MagicUser: Use this parameter to specify the destination FTP server selectedin the user name: user[@host[:port]]. This may appear as follows:

51


> ftp [email protected]:21

Magic Char: The MagicChar character is normally set to “%”. If the option‘Magic User ’ is enabled, any character can be used for this.

Maximum No. of Clients: Maximum number of open connections on the FTPproxy.

Listen to selected IP address: IP address over which the FTP proxy responds.

4.3.10 Configuring the HTTP Proxy: Internal to External

In this module, make settings for the HTTP proxy. This module processes HTTPrequests by internal network users.

HTTP Proxy

The following entries are required for the configuration of the HTTP proxy:

Figure 4.28: Configuration of the HTTP Proxy — Dialog 1

HTTP Proxy Port Set the port where the proxy should accept internal HTTPrequests. Default setting is port3128 (see Figure4.28).

Listen to selected IP addresses Here, define the IP address of the firewallfrom which HTTP requests can be received. In the selection list, find theinterfaces specified in the base configuration as internal.0.0.0.0 stands forall firewall interfaces.

Transparent Proxy Basically, this only monitors the proxy on port 3128. Ifan HTTP request is submitted, this will run over port 80 and will not beprocessed. The option ‘Transparent Proxy ’ must be activated to process

52


this request. In conjunction with this, a “redirect” rule (rerouting) must exist,which will reroute the request inside the firewall to port 3128. If this optionis not enabled, all clients or the internal proxy must have the firewall enteredas proxy.

Caching? For repeated HTTP requests, activate the option ‘Caching? ’ to pre-vent valid pages from being reprocessed. The size of the cache can be definedin the entry field provided and should not be less than 100 MB.

� �

� CautionThe firewall should not be used as a buffering HTTP proxy, becausethis is not the actual purpose of the firewall. A better solution is usinganother independent host.

After making all desired changes, confirm the settings with ‘Next ’.

Defining ACLs


Define who can use the proxy and what these users are able to access on theInternet (see Figure4.29).

Name of ACL First, name the list to add.

Type Next, select a ‘Type ’ for your ACL. You have the choice among:

url_regex Specify URL addressesproto (protocol) Define the respective protocolssrc (source) Define the source addressesdest (destination) Specify destination addresses

53


Add Add the new ACL to the list of already existing ACLs.

Delete Delete ACLs.

Edit ACL In this window, enter or change values attributed to a selectedACL. Insert new values or edit and delete already existing ones in theentry field.After making all desired changes, confirm the settings with ‘Next ’.

Arranging ACLs


Find various options for setting up the rules (ACL) on this module page. Theselected settings for ‘ACL’ and ‘Negate ACL ’ are linked by the logical “AND”(see Figure4.30).

• In ‘Action ’, choose between ‘allow ’ to permit or ‘deny ’ to prohibit Inter-net access defined below.

• Specify, via ‘ACL’, an already existing list to which the settings will apply.

• Specify an ACL that should be negated via ‘Negate ACL ’. In this man-ner, you can, for instance, allow retrieval of Internet sites (selection un-der ‘ACL’), which will, however, not run over SSL ports (selection under‘Negate ACL ’).

• A new rule can be integrated via ‘Add’.

• Click the respective rule in the list field to edit it. At this point, the settingsin the above portion will be applied. Modify them and save the changes with‘Edit ’.

• Click ‘Delete ’ to remove rules after selecting the respective item.

54


• In the lower part of the window, find a list field with entries pertaining to allactions and their ACL settings.

� �

� CautionThe order of rules in the list field is very important, because the list willbe processed from top to bottom. According to the first match, accessto the requested URL will either be accepted or denied.

• To move a rule up or down, click the rule and activate the button in the rightwindow margin with the corresponding arrow.

• After making all desired changes, confirm the settings with ‘Next ’.

Content Filter


To filter or search for certain HTML page contents and, if needed, to block con-tents, activate the checkbox next to ‘Content Filter ’ (see Figure4.31).

� �

� NoteYou should be able to program HTML to configure this filter. The “tags” and“attributes” discussed in the following are HTML components, the program-ming language in which web sites are written.

All the added filter settings can be found in the lower window panel. There,see names attributed to types, actions defined, and substitutions specified. Allundefined HTML tags or attributes will be denied.

55


Proceed as follows:

• To add a filter rule, select the respective type from the selection field withthe same name. Choose between ‘tag ’ and ‘attr ’ (for an attribute). In the‘Name’ entry field, specify the text of the “tag” or “attribute” then select an‘Action ’. Multiple labels for actions are also possible. Choose from:

allow permits the selected tag or attribute

log sets an entry into the “log file” and can be used later for setting up filterstrategies

replcont replaces the tag or attribute and continues evaluating the attribute

replabort replaces the tag or attribute and stops evaluating the attribute

• Both of the following actions serve to remove entire coded sections from therequested documents:

replskip shows the beginning of an omission, which will not be forwardedto the user.

replendskip shows the end of the omission.

• In the entry field next to ‘Replacement ’, enter the string to use instead ofthe first one. No blanks spaces are permitted. Instead, use to insert ablank space. Here, of course, it only makes sense to insert something if youhave selected ‘replcont ’, ‘ replabort ’, ‘ replskip ’, or ‘ replendskip ’as an action.

• To edit a filter rule, select it from the list field. See the values in the entryand selection fields located in the upper portion of the window. Modify thevalues and confirm by clicking on ‘Edit ’.

• To remove filter rules, select them from the list field and click ‘Delete ’.

MIME Type Filter

Introduction

Content filtering on theSuSE Linux Firewall on CD is done by thehttpf-proxysoftware. A part of the content filtering is configured in the previous dialog,based on tags found in HTML code. Content filtering can also be accomplishedby the MIME type of documents retrieved via http. Well-known MIME typesinclude image data (such as gif or jpeg), audio data (such as mpeg or wav), orvideo data (such as mpeg or avi).

By means of the transferred bit stream of retrieved data, the MIME type of adocument can be recognized. Therefore, it is possible to allow or disallow thetransfer of the corresponding file. The default policy ofhttpf is to deny the trans-fer of any unknown MIME type.

It is also possible to test if the bit stream corresponds to the MIME type the fileformat specifies. For example, an executable disguised as a more or less harmlessgif picture.

56


Use the ‘MIME Type Editor ’ module in the FAS to configure the content fil-tering. This configuration will be saved to the configuration disk together withthe rest of the firewall configuration.

Usage

The window labeled ‘Mime Type Filter ’ shows a list of all MIME types al-ready configured.

The three fields ‘MIME Type’, ‘ Offset ’, and ‘String ’ are for regenerating andediting MIME types. ‘MIME Type’ specifies the MIME type involved. ‘Offset ’indicates the location of the string ‘String ’ after the beginning of the file. Both‘Offset ’ and ‘String ’ are optional, because not all file formats are clearlyidentifiable.

All MIME types must be defined in this interface that should be passed throughthe MIME type and content filter. A configuration containing most MIME typesis included in the default template.

Figure 4.32: Configuration of the HTTP Proxies — Dialog 5

Parent Proxy Configuration

If your provider supplies specific proxy for HTTP requests, the IP address ofthe proxy can be entered in the field next to ‘Parent Proxy IP Address ’.The provider’s HTTP port is then entered under ‘Parent Proxy Port ’. SeeFigure4.33on the following page).

If the content filter is disabled, specify, under ‘Parent Proxy ICP Port ’ (ICPis internet caching protocol), the provider’s ICP port if their proxy supports ICP.

After making all desired changes, confirm the settings with ‘Next ’.

57



4.3.11 Configuring the HTTP Proxy: External to Internal

If you are not managing your own web server, you will not need to configureanything here. Otherwise, make the following settings (see Figure4.34):

Figure 4.34: Configuration of the External HTTP Proxy

HTTP Proxy Port: The port listens on the proxy, normally port 80. In thisway, your firewall becomes the web server when viewed from the outside.Therefore, request an alias for your firewall from your provider, for example,www.my-company.com

Listen to Selected IP Address: IP address of the interface where the proxyaccepts connections.

58

www.my-company.com


Web Server IP Address: The IP address of your web server located on yourintranet.

Web Server Port: Normally port 80.

4.3.12 The FAS Keyring Module

The FAS Keyring Module is used to create, import, and manage the X.509 cer-tificates for authentication. The module is not displayed in the list on the leftside, but reached via the menu ‘Modules ’ → ‘Certificate Management ’.

About Certificates and the Certificate Authority (CA)

The keys and certificates are created on the Adminhost with the program packageOpenSSL.

SSL and PKI: Encryption with SSL is done in an asymmetric way. For en-cryption and decryption, a pair of keys is always necessary. This pair consists ofa public and a private key.

PKI asymmetric encryption: In this mechanism, the public keys are exchangedbetween the client and the server computers. Encryption takes place with thepublic key of the corresponding site. For decryption, the private key is needed.

CA Certificate Authority

A certificate is signed by a CA. Therefore, you need a CA. You can use one ofofficial sites that own CAs, but then you must submit all your certificates to oneof these sites for signing. Alternatively, create a CA of your own to sign yourcertificates. This is sufficient for most purposes.

X.509 Certificates

A X.509 Certificate consists of the following parts:

• version

• serial

• signature algorithm ID

• issuer name

• validity period

• subject (user) name

• subject public key information

59


• issuer unique identifier (version 2 and 3 only)

• subject unique identifier (version 2 and 3 only)

• extensions (version 3 only)

• signature on the above fields

FAS has a front-end for creating a X.509 certificate.

Certificate

Start FAS and login as the admin user‘fwadmin’ . Choose ‘Modules ’ → ‘Cer-tificate Management ’.

A list of already existing certificates will be displayed (Figure4.35).

Figure 4.35: List of Certificates

Normally at the first start, no CA (Certificate Authority) exists. A CA is neededto create certificates for your clients.

Create Certificate Authority

This dialog can only be opened once. The CA is global for all configurationsmade on this Adminhost. All certificates to create will be signed by this CA.

Select ‘Certificate Management ’ → ‘Create CA ’ from the menu. Refer toFigure4.36on the next page. Fill out the dialog completely. Many of the settingswill be transferred to the certificates later.

• First, choose a ‘Name’ (cn) for your certificate. For example, the name ofyour company.

• In ‘E-mail address ’, enter the e-mail address of the employee responsiblefor the CA.

60


Figure 4.36: Dialog to Create a CA

• In ‘Organizational unit ’ (ou), enter the department.

• Choose your company’s name for ‘Organization ’ (o).

• ‘Locality ’ (l), ‘ State ’ (st), and ‘Country ’ (c) refer to your geographicalposition.

• ‘CA password ’: Enter the passphrase for the CA to secure it and retype toverify it.

• ‘Key Size ’: Choose between 1024 bit and 2048 bit. The longer the key is,the better the protection is.

To save your settings, confirm with ‘OK’. If everything went fine, a notificationappears.

Creating a Certificate

Select from the menu ‘Certificate Management ’ → ‘Create Certifi-cate ’. In the following dialog, add the entries for a new certificate. Some of thefield will be filled already with the information from the CA (Figure4.37on thefollowing page).

• First, choose a ‘Name’ (cn) for your certificate. For example, the name of thehost for which the certificate is created.

61


• ‘E-mail address ’

• ‘Organizational unit ’ (ou)

• ‘Organization ’ (o)

• ‘Locality ’ (l)

• ‘State ’ (st)

• ‘Country ’ (c)

• ‘CA password ’: To sign the new certificate with the CA, the CA passwordneeds to be entered.

• The new certificate should also be secured with a password that needs to beretyped for verification.

• ‘Key Size ’: the default is 2048 bit.

When you are done, click ‘OK’. When the creation was successful, you get amessage and the new certificate shows up in the list.

Figure 4.37: Dialog to Create a Certificate

Revoking a Certificate

Select a certificate to revoke from the list. Choose ‘Key ’ → ‘Revoke Certifi-cate ’. You are prompted for the passphrase of the signing CA. Confirm the pop-up message ‘Do you really want to revoke this certificate ’ with‘OK’. After successful revocation of the certificate, a message to that effect ap-pears.

62


Importing Certificates

Select ‘Certificate Management ’ → ‘ Import Certificate ’. Choose thedirectory from which to import and the certificate type in the ‘File type ’ box.The certificates will be shown. Select the certificate.

Certificates to import can have three different formats: DER, PEM, and PKCS12.With DER and PEM, no additional settings are necessary. For a PKCS12 cer-tificate, a password dialog appears in which to enter the import password. Fur-thermore, you are required to specify a new certificate password and retype it forconfirmation.

Exporting Certificates

Select ‘Certificate Management ’ → ‘Export Certificate ’. It opens adirectory listing. Choose a name for the certificate and an extension from theselect box. The certificate can be stored in the following formats:PEM, DER, orPKCS12.

A certificate can only be stored in PKCS12 format if a key exists. You will alsobe prompted for a password and will have to specify an export password, whichwill be required when importing the certificate.

4.3.13 Configuring a Time Server with xntpd (NTP Module)

The FAS module NTP is used to configure the xntp daemon on your firewallcomputer. xntpd is used to keep the time on your firewall syncronized with atime server. This very useful for keeping timestamps in syslog messages in syncwith the machine that keeps the logs of your firewall.

Enter up to three different time servers used to fetch the up-to-date time (Fig-ure4.38on the next page). Simply enter the names or IP addresses of the timeservers.

The NTP protocol is UDP based, so open the ports for NTP in your IP packetfilter configuration.

4.3.14 rinetd

The programrinetd is a generic proxy. It is software that listens for connectionson a specified interface, accepts data on this interface, and routes this data toanother computer via a second network interface. The routing is also port depen-dent.rinetd can only route TCP connections. It is TCP routing on the applicationlayer. rinetd can only route connections over one channel, so rinetd cannot beused as an FTP proxy, as FTP uses two channels.

Configurerinetd with the ‘rinetd Module ’ of the Firewall Administration Sys-tem (Figure4.39on page65). The generic proxyrinetd should be used only ifthere is no dedicated application-level gateway (for example,Squid for httpd)

63


Figure 4.38: Configuring Time Servers with the NTP Module

With rinetd, it is possible to route any TCP-based service through a firewall in aeasy and secure way, for example, POP3. All connections to rinetd are loggedwith syslogd . See also the man page forrinetd (man 8 rinetd ).

Configuring rinetd with FAS

With FAS, easily add, edit, and delete rinetd connections. For a connection, youneed the following data:

• The IP address and interface of the firewall on which rinetd is listening forconnections.

• The port number or service name (see/etc/services ) of the service thatshould be redirected by rinetd.

• IP address and port number of the host to reach.

It is absolutely necessary to add rules to the IP filter script enabling all the portsand network interfaces to redirect. This is easily accomplished in the FAS mod-ule ‘SuSEFirewall Module ’.

FAS provides a dialog for entering this data. Start the ‘rinetd ’ module of FAS.A list shows all existing rinetd connections (Figure4.39on the next page).

By double-clicking an existing connection, see the additional allow and denyrules.

To create a new connection with rinetd, click ‘Add’. The configuration windowof the module appears (Figure4.40on page66).

A new forwarding or redirection rule consists of the following parts: bind ad-dress, bind port, connect address, and connect port.

Bind address is the IP address on which rinetd listens for incoming TCP con-nections.

64


Figure 4.39: Rinetd module with rinetd connections

Bind port is the port number of the service that should be redirected.

Connect address is the IP address of a computer to which the connectionshould be redirected.

Connect port is the port number of the service the computer is offering.

Example

You want to connect from the internal network through the firewall to a POP3server at your ISP. The bind address is the internal interface of your firewall (e.g.,10.10.10.1 ).

The bind port is port 110 (POP3). The connect address is the POP3 server ofyour ISP, something like195.23.82.20 . The connect port is port 110 (POP3).So your settings should look like this:

bind address bind port connect address connect port10.10.10.1 110 195.23.82.20 110

Additional options

The allow and deny rules:

These attributes enable you to restrict source addresses of incoming TCP con-nections. It is possible to state single IP addresses or ranges of IP addresses.The allowed characters are digits, dot (‘.’ ), question mark (‘?’ ), and asterisk(‘*’ ). The wild card‘?’ matches a single character and the asterisk matchesany number of arbitrary characters.

Allow: If one or more allow attributes to a connection rule are set, all connec-tions not matching at least one of them are immediately rejected.

65


Figure 4.40: rinetd Configuration Window

Deny: Incoming TCP connections of a matching source address are rejectedimmediately.

To confirm your changes press ‘OK’.

To edit a TCP connection, select a rule from the list and click ‘Edit ’. You willsee the current settings in the dialog. Do the editing and confirm with ‘OK’. Todelete a TCP connection, select a rule from the entries and press the ‘Delete ’.

4.3.15 VPN Connections (IPSEC Module)

Introduction

The FAS ‘VPN Connection ’ Module is a front-end for configuring VP Net-works. A VPN can be seen as a tunnel betweeen to hosts. This tunnel runsthrough the “normal” Internet. The tunnel itself knows nothing about the databeing transferred through it.

On theSuSE Linux Firewall on CD , VP Networks are implemented with IPsec.IPsec is a family of protocols that enables connections between computers. Au-thentication is done via certificates or pre-shared keys. All data transferredthrough an IPsec tunnel is encrypted automatically. The certificates used forauthentication and encryption are created or imported with the FAS ‘KeyringModule ’.

To use IPsec with theSuSE Linux Firewall on CD , the IP packet filter mustbe modified. If you have created the packet filter with the FAS module ‘SuSEFirewall ’, every necessary modification is done automatically.

66


If you are using a self-made ipchains script, imported viaipchains-save andthe FAS module ‘ipchains ’, complete the following:

Create a new chain namedipsec .earth: # ipchains -N ipsecearth: # icphains -A input -j ipsec

With this rule, all incoming packets are sent through this filter.

This should be near the beginning of the all the rules, maybe directly after an-tispoofing, so any incoming IP packet runs through the ipsec chain before otheripchains rules can affect its fate. If the packet was not destined for the VPN con-nection, it will return to the normal ipchains filter rules. This additional ipchainschain is necessary because the ports for IPsec must be released and masqueradingmust be turned off for IP packets destined to the VPN.

The script/etc/ipsec.d/updown is used to configure the filtering rules inthe chainipsec This script is run when an IPsec connection is established orstopped.

Save the filter rules as usual withipchains-save . The additional filter chain isnecessary so that, during the start-up of IPsec, the needed ports will be enabledand the masquerading for the packets sent through the tunnel disabled.

The IP packets sent through the VPN tunnel will only be filtered in the ipchainschainipsec . To restrict the access of VPN partners to some services, it is nec-essary to add more rules in the chainipsec . These rules can be set up in theFAS dialog ‘IP filter rules for VPN tunnel ’. Note that these rules willapply to all VPN connections of this firewall configuration.

Configuring an IPsec Tunnel with FAS

In the first dialog of the FAS module ‘Select certificate ’, choose an X.509certificate for authentication (Figure4.41 on the next page). To create certifi-cates, see Section4.3.12on page59.

This certificate will be used by your firewall server to authenticate itself to otherhosts. It can be seen as a kind of identity card for your computer.

If you do not want to use strong authentication, do not select a certificate. Usingstrong authentication is recommended, however. This means you authenticatenot only with a passphrase, but additionally with key.

In the second dialog, configure the VPN connections (Figure4.42on page69).In a table field, all previous configured VPNs are shown.

To configure a new VPN, use the ‘Add’ button.

A new dialog appears with to two tabs: ‘General Settings ’ and ‘VPN Con-nection ’ (see Figure4.43on page69).

General Settings

Enter a name for the new VPN connection. This helps in identifying a connectionif you configure more than one tunnel. For example, you have more than two

67


Figure 4.41: Choose Local Certificate

locations to which to connect with VPNs. The name of a connection may containonly alphanumerical characters, hyphens, and underscores.

There are two modes with which theSuSE Linux Firewall on CD can connect ina VPN. In client mode, the firewall opens a connection to a VPN server at boottime. In server mode, the firewall waits for clients to connect. For example, asubsidiary that wants to connect to the main location will choose the client mode.The VPN gateway in the main location chooses the server mode.

Furthermore, select the mechanism for authentication for a given connection.Choose between X.509 certificates (recommended) and pre-shared keys.

The X.509 certificates can be seen as an identity card created for your computer.With this certificate, your computer authenticates itself to all VPN gateways.This is why you can choose only one certificate for a given computer.

The shared key is a freely selected string. No quotation marks ("") are allowedin this string. Every connection can have its own pre-shared key, but the keys oneach side of a tunnel must be identical.

The transmission of a shared key has to be done in a secure way, because anyonewho has this key can establish a connection to the corresponding VPN gateway.Authentication via X.509 certificates is the better solution.

For completion of the configuration, choose the tab ‘VPN Connection ’ (Fig-ure4.44on page70).

Local Configuration

In the field‘IP Address ’, enter the IP address of your firewall host to whichVPN connections should be established. The field ‘Subnet ’ specifies the net-work that should be reachable through the VPN Gateway. The subnet in localconfiguration must be from another IP range than the subnet on the remote side.

68


Figure 4.42: Installed VPN Connections

Figure 4.43: VPN Connection Dialog — General Settings

On the remote end of the VPN tunnel, a route to this subnet will be set automat-ically.

‘Gateway ’ must be completed if the other VPN gateway is only reachable viathis gateway.

Remote Configuration

Choose between ‘Road Warrior ’ and ‘Fixed IP Address ’. The RoadWar-rior setup enables a client to connect to the VPN server from any IP address (e.g.,dial-up connection to any ISP). The field ‘Subnet ’ is deactivated in this case.

With the fixed IP setup, clients can only connect if they have a fixed IP address.The field ‘Subnet ’ contains the network that should be accessible through thisclient. This network must be different than the network on the local site. Whileestablishing the connection, a route is automatically set to this subnet. If theVPN gateway can only be reached via a router, enter the IP address of this router

69


Figure 4.44: VPN Connection Dialog — Local and Remote Configuration

in ‘Gateway ’.

Complete the configuration by pressing ‘OK’. To change an already configuredVPN connection, select the connection and press ‘Edit ’. To delete a VPN con-nection from your configuration, select the VPN connection and press ‘Delete ’.

To use X.509 certificates to authenticate, you must have generated or importedthem before with the ‘Keyring Module ’. Choose one from the selection listavailable with the ‘Select ’ button (Figure4.45).

Figure 4.45: Select Remote Certificate

ipchains Set of Rules for VPN Tunnel

In this dialog, the services accessible through the VPN tunnel are enabled. SeeFigure4.46on the next page).

Local Site to Remote Site: services are enabled that are accessible on the re-mote site through the VPN tunnel. Select the TCP and UDP services or portsto enable in the list

70


Remote Site to Local Site: services accessible from a remote site on the localsite. Select the services from the list

Figure 4.46: Filter Rule Set for VPN Tunnels

If a needed service is not in the list, add the required ports or services to therespective configuration files:

/etc/fas/IpsecTCPServices.conf/etc/fas/IpsecUDPServices.conf

The network traffic through the tunnel can also be completely enabled. Activatethe checkboxes ‘Allow all ’.

These rules only apply to VPN connections. All other restrictions remain active.

Distribution of Certificates

The distribution of the certificates to the clients is achieved in the following way.

Select a VPN from the list. Right-click ‘Export Connection ’. Choose, fromthe shown directory listing, where to save the certificate. The data will be writtento this location. (e.g., a floppy) To export a certificate for a Windows client, usea DOS formatted floppy disk.

The certificates can be exported in the following formats:

• The CA in PEM format ascacert.pem

• The certificate of this configuration in PEM format assrvCert.pem

• Certificate and key for a client computer in PKCS12 format asremCert.p12 ; the certificate and the key must have been saved to the keyring

Testing of the VPN tunnel

• Connect the clients to the server

• Linux to Linux connection

71


• Linux connected to other VPN Gateways

• Set up Windows clients

4.3.16 Saving the Configuration

A configuration can be saved by clicking ‘Save configuration ’ in the ‘Con-figuration ’ menu. Once you have exited the configuration and modified thesettings, you will be asked if you want to save the changes. The configuration isarchived withtar , compressed withgzip , and saved to the hard disk in the file

/var/lib/fas/<username>/configs/<configurationname>.tar.gz .

No normal user on the Adminhost can read this configuration. Only‘root’ hasthe necessary permissions.

To save the configuration to a floppy disk, insert it into the drive, select the con-figuration to save to disk, then click ‘Configuration ’ → ‘write to floppy ’.Now, the disk will be written. The configuration must have previously been rec-ognized as “properly configured”, in which case a green check mark will appearin the left portion of the dialog.

4.4 Editing an Existing Firewall Configuration

To edit an existing firewall configuration, start the Firewall Administration Sys-tem FAS. Log in as the user used to create the configuration via the menu ‘FAS’→ ‘Login ’ then enter your password. Now, obtain a list of the configurationspreviously created by this user.

Select the configuration to edit from the list. Double-clicking the configurationname in the list located in the left window panel allows editing one of the servicesin its respective module.

4.5 Testing the Configuration

The configuration created using the administration application must be testedbefore it can be put to productive use. To do this, the firewall is started offline(connected neither to the Internet or your intranet). To carry out the testing, thefirewall is connected directly to the Adminhost (crossover cable).

Testing for the packet filter can easily be done with a port scanner. To this end,the programnmap is installed on the Adminhost. If you carry out a port scanfrom the Adminhost, you must disable the packet filter of the Adminhost. Login as user‘root’ and enter the following command in a console:root@adminhost: # SuSEfirewall stop

In this way, ensure that all returning IP packets can be received by the Admin-host. Do not forget to reactivate the packet filter after completing the test withroot@adminhost: # SuSEfirewall start

72

4.6 Documenting the Configuration, theTests, and the Results

Following the port scan, the scanning results and the log file should be docu-mented on the firewall and retained.

Use the following tests to make sure services are running properly:

• Test name server withnslookup plus name of the firewall. Check the logfile, for example, withgrep named /var/log/messages . There shouldnot be any messages containing “error”.

• Mail relay: by sending an e-mail and checking the log files/var/log/mailand /var/log/messages . Search the log files for “postfix”, for example,usinggrep postfix /var/log/mail .

• FTP proxy: viatelnet to port 21 (FTP) of your firewall.

• Test the HTTP proxy by attempting to access the Internet from a client.

• TestSSH by logging on to the firewall from a client.

Always verify all processes by referring to the log files.

4.6 Documenting the Configuration, the Tests,and the Results

It is essential to document the configuration, any tests performed, and their re-sults. Record what is permitted or prohibited by the configuration and how thisis guaranteed. By means of such documentation, detect configuration errors andremedy them. This documentation is also necessary for auditing the firewall.

4.7 Monitoring the Firewall

As already mentioned several times, a firewall’s functionality is quite limited ifnot accompanied by constant monitoring. Some tools for monitoring the firewallare located on the Adminhost. The most important sources of information arethe log files, which are saved either to the log host or the hard disk, dependingon the configuration.

The following programs are available as tools for analyzing log files.

• xlogmaster

• logsurfer

• sylog-ng

The following network or packet sniffers can be used to monitor your firewall:

• ntop

• tcpdump

• ethereal

73


With the following port scanners, examine the firewall on open ports and monitorthe packet filter configuration:

• nmap

• nessus

In addition, you can use your own shell or perl scripts.

4.8 Configuration of syslog-ng

To configure the login daemonsyslog-ng on the log host, log in to a consoleas user‘root’ or enter the commandsu - root in an xterm. If the SuSELinux Adminhost for Firewall is not your log host, copy the program/opt/fas/sbin/fas_syslogng_config.pl to your log host.

Start the program as‘root’ with the following command:root@loghost: # /opt/fas/sbin/fas_syslogng_config.pl

Specify the host name of your firewall. Define whethersyslog-ng should bestarted when the system is booted. The default setting is "yes".

The host name of the firewall must be able to be resolved to an IP address. Youcan determine if this is the case by referring to an entry in the/etc/hosts fileon your log host. For this, refer to the File4.8.1.

# Firewall logging entry# IP address of firewall hostname.mydomain.com hostname# e.g.,192.168.0.1 stargate.mydomain.com stargate

File 4.8.1: Sample Entry in the /etc/hosts File

74

5 SuSE Linux Live CD for Firewall


5.1 Introduction

The “Live CD” for SuSE Linux Firewall on CD is the “executive branch” of thefirewall. The Live CD is a minimal SuSE Linux equipped to meet security needs.This applies to the available applications as well as to the kernel itself. TheSuSELinux Firewall on CD is, in addition, an “Application Level Gateway”, meaningthat, for security reasons, IP packet routing should not set be up. Forwardingrequests to services is managed by applications (proxies).

Proxies and non-forwarding IP packets are not enough to prevent undesired In-ternet IP packets from reaching the intranet or vise versa. This firewall func-tionality is adopted by the kernel packet filter configured byipchains(8). This iswhere the idea of the Live CD comes into play. The operating system and all theapplications are located on a CD — on a read-only file system. A RAM disk,where the Live CD is mounted, is generated when booting. The standard systemcan simply be restored by rebooting the machine. Updating the “SuSE LinuxFirewall on CD” is likewise very simple because of this: just swap the Live CDfor the new Live CD and restart your firewall host.

Configuring the system and the services is done by disk, where all the necessaryconfiguration files are saved. This disk is mounted read-only when booting. Justto be on the safe side, the disk should also be write-protected. The data on theconfiguration disk will be copied to the RAM disk and the disk itself removedfrom the file system.

Hardware requirements:

• An ix86 computer, where x is 5 or higher. At least aPentium II is recom-mended.

• At least128 MBRAM

• a 3.5-inch floppy disk drive

• a bootable CD-ROM drive

• at least two network interfaces

This chapter does not provide any instructions for configuring firewall services,but, rather, technical documentation for the well-versed administrator willing tograpple with the internal aspects of the system. We will also describe detailsrelating to the configuration files of the services provided on the Live CD. Forconfiguration purposes, the Firewall Administration System (FAS) on theSuSELinux Adminhost for Firewall should be used.

75


5.2 Description of the SuSE Linux Live CD forFirewall

TheSuSE Linux Live CD for Firewall is a Live File System CD from which allthe applications will run directly. Theoretically, the firewall host could be drivenwithout a hard disk. However, a hard disk for the cache and spool directoriesis required by proxy services such asSquid or postfix. A hard disk is likewiserequired if you want to save the syslogd log messages locally. To set up thefirewall system, insert the CD and the configuration disk created by theSuSELinux Adminhost for Firewall and boot the host.

5.3 Services on the Firewall

“Application level gateways”, or proxies, are located on the “SuSE Linux LiveCD for Firewall” for the most common and essential Internet protocols:

DNS (Domain Name System): IP addresses can be converted into “Fully Qual-ified Domain Names” and vice versa withbind8

SMTP Postfix manages the transportation of e-mail messages

HTTP/HTTPS — the WWW Protocol: Squid, httpf, transproxy, tinyproxy

FTP ftp-proxy-suite is used for transmitting files from one host to another.

SSH “Remote logins” with encrypted transfers take place viaopenssh, the au-thentication program for RSA key pairs.

rinetd Generic TCP Proxyrinetd

ntp Time serverxntpd

ipsec FreeS/WAN

All these applications involve Open Source or free software. All these processesrun on the “SuSE Linux Live CD for Firewall” in chroot environments.

To raise the security level of the system even higher, the following programs andkernel modules are used for the Linux Kernel (2.2.19) implemented by the LiveCD: secumod , compartment , OpenWall-Patches .

5.3.1 ipchains

The packet filter of the Linux kernel 2.2.x is configured using theipchains appli-cation. ipchains allows for extremely flexible configuration of the kernel packetfilter. To do this, refer to the man page foripchains (man 8 ipchains ).

Normally, ipchains recognizes three packet filter chains: input-chain, forward-chain, and output-chain. These three filters determine the fate of an IP packetarriving at an interface. It is advisable to determine a policy for these chains that

76


denies all packets. This will then be the default behavior of the chain: everythingnot expressly permitted will be denied.

IP packets cycle through the chains and will be treated in respect to their addressof origin, destination, and port. The packets will be forwarded, discarded, or re-jected. There are basically two options provided by theSuSE Linux Live CD forFirewall for configuringipchains filter rules. The first and rather convenient op-tion is to use the SuSE Firewall Script. The SuSE Firewall Script is configureddepending on the configured and activated services. With its Firewall Admin-istration System (FAS), theSuSE Linux Adminhost for Firewall provides easyaccess to the SuSE Firewall Script. The second available option is configuringyour own packet filter withipchains. First, we give an overview of the SuSEFirewall Script and, subsequently, instructions for setting up your own packetfilter.

The SuSE Firewall Script and configuration

Below is a technical description of how filter rules are generated as well as somebackground on the new SuSE Firewall Script design. However, this documenta-tion doesnotoffer instructions on how to configure the firewall — the configura-tion file /etc/rc.config.d/firewall.rc.config contains sufficient com-ments to simplify the process. Furthermore, find some sample configurations intheEXAMPLESfile in the/usr/share/doc/packages/SuSEfirewall direc-tory. Recently, a FAQ has been added to the same directory. This documentationrefers to “firewall” throughout, although this script is technically not a firewallitself. This package is a “packet filter” that accepts or denies data on the TCP/IPlevel. In other words: if you are operating a web server and want to allow accessto it from outside and have access to the Internet from inside, this script will notprovide any protection if the web server has a security problem. However, it willenable you to protect services that should not be accessed, keep potential hackersin the dark about your configuration and recognize intrusions by detecting filterviolations.

The design of the SuSE Firewall Script satisfies the following demands:

• Above all, securityThose installing and configuring this package expect that the script will doeverything possible to secure the system. A user must, however, take intoaccount that some things are more difficult or perhaps, in rare cases, not atall configurable in this package. It will also consume some time to set up thefirewall properly.

• No compromises to the system in case of errorsAn error in the script or in the configuration file should not lead to open filterrules. However, this goal is, in certain areas, difficult to realize. In any case,SuSE has made a strong effort to achieve this goal.

• Simple configurationSimple questions are asked, but only as many as are absolutely necessary.This is, of course, the greatest challenge, but you will still need to have prior

77


TCP/IP knowledge, administrator skills, a knack for system security, andpatience.

• Automated configurationTo simplify the configuration and for better support of dynamic systems, theSuSE Team has tried to determine as much information as possible at thevery moment the firewall script starts.

• Support of dynamic IP addresses + networksNot only a dynamic IP address, but also several network cards (an infiniteamount) for the Internet as well as for the internal network are supported.

The following section contains frequent references to filter rules and networks.Filter rules, which apply to internal interfaces or networks, are only processedif they are configured and available immediately when the firewall script starts.If they were only accessible after starting the script, for instance, if the interfacewere "down", network communication would no longer be possible.

The SuSE Firewall Script procedure located in/sbin can be outlined as follows:

a) First, the configuration file,/etc/rc.config.d/firewall.rc.config ,is read. Before anything can happen, the user must configure/etc/rc.firewall . These files will be created automatically if you are using FAS.

b) A search is then conducted for auxiliary programs such assed, awk, grep,ifconfig, netstat, and ipchains. If any one of these programs cannot be de-tected, an error message will abort the script. Next, the kernel version isverified to determine whetheripchains is supported. The script will be ter-minated if a 2.0 kernel is identified or a warning issued if the kernel versioncannot be identified at all.

c) Now, the interpretation of the configuration file follows, along with the evalu-ation of the important data at hand. In this way, data for all the network cardsconfigured in the script, such as IP address and netmask, will be scanned. Ifan interface is not "up" (e. g., an ISDN or a PPP interface), filter rules willstill be generated later in the script procedure, but only a few rudimentary se-curity mechanisms will be in place. After setting up a connection with ISDN,for example, the SuSE Firewall Script should be started again.

d) Now you can begin. First, the rules are reset and the default for incomingpackets as well as for packets for routing the firewall set to "discard". If, forsome reason, a packet in the script does not have any rules, this packet willalways be discarded. Packets wanting to exit the firewall will be set to thetarget value "allow".

e) If the firewall is set to "route", this will activate routing.

f) The /proc system allows easy configuration the kernel while the system isrunning. The script makes use of this for the purpose of activating some secu-rity options. For many of these options, the optionFW_KERNEL_SECURITYin the configuration file must first be set to "yes", because it could otherwisehave rather complex consequences.

78


g) Then, most importantly, all traffic from the "localhost" via the loopback in-terface is released.

h) Now, the script will handle the rules pertaining to "IP spoofing" and "bypassprevention". These rules ensure that external and internal attacks that pretendto be from another network segement are recognized and refused. At thesame time, attempts to directly break into the network will be impeded.

i) The redirecting rules that follow can be used to reroute attacks on the internalnetwork or local ports to a special firewall port.

j) If connected to an internal network, the firewall sysadmin specifies in theconfiguration file whether the firewall should be protected against internal at-tacks. If not, from this point on, any traffic on the internal network will be re-leased to the firewall. The option for this isFW_PROTECT_FROM_INTERNAL.

Then rules for ICMP, TCP, and UDP are generated.

k) ICMP rules are generated in two phases. First, special ICMP packages areallowed or denied according to the configuration: packages such as "ping" tothe firewall, "source quench" messages of the next front-end router, and re-sponse packages for similar programs such astraceroute. The second phaseis comprised of general configurations prohibiting dangerous ICMP pack-ages and allowing the essential ones. The internal network can always accessthe firewall with "ping".

l) For TCP rules, the configured services are first released to the outside, then totrustworthy networks, and, finally, to those services designated for the inter-nal network. Subsequently, port 113 will be configured to send a connectionreset to prevent unnecessary wait times (e. g., when sending e-mails). Now,an automatic process comes into play:If FW_AUTOPROTECT_GLOBAL_SERVICEShas been set to "yes", these ser-vices will be protected by filter rules that donot listen to any special inter-faces (to0.0.0.0 or INADDR_ANY). In this way, all high ports for incomingconnections can be released, if necessary, but with the assurance that yourdatabases and other things that may be running (on port4545 , for instance)will still be protected. In conclusion, rules will be generated as to whetherand how unprivileged ports (between1024 and65535 ) can be accessed: notat all, only name servers as defined in/etc/resolv.conf , only connec-tions originating from a given port (not recommended since this safeguard iseasy to circumvent), or all connections. Internal systems canalwaysaccessunprivileged ports — with the exception of services, which are all protectedby AUTOPROTECT.

m) The same is done for UDP, except that a connection reset for port113 is notrequired.

n) Next, the script handles the routing rules for defining which systems in theinternal network can be accessed from outside. These routing rules shouldnot be used for obvious reasons, as these systems would be unprotected.

o) Now the masquerading rules are configured.

79


p) The configuration of additional log mechanisms for special packets is veryimportant, for example, forbidden TCP packets attempting to establish a con-nection. IfLOG_*_ALL is set,everypacket really will be logged, which willgenerate quite a few log entries, so should only be used for troubleshooting.

q) Last but not least, a few optimization rules are set for SSH, FTP, WWW,Syslog, and SNMP to make the transfer over the network faster and moresecure for these services.

This completes the script. If there is an error, the return value is 1. Otherwise,the return value is 0.

Now it is necessary to initialize the firewall during the booting process. The nameof the actual rc script is/sbin/init.d/firewall . It is called up in runlevel2 with S04firewall_init and S99firewall_setup . S04 only generatesrudimentary rules and does not return any errors. This is only done when theS99 script is run, once all services and interfaces have been properly configured.K51firewall removes all filter rules at ("shutdown") and allows any packet, whiledisabling the routing.

The firewall should always be started dynamically as

/sbin/init.d/rc2.d/S99firewall_setup start

using dial-up scripts, so filter rules will only be generated if configured to do so.

TRACEROUTE

To activatetraceroute and other similar applications, the following must be con-figured for them to function properly.FW_ALLOW_FW_TRACEROUTE=yes (at the very end of the expert-config)FW_ALLOW_FW_PING=yesFW_ALLOW_INCOMING_HIGHPORTS_UDP=yes

If you only make these settings and use the SuSE Firewall, you system is, how-ever, not yet really secure. To increase the security level of a firewall server, youshould:

• Minimize any services to insecure networks (such as the Internet), only useapplications considered safe (e. g.,postfix, ssh), and configure these care-fully. In addition, you will need to ascertain that these applications are not,in fact, exhibiting any security gaps. If at all possible, doNOT run any ser-vices as‘root’ and do not run any services in a "chroot" environment.

• Do not rely on any software you have not tested yourself first.

• Check your server’s integrity on a regular basis.

• If you want to use the firewall server as a masquerading or a routing server,which is not recommended, check to see if proxy services can be imple-mented instead, such asSquid for the WWW andsmtpd for e-mail. Also,beware of "chroot" here as well. Do not let any processes run as‘root’ .Disable this machine’s routing.

80


Below, find explanations of the SuSE Firewall Script configuration file/etc/rc.config.d/firewall.rc.config .

As already mentioned, you will not have to set up this file by hand. Use theFirewall Administration System on the Adminhost. However, if you want toedit this file for your own purposes, read the Firewall Script documentation andreview your script thoroughly before running it. No guarantee or support can beoffered for self-made configurations.

� �

� NoteConfiguring these settings and using the SuSE Firewall Script will not, onits own, make your system secure. There is NOTHING that can simply beinstalled all at once and guarantee full protection against security leaks.

For a “secure” system, also keep in mind the following:

Back up any services provided for unreliable networks (such as the Internet) withsoftware developed to accommodate security requirements (e. g.postfix andssh).Do not implement any software originating from unreliable sources. Regularlycheck the security of your server.

Configuration of the SuSE Firewall Script

To start the firewall script, the variableSTART_FWin the /etc/rc.config filemust be set to "yes". If theSuSE Linux Adminhost for Firewall is being imple-mented, this will take place automatically.

If this server is a firewall functioning as a proxy (no routing between networks) orif you are an end-user connected simultaneously to the Internet and the intranet,configure items 2, 3, 9, and, possibly, 7, 10, 11, 12, 14, and 18.

If the machine is functioning as a firewall and provides routing and masqueradingfunctionality, change items 2, 3, 5, 6, 9, and, possibly, 7, 10, 11, 12, 15, and 18.

If you know exactly what you want to do, you can reconfigure items 8, 16, 17,18, and the expert options 20, 21, and 22 in the outermost margin of the file.However, SuSE advises against this.

To implement “diald” or “ISDN dial-on-demand”, edit item 18.

To use applications such astraceroute together with your firewall, set theoptions 11 (only UDP), 19, and 20 to “yes”.

To start all the packet filter rules yourself, configure a static IP and netmask forthese if they do not already exist. Note examples in 2, 3, and 4.

If you use service names, they will be located in/etc/services . Note thatthere is no service “DNS”. The correct name is “domain”. For e-mail, use“smtp”.

Every time routing takes place between interfaces, with the exception of mas-querading,FW_ROUTEwill have to be set toyes . Otherwise, use the variablesFW_FORWARD_TCPandFW_FORWARD_UDP.

81


1. Should the firewall script be started at the system boot?

For this, the variableSTART_FWin /etc/rc.config must be set to "yes".

2. Which network interfaces are connected to the Internet or to unreliable net-works?

Specify all unreliable networks here. Enter an unlimited number of inter-faces, each separated by a blank space, for example, "eth0" or "ippp0 ippp1".

FW_DEV_WORLD=""

Specify a static IP address and a network mask address, thereby forcing apacket filter rule to be loaded for an interface not yet available.

FW_DEV_WORLD_[device]="IP_ADDRESS NETMASK"

DefineFW_DEV_WORLDfirst. The entry will then appear as follows:

FW_DEV_WORLD_ippp0="10.0.0.1 255.255.255.0"

3. Which network interfaces are associated with the internal network? Specifyall trustworthy network devices here. If you are not connected to a trust-worthy network (e. g., if you only have a dial-up connection), leave the listblank. Enter an unlimited number of network devices, each separated by ablank space, for example, "eth0" or "eth0 eth1 ippp0".

FW_DEV_INT=""

Specify a static IP address and a network mask address, thereby forcing apacket filter rule to start for an interface not yet available:

FW_DEV_INT_[device]="IP_ADDRESS NETMASK"

DefineFW_DEV_INTfirst. See the following example for the internal inter-face "eth0":

FW_DEV_INT_eth0="192.168.1.1 255.255.255.0"

4. Which interface is linked to the DMZ?

Specify all network devices linked to the DMZ. Caution: Configure thevariablesFW_FORWARD_TCPandFW_FORWARD_UDPthat specify the servicesprovided for the Internet and set the variableFW_ROUTEto "yes". You havethe choice of: "tr0", "eth0 eth1", or "".

FW_DEV_DMZ=""

Specify a static IP address and a network mask address, thereby forcing apacket filter rule to start for an interface not yet available:

FW_DEV_DMZ_[device]="IP_ADDRESS NETMASK"

DefineFW_DEV_DMZfirst. See the following example for the DMZ interface"eth1":

FW_DEV_DMZ_eth1="192.168.1.1 255.255.255.0"

5. Should “routing” be activated between the Internet, the DMZ, and the inter-nal network? For this, you needFW_DEV_INTor FW_DEV_DMZ.

Only set the variable to "yes" if you either want to mask internal machines orallow access to the DMZ. This option overwrites the variableIP_FORWARDin /etc/rc.config .

82


If you set this option, nothing will happen yet. Either activate the masquerad-ing with the variableFW_MASQUERADEor configureFW_FORWARD_TCPorFW_FORWARD_UDPto define what to route. Specify "yes" or "no" here, thedefault being "no".

FW_ROUTE="no"

6. Do you want to mask outgoing internal networks? To do this, useFW_DEV_INTandFW_ROUTE.

“Masquerading” means that all your internal machines that use Internet ser-vices will appear as if they were originating from the firewall. It is moresecure to communicate over proxies with the Internet than to implement mas-querading.

Options: "yes" or "no", default: "no"

FW_MASQUERADE="no"

Which internal hosts or networks should have access to the Internet? Onlythese networks can go on the Internet and will be masked. Leave the listblank or specify any number of networks and hosts, each separated by ablank space. A protocol type and service can be added to each network orhost, separated by a comma.

FW_MASQ_NETS=""

In addition, specify the interface where the masking takes place, for example,"ippp0" or "$FW_DEV_WORLD"FW_MASQ_DEV="$FW_DEV_WORLD"

7. Do you want to protect the firewall from internal networks? This can beaccomplished with the variableFW_DEV_INT. If this variable is set to "yes",computers on the intranet can only use the enabled services.

Options: "yes" or "no", basic setting: "yes"

FW_PROTECT_FROM_INTERNAL="yes"

8. Do you want to protect all globally running services?

If you specify "yes" here, all network access attempts to TCP and UDP notassociated with a particular IP address or not otherwise explicitly permittedwill be prohibited on this machine. SeeFW_*SERVICES_*. "0.0.0.0:23" willbe protected, for example, but "10.0.0.1:53" will not. Options: "yes" or "no",default is "yes".

FW_AUTOPROTECT_GLOBAL_SERVICES="yes"

9. Which services on theFirewall host are open to the Internet or any other un-reliable network, to the DMZ, or to the internal network? (See items 13 and14 if you want to route your network traffic over the firewall) Specify all portnumbers or port names, each separated by a blank space. TCP-based ser-vices (e. g., SMTP, WWW) must be set inFW_SERVICES_*_TCPand UDPservices (syslog) inFW_SERVICES_*_UDP. For IP protocols (such as GREfor PPTP or OSPF for routing),FW_SERVICES_*_IP must be specified bythe protocol’s name or number (see also/etc/protocols ).

83


Options: Specify port numbers, port names (see/etc/services ), portzones (e. g. 1024:2000), or services (TCP) that should be visible from theoutside, normally “smtp domain”. Separate the items in the list with blankspaces. Give a blank list to prevent any access from an untrustworthy net-work.

FW_SERVICES_EXTERNAL_TCP=""

Services (UDP) visible from the outside, normally “domain”:

FW_SERVICES_EXTERNAL_UDP=""

Services (all other) visible for the DMZ, for example, VPN or routing, ter-minating at the firewall:

FW_SERVICES_EXTERNAL_IP=""

Services (TCP) visible for the DMZ, normally “smtp domain”:

FW_SERVICES_DMZ_TCP=""

Services (UDP) visible for the DMZ, normally “domain syslog”:

FW_SERVICES_DMZ_UDP=""


FW_SERVICES_DMZ_IP=""

Services (TCP) visible for the internal network, normally “ssh smtp domain”:

FW_SERVICES_INTERNAL_TCP=""

Services (UDP) visible for the internal network, normally “domain syslog”:

FW_SERVICES_INTERNAL_UDP=""


FW_SERVICES_INTERNAL_IP=""

10. Which services should be reachable from trustworthy Internet networks?

Specify the trustworthy Internet networks and the TCP or UDP services theycan use.

Options: blank lists or any IP address and networks, each separated by ablank space.

FW_TRUSTED_NETS=""

Specify a blank list next toFW_SERVICES_TRUSTED_*, the port numbersand the known port names (see/etc/services ), or the port zones, eachseparated by a blank space, for example, "25", "ssh", "1:65535", "1 3:5"

Services (TCP) to make available to trustworthy networks and hosts, nor-mally “ssh”:

FW_SERVICES_TRUSTED_TCP=""

Services (UDP) to make available to trustworthy networks and hosts, nor-mally “syslog time ntp”:

FW_SERVICES_TRUSTED_UDP=""

Services (all other) visible to trustworthy hosts, for example, VPN or routing,terminating at the firewall:

84


FW_SERVICES_TRUSTED_IP=""

Sometimes, some trustworthy hosts should have access to certain servicesand other trustworthy hosts to other services. Here, set up this option accord-ing to the pattern: "trusted_net,protocol,port", for example, "10.0.1.0/24,tcp,8010.0.1.6,tcp,21":FW_SERVICES_TRUSTED_ACL=""

11. Is access to high, unprivileged ports (above 1023) allowed?Allow ("yes") or deny ("no") all access to the high ports, allow any accessoriginating from a given port (specification of port number or service name,which can, however, be easily circumvented), or allow only authorized nameservers (DNS) access.To enable active FTP, set the TCP variable to "ftp-data". For passive FTP,this is not necessary. You cannot use any rpc requests. To allow this, set theport zone "600:1023" inFW_SERVICES_EXTERNAL_UDP.Options: "yes", "no", "DNS", port number, or port name. Default is "no".The following variable is for incoming TCP connections to ports 1024 andhigher, used for active FTP by default. Set this to "yes" to use active FTP.FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes"

The following variable is for incoming UDP connections to ports 1024 andhigher, normally: "DNS" or "domain ntp":FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes"

12. Do you have one or more of the following services running? These require abit of caution. Otherwise, they will not function. For services to provide, setthe variable to "yes" and the others to "no". Default values are "no".FW_SERVICE_DNS="no"If "yes", port (or domain) 53 must haveFW_SERVICES_*_TCP. The variableFW_ALLOW_INCOMING_HIGHPORTS_UDPmust be set to "yes".FW_SERVICE_DHCLIENT="no"If you are using dhclient to obtain an IP address,FW_SERVICE_DHCPDmustbe set to "yes".FW_SERVICE_DHCPD="no"If this host is a DHCP server, setFW_SERVICE_DHCPDto "yes".FW_SERVICE_SAMBA="no"To implement Samba as a client or server, setFW_SERVICE_SAMBAto "yes".For a Samba server,FW_SERVICES_{WORLD,DMZ,INT}_TCP="139" stillmust be set. Overall, it is a bad idea to use Samba on a firewall host.

13. Which services accessible from the Internet may access the DMZ or internalnetwork?With this option, allow access for your mail server, for instance. This hostmust possess a valid IP address. If an open connection should be establishedto your network, just use this option to access your DMZ. The followingvalues are possible: leave the variable empty (the best choice) or use thefollowing syntax for the forwarding rules. Separate rules with blank spaces.A forwarding rule consists of:

85


a) Source IP or network

b) Destination IP (dmz or internal)

c) Destination port (or IP protocol), separated by a comma

# Forward TCP connections# Beware of using this!FW_FORWARD_TCP=""# Forward UDP connections# Beware of using this!FW_FORWARD_UDP=""# Forward other IP protocol connections (for VPN setups)# Beware of using this!FW_FORWARD_IP=""

14. Which services can be used on masked hosts (in your DMZ or internal net-work)?

REQUIRES: FW_ROUTE, FW_MASQUERADE

With these variables, allow access to your mail server, for instance. The hostmust be located in a masked network segment and cannot have an official IPaddress.

If FW_DEV_MASQis set to your external interface, likewise set the variablesFW_FORWARD_*from your internal network to the DMZ for these services.

� �

� CautionFor security reasons, you should not use this feature, as it opens a secu-rity gap in your internal network. If your web server were compromised,your entire network would become vulnerable to attack.

Options: Leave the entry blank (best choice) or use the following syntax forthe forwarding masquerade rules. Separate the rules with blank spaces.


b) Destination IP (dmz or internal)

c) Destination port, separated by commas,for example, "4.4.4.4/12,20.20.20.20,22 12.12.12.12/12,20.20.20.20,22"

# Forward TCP connections to masqueraded host# Beware of using this!FW_FORWARD_MASQ_TCP=""# Forward UDP connections to masqueraded host# Beware of using this!FW_FORWARD_MASQ_UDP=""# it is not possible to masquerade other IP protocols,# hence no _IP variable

86


15. Which services should be rerouted to a local port on the firewall host?

This can be used to relay all your internal users over your HTTP proxy orto forward all incoming requests transparently to port 80 on a secure webserver.

Option: Leave the list blank or use the following syntax for redirecting rules:


b) Destination IP or network

c) original specification port

d) local port to which the network traffic is rerouted. For example,"10.0.0.0/8,0/0,80,3128 0/0,172.20.1.1,80,8080"

Redirect TCP connectionsFW_REDIRECT_TCP=""

Redirect UDP connectionsFW_REDIRECT_UDP=""

16. Which log level should be forced?

Decide if accepted or denied packets are logged. Also specify the log level:"critical" or all. Note that*_ALL should only be activated for debuggingpurposes.

Options for the variable: "yes" or "no",FW_LOG_*_CRITdefault is "yes".

# Log critical denied network packetsFW_LOG_DENY_CRIT="yes"# Log all denied packetsFW_LOG_DENY_ALL="no"# Log critical accepted packetsFW_LOG_ACCEPT_CRIT="yes"# Log all accepted packetsFW_LOG_ACCEPT_ALL="no"

17. Do you want additional kernel TCP/IP security features? If you set this vari-able to "yes", the following kernel options will be set:

icmp_ignore_bogus_error_responses,icmp_echoreply_rate,icmp_destunreach_rate,icmp_paramprob_rate,icmp_timeexeed_rate,ip_local_port_range,log_martians,mc_forwarding,rp_filter,routing flush

Options: "yes" or "no", default is "yes":FW_KERNEL_SECURITY="yes"

87


18. Should the routing remain active if the packet filter rules are reset? For this,you will needFW_ROUTE.If you use “diald” or “dial-on-demand” via ISDN and IP packets are sent overthe Internet, activate this function. Then, masquerading and routing will notbe deactivated when the script terminates. You might need this functionalityif you have DMZ. Note, however, that this isnot secure! If you unload the IPfilter rules, but still have the connection, your network could be vulnerableto attacks.Options: "yes" or "no", default setting: "no"FW_STOP_KEEP_ROUTING_STATE="no"

19. Should ICMP echo pings to the firewall host or to the DMZ be allowed? TheFW_ROUTEis required forFW_ALLOW_PING_DMZ

Option: "yes" or "no", default is "no"

# Allow ping to firewallFW_ALLOW_PING_FW="yes"# Allow ping to DMZ host.FW_ALLOW_PING_DMZ="yes"

Creating your own packet filter with ipchains

If you do not want to use the SuSE Firewall Script, you have the option of con-figuring your own packet filter withipchains. Adjust the filter rules to meet yourparticular need on a Linux host, such as theSuSE Linux Adminhost for Firewall ,and save this packet filter setup withipchains-save to a file.root@adminhost # ipchains-save > myfiltersetup 2>/dev/null

Using FAS, load this file along with your packet filter configuration to theSuSELinux Live CD for Firewall configuration. These filter rules will be saved tothe/etc/ipchainsrc file on the configuration disk and loaded by the/sbin/init.d/ipchains script when booting the firewall host.

5.3.2 DNS

The name serverBIND Version 8 is used to enable name resolution over thefirewall. To learn more about DNS, read chapterA on page113in the appendixof this manual.BIND is configured as forwarding and caching-only server. Allrequests will be passed on to the forwarders.

5.3.3 MAIL

Postfix

A more secure, quicker, and more flexible modular mail transport agent used onthe Live CD as mail relay. Note that a built-in hard disk is absolutely essentialfor using the mail relay function, becausepostfix first has to route the incominge-mails to a buffer.

88


5.3.4 HTTP Proxy

TheSuSE Linux Live CD for Firewall uses a multitude of proxies to enable themost refined access control to HTTP/HTTPS services as possible. Two separateproxy branches are used to govern internal access to the outside and externalaccess to inside networks.

Squid

Squid is an HTTP proxy that offers extensive configuration options as well asaccess controls for clients to the WWW by way of ACLs (access control lists).

The internal HTTP proxySquid can be configured to be either transparent or non-transparent. Innon-transparentmode, the following protocols are supported:

• http

• https

• FTP

The prerequisite for this is that this is set as a proxy for the clients (web browser).

� �

�

NoteSquid can, however, only process HTTP transparently. Transparent HTTPSand FTP do not function with Squid. There is currently no solution availablefor transparent HTTPS apart from being guided straight through the firewall.The proxy suite can be used for transparent FTP (internal FTP in the FAS).

More exact information onSquid can be found AppendixB on page125.

httpf, tinyproxy

The applicationhttpf is responsible for "content filtering". It is not actually aproxy, as proxy functionality is furnished by the programtinyproxy.

It is more specifically a filtering proxy that can prevent downloading and execut-ing program code. This occurs in that only known and benign language elementsare forwarded to the web browser. Even the HTTP header entries can be filteredso that, for instance, no information can be posted to the server via the clienthost’s operating system.

The configuration can be generated using FAS on the Adminhost.

transproxy

transproxy governs external access to an internal web server.

Altogether, these applications offer the option of multifaceted filtering: ACLsfor clients, servers, ban lists, content filtering, and web caching.

89


5.3.5 FTP Proxy

FTP service is split up into two channels. First, setting up the internal connectionto the outside and, second, setting up the external connection to the inside orDMZ.

Internal to external:

magic user

Enables the user name, the host, and the destination FTP server’s port to beprovided (e. g.,[email protected]:2345 ) — automatic execution of theUSER command.

External to internal:

To run an FTP server accessible from the Internet, define the settings in thisdialog of the module.

Proxy Configuration for Personal FTP Server

IP Address of the FTP Server: IP address of your FTP server in your DMZ orintranet, which should be accessible from the Internet.

FTP Proxy Port: Normally 21 (default).

Maximum Number of Clients: The maximum number of open connections isset to 512 (typically 64).

Listen to Selected IP Address: IP address of the interfaces on which the FTPserver listens for connection requests from the Internet. ‘0.0.0.0 ’ assignsall the firewall machine’s interfaces.� �

� NoteThe FTP proxy opens its data channels for external clients in the portnumber range of 41000 to 41999. Keep this in mind when configuringyour packet filter.

Port reset PASV: There are two possibilities for establishing a connection toan FTP server:

• Active FTP mode: when there is a request, the server opens a port for datatransfer.

• Passive FTP mode (PASV): the port number is relayed to the server spec-ified for receiving the data.

Identical Address: If this option is enabled (‘yes ’, Default), the same serverreceiving incoming requests will be forced to respond to these as well.

90

[email protected]:2345


5.3.6 SSH

openSSH enables use of a shell on a remote host where the connection is en-crypted.

5.3.7 chroot, secumod, compartment, kernel capabilities

To raise the security level on the firewall, run the services on the SuSE LiveCD for Firewall in achroot environment. The “secumod” kernel module and“compartment” will also be implemented. Setting capability bits in the kernelincreases the security of the system applications.

chroot With chroot, an application can change its view to the file system irre-vocably by defining a new "root" for the file system. As soon as the appli-cation has applied itself to this segment of the file system, this segment willadopt the role of the entire file system for this application. The rest of thefile system no longer exists as far as this application is concerned. Even ifthe program has somehow crashed, the hacker would remain in this chroot()environment so be unable to damage the actual system.

secumod Special kernel module that raises the system security level. This in-volves defining

• the trusted path

• adding a ban on hard links to files not belonging to the user

• protecting the proc file system

• not tracing symlinks if they do not correspond to the process currentlyrunning (exception: the process is running under‘root’ permissions)

• protecting fifos

• syscall table checking

• logging

• setting capabilities

compartment Enables execution of applications and services in chroot jailswith unprivileged users and groups. It supports scripts run before the pro-gram actually starts (e. g., to set up a chroot() environment.) Supports theuse of kernel capabilities.

kernel caps Kernel capability bits

Increasing security by limiting the capabilities of executable programs. Thecapabilities are documented in

/usr/include/linux/capability.h

Using the application compartment is another relatively simply option forspecifying the capabilities for an application.

91


5.4 The Configuration Disk

The configuration disk contains the complete system and application level gate-way configurations.The configuration disk must be accommodated with an ext2 file system and ob-tain the label "SuSE-FWFloppy" via the following command:Insert a disk formatted with an ext2 file system./sbin/e2label/dev/fd0SuSE-FWFloppy

The configuration disk will not be recognized without this label. The FAS (Fire-wall Administration System) on theSuSE Linux Adminhost for Firewall willautomatically generate the file system and the label.The configuration disk will be read as the Live CD is being booted.

5.4.1 Creating the Configuration Disk

The configuration disk can be generated on theSuSE Linux Adminhost for Fire-wall using the administration desktop FAS. It will generate a tar archive that isthen decompressed on the disk. This is the recommended procedure. Changingthe configuration files with an editor should be left to experts who really knowwhat they are doing. No support is offered for manual configuration.

5.4.2 The Configuration Files

The following overview of the configuration files located on the disk is for infor-mation purposes only. The files will already be generated by the admin desktop:/etc/hosts (see man hosts)/etc/hosts.allow (see man 5 hosts_access)/etc/hosts.deny (see man 5 hosts_access)/etc/inittab (man inittab)/etc/isdn//etc/cipe//etc/live-setup.conf/etc/passwd/etc/ppp//etc/localtime/etc/modules.boot

In the/etc/modules.boot file, specify loadable kernel modules to start alongwith the system. They will be listed with their relative path names in the/lib/modules/<kernelversion>/ directory. If necessary, additional options canbe posted to the module, such as irq or the IO addresses of the hardware used.Lines beginning with "#" will be ignored. If a "-" precedes the module name,an attempt will be made to unload the module (this may be necessary if theautomatic hardware recognition tries to load the wrong network module, for in-stance).Example:

92

5.4 The Configuration Disk

# In this file you can provide a list of modules# and options, that have to be loaded on system boot.# Module name can be used relative, i.e. net/ppp.o.## Module name [options]## z. B.:#misc/cipcb.o#net/slhc.o#net/ppp.o#net/ppp_deflate.o#net/ppp_mppe.o-net/de4x5.o # This module will be removed

net/tulip.o # This module will be loaded

/etc/ipsec.d/ contains certificates and configuration files

/etc/named/ contains the zone files of the name server

/etc/named/master/ contains the master zone files

/etc/named/slave/ contains the slave zone files

/etc/named/root.hint contains the addresses of the root name server

/etc/named.conf responsible for the configuration of named

/etc/pam.d/ this directory contains the PAM (Pluggable Authentication Mod-ule) configuration files

/etc/permissions.local sets the access permission of and to applications, files,etc.

/etc/postfix configuration directory forPostfix. The major configuration filesare

• /etc/postfix/master.cf

• /etc/postfix/main.cf

• /etc/postfix/virtual

• /etc/postfix/transport

• /etc/postfix/access

/etc/proxy-suite/ configuration directory for FTP proxies

/etc/rc.config SuSE Linux central configuration file

/etc/rc.config.d/ contains further configuration files read bySuSEconfig

/etc/rc.config.d/firewall.rc.config configuration file for the SuSE Firewall Script.It is generated by the FAS on theSuSE Linux Adminhost for Firewall .

/etc/resolv.conf configuration for the resolver library: list of name servers andthe search list

93


/etc/route.conf file containing the information related to generating the statickernel routing table

/etc/runlevel.firewall In this file, scripts and applications are assigned to run-levels of the firewall. If a script should be started in a certain runlevel, enterit in the corresponding column in this file.

/etc/securetty list of the ttys where the user‘root’ can log on

/etc/shadow Contains the encrypted passwords. Normally, these are listed inthe form of a “*” for each user except‘root’ , so only‘root’ can log in.In FAS, you have to option not to define a‘root’ password, in which caseaccess to the firewall would only be possible via ssh and RSA key.

/etc/squid.conf configuration file for the HTTP proxySquid

/etc/ssh/ Contains the configuration files foropenssh: ssh_config andsshd_config .

/etc/su1.priv Configuration file for thesu1 command that permits selected usersto run programs with uid=0 (i.e., as‘root’ ).

/etc/syslog.conf Configuration of the syslog daemon. To this end, read theman pagesman 5 syslog.conf , man 8 syslogd , andman 3 syslog .

The log host and the messages to log are entered in this file. The entry forthe log host should appear as follows:*.* @hostname.domain.tl (or the IP address)

/etc/syslog.socks The log daemonsyslog has to create a writable socket forall services started in thechroot environment. This process is associatedwith the following files:/var/named/dev/log/var/squid/dev/log/var/chroot/rinetd/dev/log/var/chroot/ftp-intern/dev/log/var/chroot/ftp-extern/dev/log

/sbin/, /sbin/init.d/ This directory contains self-written init scripts, such as IPpacket filter scripts.

/root/, /root/.ssh/, /root/.ssh/authorized_keys This file contains the RSA pub-lic key of the fwadmin user on theSuSE Linux Adminhost for Firewall .This enables the user‘fwadmin’ to log in on the firewall as‘root’ . RSAkeys, protected by an additional pass phrase, handle user authentication. Thispass phrase is generated during the installation of the Adminhost by way ofthe YaST2 module “Firewall Admin Host”.

You can also generate the RSA keys at the command line using the commandssh-keygen(1) . Read more about it in the man page (man ssh-keygen ).

It is highly recommended to use the administration desktop FAS on theSuSELinux Adminhost for Firewall for creating configuration files.

94

5.5 Boot Parameters

5.5 Boot Parameters

You can give boot parameters at the linuxrc boot prompt as usual (see referencemanual, kernel boot parameters).

The following restrictions apply:

For security reasons,init=/bin/bash or the like cannot be entered at the bootprompt for obtaining privileged permissions in a shell.

Boot parameters beginning with "init=" will be ignored.

95


96

6 Implementing the Firewall


Requirements for successful implementation:

You have manually created a configuration for theSuSE Linux Live CD for Fire-wall by way of theSuSE Linux Adminhost for Firewall or a configuration floppy.Alternatively, you have enlisted the services of the SuSE Linux AG for settingup a firewall and now want to begin operating the firewall host. Starting up thefirewall should proceed in several steps. First, check to see if your host bootsusing the configuration set up and also to see if the selected services start and areavailable for use. Next, check to see if the IP filter of the kernel is working asconfigured.

6.1 Booting the Firewall Host

1. Start the host then open the BIOS setup program. Check the settings for thetime and date.

2. Configure the boot sequence so the host boots from the CD first — if possi-ble, only from the CD.

3. Assign a BIOS password to prevent, for instance, changes to the boot se-quence and to prevent the firewall from being booted from disk.

4. Save the BIOS configuration.

5. Insert the SuSE Linux Live CD for Firewall.

6. Insert the configuration floppy.

7. Reboot the host.

8. Note any errors that appear when booting and revise the respective config-uration files if necessary. If services do not start (message: "<Servicexyz>failed/skipped"), the corresponding configuration file for the service<xyz>contains an error. If this is the case, recreate the configuration disk usingthe FAS tool on the Adminhost or revise the configuration saved there andrewrite this to the configuration disk.

You should have already defined the configuration of the hard disk using FAS,but if partitions 1 (swap) and 2 (var) of the firewall host do not correspond to thesettings in the/etc/live-setup.conf file, a dialog screen will appear. Toreconfigure the hard disk, answer ‘yes ’.

97


6.2 Testing the Firewall

Before employing the firewall for daily use, testing should be done to ensure that,first of all, the packet filter is configured correctly and that second of all, the (con-figured) proxies all start and requests are processed properly. Adminhost toolsare available on the SuSE Firewall for these purposes (see Chapter3 on page15),such as nmap, nessus, xlogmaster, logsurfer, and http clients. Detailed documen-tation for these programs is available in the/usr/share/doc/packages/ di-rectory on theSuSE Linux Adminhost for Firewall . Man pages are also availablefor each program.Only when every single test has been successfully completed can you start thefirewall. Document all tests conducted.

6.3 Testing Operation

Before actually using your firewall, it is important to thoroughly test the pro-tection measures. First, connect a laptop or other computer to the firewall hostto simulate an external network. Then, close the connection to the internal net-work and establish a connection to the Internet. If possible, test your firewallexternally.Check your setup. Test EVERYTHING!

6.3.1 Internal testing

Tests to carry out:

• Are all services available?

• Test if the permitted services are working from the internal clients. Can youaccess https, send e-mails, transfer data via FTP?

• Are your restrictions effective?

• Test your packet filter. Try using a port scanner like nmap. Follow the logmessages of your firewall on the log host or on your firewall itself. Let apacket sniffer run simultaneously to detect restricted packets or to see if re-sponse packets are not being sent.

• Are the log files being written to the log host?

Fixing errors:Determine the source of the problem. Search for the log files according to pro-cess name, for example, postfix or named:# grep postfix /var/log/messages

or# grep named /var/log/messages

Many programs can be switched to “verbose mode”. In this way, obtain detailedinformation, which can, however, be quite extensive.

98

6.3 Testing Operation

6.3.2 External testing

Test externally to see if the available services are working. For instance, youcan send e-mails to the internal network. You should be able to see in the post-fix messages in/var/log/mail on the firewall host whether the e-mails wereaccepted and could be delivered to the internal mail server. Check to see if thepacket filter is working. This can be verified by a port scanner. At the sametime, find the kernel packet filter messages in/var/log/messages as well asin the log directories of the log host. These messages will be reflected in the"DENY" and "ACCEPT" messages. Try to set up connections to explicitly re-stricted ports and attempt to find the corresponding log entries and match themto their corresponding events.

If you are using a log host, check to see if the log messages are being transmittedin their entirety.

6.3.3 “Really” going online

Only after you have completed all these tests, connect the firewall host to theInternet and to your intranet and begin productive operation.

� �

� NoteConstantly monitor your log files. This is the only way to ensure a timelyresponse to attacks or failures. If unusual events occur, react immediately.Raise the log level (if possible) and refine your log analysis.

99


100

7 Help

7 Help

In this chapter, find information about creating a setup concept for a firewallsolution in your network using theSuSE Linux Firewall on CD . Also find in-formation about using the services of SuSE Linux AG to have a plan drawn uptailored to your specific needs.

7.1 Troubleshooting

Find help here if the Adminhost cannot be installed or if theSuSE Linux LiveCD for Firewall is not booting.

7.1.1 Problems Installing the Adminhost

If you have trouble installing theSuSE Linux Adminhost for Firewall , SuSELinux Installation Support is available free of charge. First, check the supportdatabase. Here, find a realm of information on a variety of installation problems.A keyword search will help find relevant information. The support database isavailable athttp://sdb.suse.de .

7.1.2 Problems Booting the Live CD

To simplify your troubleshooting, observe and note the following:

• What happens when you boot?

• Are services not started that have already been configured (skipped or failedmessages)?

• Do error messages appear on the console?

• Are there kernel error messages on virtual consoles 9 or 12? To see thesemessages, change to this console using

�� Alt +�� F9 or�� Alt +�� F12 .

7.1.3 Problems Integrating the Network

Observe and note the nature of the problems. For example, on the firewall, testwhether the network interfaces are configured correctly (log in to the firewall asuser‘root’ ) by enteringifconfig .

This command will show which interfaces are configured and which IP ad-dresses, network masks, etc., are set up. If necessary, correct the configuration

101

http://sdb.suse.de

7 Help

using FAS and create a new configuration floppy. The host must be restarted tocommit the new configuration.

• Which services function from the client side (intranet)? Should they be func-tioning? The log files can help determine whether it is a problem involvingunauthorized access.

Try reproducing the errors.

• Is external access to available resources not functioning? Which services areaffected? Should the resources really be accessible?

Test usingps whether the process is available — whether the process is ac-cessible. If services are not accessible, check your log files. Find messagesabout why a particular service was not started or whether an unauthorizedparty has been attempting to make use of the service.

Test from several clients whether the firewall host is accessible and whetherthe proxies are responding.

7.2 Security Policy and Communication Analysis

To ensure that the internal network’s connection to the Internet (or to any other“unprotected” network) is secure, a few things will need to be clarified first. Thisincludes outlining a security policy for your own network as well as undertakinga communication analysis.

7.2.1 Security Policy

The security policy provides the basis for working with all programs, hosts, anddata. In addition, it outlines how to guarantee the monitoring of security guide-lines and how internal or external breaches of this policy are handled. To draft asecurity policy, it is best to produce a communication analysis. To this end, thefollowing topics are of utmost importance:

• An analysis of your security requirements is necessary. What needs to beprotected?

• Are there areas of the intranet that contain especially sensitive data (such asthe personnel department and data critical of the company). Where is thisdata located?

• Who can access the data? Are there various levels of authorization?

• Should data be available over the network?

• Which services should be accessible internally? Which services should beaccessible from internal to external (e-mail, surfing, data transfer) and whichservices external to internal (e-mail, web services, data transfer)?

The list of questions to answer in a security policy must be drawn up individuallyand answered.

102

7.3 Services Offered by SuSE Linux AG

7.2.2 Communication Analysis

The most important aid for carrying out a communication analysis is a commu-nication matrix. The services available for client hosts and users are representedhere in a table format. This matrix is then mapped to the proxies and IP filterrules.

Setting up a communication matrix:

Make a list of all clients and servers on your network. Then define which pro-tocols may be used by which clients. Also, state in which direction each packetcan be sent or received.

An example for HTTP protocol: The client host1 needs to access a web serverin the internal network, but should not be able to establish a connection to anexternal web server. The entry in the communication matrix will then appear asdepicted in the example shown below.

Protocol icmp ftp ssh smtp http https . . .Client internal external i. e. i. e. i. e. i. e. i. e.

host1 x – x – – – x – x – –host2 x – – – x – x – – – – –host3. . .hostn

With the help of such a communication matrix, obtain an overview of the com-munication constellations within the network. This will simplify the configura-tion of your network and error analysis.

7.3 Services Offered by SuSE Linux AG

SuSE Linux AG offers its services in the areas of:

• Consulting:

Clarification of security needs, communication analysis

• Planning:

– Hardware requirements

– Network planning and integration

• Installation:

– On-site installation of the firewall solution

– Conducting tests on-site or remotely

– Documentation

103

7 Help

• Maintenance:

– Business support (available at cost)

– Online maintenance via modem or call-back (by consulting or businesssupport)

7.4 Updates

One of the most important aspects of operating a firewall is constant mainte-nance of the implemented software. As soon as a security gap is discovered andremedied, the respective software must be updated.

If such a security update affects theSuSE Linux Live CD for Firewall, a newLive CD will be sent to you. This update CD can simply be inserted into the CDdrive of the firewall host and the firewall restarted.

Security-related updates for theSuSE Linux Adminhost for Firewall will bemade available on the SuSE FTP server. This package can be loaded to theadminhost and installed by giving a command like:root@adminhost:# rpm -Uhv newpackage.rpm

Also follow the instructions posted on the security mailing lists and the SuSEweb server:

http://lists2.suse.com/archive/suse-securityhttp://www.suse.de/de/support/security/index.html

104

http://lists2.suse.com/archive/suse-security

http://www.suse.de/de/support/security/index.html

7.5 Detecting Attacks


7.5.1 Intrusion Detection and Event Display

A properly configured Linux/UNIX system can, in and of itself, be consideredquite secure. Internal system hazards associated with a complex system suchas Linux or UNIX are more easily recognized than on other operating systemsbecause UNIX has been used and developed for over thirty years. UNIX alsoforms the basis of the Internet. Nevertheless, configuration errors can occur andsecurity holes can appear. There will always be security flaws. Security expertsand crackers are in perpetual competition to be one step ahead of the other. Whatqualifies today as secure may be vulnerable tomorrow.

Signs of Intrusion

Any abnormal behavior on your firewall system can be considered a sign thatyour system is compromised:

• increased processor load

• unusually heavy network traffic

• unusual processes

• processes started by nonexistent users

Recognizing an Intrusion

First, understand which actions are defined as intrusions. Unfortunately, it is nor-mal these days that a host connected to the Internet will be scanned for open andvulnerable ports. It is just as common that ports recognized as vulnerable (suchas POP3 or qpopper, rpc-mountd, smtp or sendmail) are attacked. Most of theseattacks are carried out by “script kiddies”. Prefabricated “exploits” published onrelevant web sites (e. g.,http://www.rootshell.com ) are used. These webpages also exist as valuable information sources for network and system admin-istrators. They can usually be identified by the fact that the hack is only carriedout once and is not repeated if the action fails in the first attempt. The first mea-sure to take in case of such an event is to check if a break-in really did happen.Furthermore, raise the log level and refine the evaluation (e. g., a selective searchaimed at an intruding IP address in the log files or any unusual port numbers).

What you consider a dangerous attack on your system remains up to your dis-cretion. At least you determine how you are going to react to such an event. Thefollowing literature is recommended if you suspect an intrusion:

“Steps for Recovering from a Unix Root Compromise” (http://www.cert.org/tech_tips/root_compromise.html )

RFC 2196 Site Security Handbook

Both publications describe procedures that should follow any successful break-in. The documents provide a formal starting point as to how a company, agency,

105

http://www.rootshell.com

http://www.cert.org/tech_tips/root_compromise.html

http://www.cert.org/tech_tips/root_compromise.html

7 Help

or educational institution can react. The procedure discussed there necessitatesa certain amount of memory to take “snapshots” of the system, as well as re-quires colleagues to carry out the analysis and to examine the security problem.Situations are described that may necessitate taking punitive action.

If you suspect a successful attack:

• It is important to stay calm. Hasty actions can destroy important information(e. g., processes initiated by the cracker that contain information about whatthe cracker is doing or how he is attacking).

• The course of action as well as who to inform should be outlined in thesecurity policy. The communication should not take place by e-mail, but bytelephone or fax.

• Physically cut the network connection to the firewall. It is not a good ideato shut down the computer. Important information could be lost, such asprograms started by the cracker.

• List all running processes withps and search for processes that do not typ-ically occur in normal firewall operation. Draw up a process table whensetting up the firewall that can later serve as a basis for comparison.

• Check the running processes for ties to unusual TCP or UDP ports.

• Were the packet filter rules changed?

• Compare all configuration files with the original configuration. This is veryeasy with theSuSE Linux Firewall on CD , because the configuration is al-ready saved on the Adminhost. In doing so, however, it is essential not torestart the firewall host, because any changes to the filter rules could be lost.

• Also back up all log files. The log files could be legally admissible evidence.Document all steps you have taken. If you save the log files locally to thehard disk, make an exact copy of the hard disk for documentation purposes.

• Save your data to CD or to another medium (tape drive, ZIP drive).

• Analyze the log files: Who tried to access what services or ports when andfrom where (IP address, domain name, possibly even user name)? Was anattempt made to uncover passwords (multiple failed login attempts with thesame user name)?

• Make sure you are using a uniform and exact time source. It is importantthat the hardware clock of the firewall host and the log host are as closely insync as possible. Use a common time source for all your servers wheneverpossible. Only in this way can you keep track of events accurately.

• Which parts of the security policy were violated? This is especially importantin regard to internal intrusions.

• You may want to deactivate the user account in your network that carried outthe attack, if it was an internal attack. The relevant procedure pertaining tointernal violations should also be regulated (security or company policy).

106


7.5.2 External Attacks

Inform the system administrator responsible for the address block (via postmas-ter or the domain’s abuse address). The question is raised as to what informationneeds to be given. The report of an incident or attack should contain enoughinformation to ensure that the other party can investigate the problem. However,consider that your contact person could be the one who has carried out the attack.Here is a list of possible information to provide. Decide which of the followingpieces of information you want to give:

• Your e-mail address

• Telephone number

• Your IP address, host name, domain name

• The IP addresses, host names, and domain names affected by the hackingincident

• The date and time of the intrusion, preferably with the time zone

• A description of the attack

• How the attack was recognized

• Excerpts of the log files relating to the attack

• A description of the log file format

• Statement of advisories and security information that describes the natureand severity of the attack

• What you want the contact person to do: Close an account, confirm the oc-curence of an attack, issue a report for information purposes only, request forfurther observation

Once you have gone through all the data security and documentation procedures,set up your firewall again. Raise the log level of each application if possible. Itis likely the cracker will try to infiltrate your system again. This will be theopportunity to catch the intruder red-handed.

Examples:

Log in to the console.

Examine the log files.

For example:# grep DENY /var/log/messages | less

With this command, see all the lines contained in aDENY— the lines listed bythe kernel’s packet filter. For instance, search for certain unusual IP addresses(frequently occurring DENY messages that correspond to IP addresses on oneor more port numbers). Find out exactly what happened. Using the tools previ-ously mentioned, examine the log files according to definable criteria. Problem:

107

7 Help

Sometimes it is unclear what to look for until you find it. It is also possiblethat a system administrator from another network is reporting a complaint, viapostmaster or abuse mail address, that attacks have been occurring from yournetwork to remote hosts. Take such complaints seriously. Request that logs ofall intrusions are sent so that you have an idea of the date and time as well asthe method of attack on the external system. Attempt to verify the circumstancessurrounding the incident. A cracker, intruder, or attacker may have already over-stepped the security boundaries and misused your network. In respect to this, thereputation of your business hangs in the balance.

Once you have backed everything up and documented it, review your firewallconfiguration. After remedying possible errors or after shutting down servicesat risk, restart your firewall. This shows the clear advantage of theSuSE LinuxFirewall on CD : the original status of the firewall will be restored simply byrebooting the firewall host, making a complicated reinstallation of the operatingsystem and bringing in the backups unnecessary.

7.5.3 Advantage of the Live File System

One of the greatest advantages of theSuSE Linux Firewall on CD is that itsinitial state can be restored simply by booting it. Keep in mind that any possibleconfiguration errors may reappear.

If the firewall has been breached, the method of intrusion should be investigatedto correct configuration errors. If security holes are found in applications, SuSELinux AG provides updates for the affected applications — in the case of theSuSE Linux Live CD for Firewall, a new CD.

Find more information athttp://www.cert.org andhttp://www.first.org .

7.6 Professional Help and Support

If you suspect an attack, but are uncertain as to whether the attack has led todamage to your network, despite having carried out the review procedures asdescribed above, introduce initial security measures. That means, first and fore-most, physically disconnecting the network.

Direct your inquiries to the vendor where you purchased theSuSE Linux Fire-wall on CD or consult SuSE directly. In such cases, you can also enlist theservices of SuSE Linux AG.

7.6.1 Installation Support

The installation support is there to assist with installing your SuSE Linux Sys-tem. This also applies to the central system components that allow for funda-mental operation. It includes:

108

http://www.cert.org

http://www.first.org

http://www.first.org


• Support ranging from the installation of the SuSE Linux base system on ahost from theSuSE Linux Admin CD for Firewall to the successful start-upof the “Firewall Administration System” (FAS).

• The configuration of the basic hardware of this host with the graphical instal-lation tool YaST2 — the central components of the PC, excluding peripheraldevices but including the configuration of an ethernet card.

Topics not mentioned here are not covered by installation support.

Time Period

The installation support for the Admin CD for Firewall lasts for a period of 30days following the registration date.

Reaching the SuSE Support Team

Reach our support team by e-mail, fax, or mail:

• E-mail:

Address: [email protected]

Processing: weekdays

• Fax:

Fax number: +45 (09 11) 74 05 34 77


• Mail:

Address: SuSE GmbH– Support –Schanzäckerstr. 10D-90443 Nürnberg


7.6.2 Professional Services

Even if an operating system comes with all the necessary facilities, it will onlybe a viable alternative for use in the corporate environment in combination withprofessional and qualified support services. SuSE guarantees this kind of servicefor Linux. All information on this can be found at the central support portal forSuSE Linux:

http://www.suse.de/en/support/

109

mailto:[email protected]

http://www.suse.de/en/support/

7 Help

Individual Projects and Consulting

You would like to use SuSE Linux at your place of business. We offer competentconsultation and solutions enabling you to optimize the performance of Linux inyour field of computing.

We have a large amount of experience in the deployment of Linux servers be-cause we have been dealing with Linux since the early days. This is where theexperience of our consultants comes into play. You can use the know-how of ourexperts to successfully realize your projects. Our strength lies in our versatil-ity. Databases, security issues, Internet connections, or company-wide networks,Linux is, with the right software, a powerful platform for your applications. Ourservices range from the conception, implementation, and configuration of serversystems to a complete infrastructure consultation.

You may want, for instance, to implement your Internet presence on a SuSELinux system and are therefore looking for web server, e-mail, and secure serversolutions. Our consultants can help you to conceptualize and implement the rightsolution.

Are you managing a complex heterogeneous network in which you would liketo integrate Linux? We offer consultation and support for the design and rolloutof complex server solutions.

Do you have special requirements or needs that are not fulfilled by standardsoftware? We can assist you further in individualized system development:

SuSE Linux AGSchanzäckerstraße 10D-90443 NürnbergTel: +49-911-740-53-0Fax: +49-911-740-53-479E-Mail: [email protected]

Represented by our Regional Service Centers in Germany and outside, as well asour Support and Development Center in Nuremberg, on-site support is providedby the companySuSE Linux AG :

• Rollout and Implementation Services

• Infrastructure Consultation

• Intranet Server Solutions

• Internet Server Solutions

• Development of Client-Specific Requirements

• Complete Solutions

• E-Commerce

110

[email protected]


7.6.3 Training

Our specialists train system administrators and programmers in such a way thatthey are able to make use of the wide range of possibilities in Linux as quickly aspossible and thus work productively. For more information on training courses,seehttp://www.suse.de/en/support/training/ .

7.6.4 Feedback

We always appreciate your tips, hints, and problem descriptions. We will helpyou if your problem is a straightforward one or if we already have the solutionat hand. Your feedback may provide us with useful information to help us avoidthis problem in our next release, thus helping other SuSE Linux customers viaour web server or the Support Database.

We make every effort to construct a SuSE Linux system that meets the wishesof our customers as closely as possible. We therefore appreciate any criticism ofour CD or of this book. We think this the best way to correct significant errorsand to maintain our high standard of quality.

Send feedback any time [email protected] e-mail or send us a letter orfax.

7.6.5 Further Services

We would also like to draw your attention to our services available around theclock free of charge:

• SuSE WWW Serverhttp://www.suse.com

Up-to-date information, catalogs, ordering service, support form, supportdatabase

• SuSE Mailing Lists (information and discussions via e-mail):

– [email protected]– announcements concerning SuSE GmbH(German)

– [email protected]– announcements concerning SuSE GmbH(English)

– [email protected]– Discussions concerning the SuSE Linux Distri-bution (German)

– [email protected]– Discussions all about SuSE Linux (English)

– [email protected]– Discussion concerning the SuSE proxy suite (En-glish)

– [email protected]– Information and discussion concerning Adabas-D in SuSE Linux (German)

– [email protected]– Discussions concerning theApplixware pack-age of SuSE GmbH (German)

111

http://www.suse.de/en/support/training/


http://www.suse.com








7 Help

– [email protected]– SuSE Linux on alpha processors (English)

– [email protected]– Information and discussion concerning SuSELinux and Lotus Domino (German)

– [email protected]– SuSE Linux and amateur radio (German)

– [email protected]– SuSE Linux and amateur radio (English)

– [email protected]– SuSE Linux and IBM DB2 (English)

– [email protected]– ISDN with SuSE Linux (German)

– [email protected]– Information and discussion concerning In-formix in SuSE Linux (English)

– [email protected]– SuSE Linux on laptops (German)

– [email protected]– SuSE Linux on Motif (English)

– [email protected]– Information and discussion concerning Oraclein SuSE Linux (English)

– [email protected]– SuSE Linux on Power PC processors (English)

– [email protected]– Discussion of security issues in SuSE Linux(English)

– [email protected]– Announcement of security-relatederrors and updates (English)

– [email protected]– SuSE Linux on Sparc processors (English)

To subscribe to a list, send an e-mail message to:

<LISTNAME>[email protected]

An automatic response will be sent back that you will need to confirm. For<LISTNAME>, substitute the name of the mailing list to which to sub-scribe, for example,[email protected] receive regularannouncements.

The procedure is similar for unsubscribing from a list:

<LISTNAME>[email protected]

Please be sure to send theunsubscribe mail with the proper e-mail address.

• SuSE FTP Serverftp://ftp.suse.com

current information, updates, and bug fixes

Log in to the system as user‘ftp’ .

7.7 Recommended Reading

• Maximum Linux Security, SAMS 1999.

• Robert L. Ziegler:Linux Firewalls, New Riders 1999.

112
















ftp://ftp.suse.com

A DNS — Domain Name Service


DNS (Domain Name Service) is needed to resolve the domain and host namesinto IP addresses. In this way, the IP address192.168.0.20 is assigned to thehost nameearth , for example.

A.1 Starting the Name Server BIND

The name server BIND8is already preconfigured in SuSE Linux, so you caneasily start it right after you have installed the distribution.

If you already have a functioning Internet connection and have entered 127.0.0.1as name server for the local host in/etc/resolv.conf , you should normallyalready have a working name resolution without having to know the DNS of theprovider. BIND carries out the name resolution via the root name server, a no-tably slower process. Normally, the DNS of the provider should be entered withits IP address in the configuration file/etc/named.conf underforwarders toensure effective and secure name resolution. If this works so far, the name serverwill run as a pure “caching-only” name server. Only when you configure its ownzones will it become a proper DNS. A simple example of this can be found in thedoc directory under/usr/share/doc/packages/bind8/sample-config .However, you should not set up any official domains until you have actuallybeen assigned one from the responsible institution. Even if you have your owndomain and it is managed by the provider, you are better off not to use it, asBIND would otherwise not forward any more requests for this domain and theprovider’s web server, for example, would not be accessible for this domain.

To start the name server, enter, as‘root’ ), rcnamed start . If “done” appearsto the right in green, it meansnamed, as the name server process is called, hasbeen started successfully. Immediately test the functionality of the name serveron the local system with thenslookup program. The local host should show upas the default server with the address 127.0.0.1. If this is not the case, the wrongname server has probably been entered in/etc/resolv.conf or this file doesnot exist. For the first test, enternslookup “localhost” or “127.0.0.1” at theprompt, which should always work.

If you receive an error message instead, such as “No response from server”,check to see ifnamed is actually running using the commandrcnamed status .If the name server is not starting or is exhibiting faulty behavior, find the possiblecauses of this logged in/var/log/messages .

If you have a dial-up connection, be sure that BIND8, once it starts, will reviewthe root name server. If it does not manage this, because an Internet connection

113


has not been made, this can cause the DNS requests not to be resolved other thanfor locally defined zones.

To implement the name server of the provider or one you already have running onyour network as “forwarder”, enter one or more of these in theoptions sectionunderforwarders . See FileA.1.1. The IP addresses used in the example are

options {directory "/var/named";forwarders { 10.11.12.13; 10.11.12.14; };listen-on { 127.0.0.1; 192.168.0.99; };allow-query { 127/8; 192.168.0/24; };notify no;

};

File A.1.1: Forwarding Options in named.conf

arbitrary so must be adjusted to your personal environment.

After options follow the zone, “localhost”, “0.0.127.in-addr.arpa”, and “.” en-tries. At least entries from “type hint” should exist. Their corresponding filesnever have to be modified, as they function in their present state. Also, be surethat a‘;’ follows each entry and that the curly braces are properly set.

If you have made changes to the configuration file/etc/named.conf or tothe zone files, adjust BIND to reread these files by enteringrcnamed reload .Otherwise, completely restart the name server by enteringrcnamed restart .To stop the name server, enterrcnamed stop . If named should be started whenbooting, reset the entrySTART_NAMED=noto START_NAMED=yesin /etc/rc.config .

A.2 The Configuration File /etc/named.conf

All the settings for the name server BIND8 are made in the/etc/named.conffile. The zone data, consisting of the host names, IP addresses, and similar,for the domains to administer are stored in separate files in the/var/nameddirectory.

The /etc/named.conf is roughly divided into two areas: one is theoptionssection for general settings and the other consists ofzone entries for the indi-vidual domains. Additional sections forlogging andacl type entries can beadded. Comment lines begin with a‘#’ sign or‘//’ .

A minimalistic /etc/named.conf looks like FileA.2.1on the next page.

A.2.1 The Most Important Configuration Options

directory "/var/named"; specifies the directory where BIND can find the filescontaining the zone data.

114

A.2 The Configuration File/etc/named.conf

options {directory "/var/named";forwarders { 10.0.0.1; };notify no;

};

zone "localhost" in {type master;file "localhost.zone";

};

zone "0.0.127.in-addr.arpa" in {type master;file "127.0.0.zone";

};

zone "." in {type hint;file "root.hint";

};

File A.2.1: A Basic /etc/named.conf

forwarders 10.0.0.1; ; is used to specify the name servers (mostly of the provi-der) to which DNS requests, which cannot be responded to directly, are for-warded.

forward first; causes DNS requests to be forwarded first before an attempt ismade to resolve them via the root name server. Instead offorward first ,forward only can be written to have all requests forwarded and the rootname servers will stop responding. This makes sense for firewall configura-tions.

listen-on port 53 127.0.0.1; 192.168.0.1; ; tells BIND to which network in-terface and port it is listening. Theport 53 specification can be left out,because 53 is still the default port. If this entry is completely omitted, usu-ally all interfaces will be implemented

query-source address * port 53; This entry is necessary if a firewall is block-ing external DNS requests. This tells BIND to post requests externally fromport 53 and not from any of the ports greater than 1024.

allow-query 127.0.0.1; 192.168.1/24; ; defines the networks from which clientscan post DNS requests./24 at the end is an abbreviated expression for thenetmask, in this case 255.255.255.0.

allow-transfer ! *; ; controls which hosts can request zone transfers. This ex-ample cuts them off completely with the! * . Without this entry, zonetransfers can be requested anywhere without restrictions.

115


statistics-interval 0; In the absence of this entry, BIND8 generates severallines of statistical information in/var/log/messages . Specifying 0 sup-presses these completely. Otherwise, the time in minutes can be given here.

cleaning-interval 720; This option defines at which time intervals BIND8 clearsits cache. This actively triggers an entry in/var/log/messages each timeit occurs. The time specification is in minutes. The default is 60 minutes.

interface-interval 0; BIND8 regularly searches the network interfaces for newor no longer existing interfaces. If this value is set to0, this will not becarried out and BIND8 will only listen to the interfaces detected at start-up.Otherwise, the interval can be defined in minutes. The default is 60 minutes.

notify no; no prevents other name servers from being informed when changesare made to the zone data or when the name server is restarted.

A.2.2 The Configuration Section “Logging”

What, how, and where archiving takes place can be extensively configured inBIND8. Normally, the default settings should be sufficient. FileA.2.2representsthe simplest form of such an entry and will completely suppress any logging.

logging {

category default { null; };

};

File A.2.2: Entry to Suppress Logging

A.2.3 Zone Entry Structure

zone "my-domain.de" in {type master;file "my-domain.zone";notify no;

};

File A.2.3: Zone Entry for my-domain.de

After zone , the name of the domain to administer is specified,my-domain.de ,followed byin and a block of relevant options enclosed in curly braces, as shownin File A.2.3. To define a “slave zone”, thetype is simply switched toslaveand a name server must be specified that administers this zone asmaster (butcan also be a “slave”), as shown in FileA.2.4on the facing page.

The options:

116


zone "other-domain.de" in {type slave;file "slave/other-domain.zone";masters { 10.0.0.1; };

};

File A.2.4: Zone Entry for other-domain.de

type master; master indicates that this zone is administered on this nameserver. This assumes that your zone file has been properly created.

type slave; This zone is transferred from another name server. Must be usedtogether withmasters .

type hint; The zone. of the typehint is used for specification of the root nameservers. This zone definition can be left alone.

file “my-domain.zone” or file “slave/other-domain.zone”; This entry speci-fies the file where zone data for the domain is located. This file is not requiredby slaves , because its contents is read by another name server. To differ-entiate master and slave files, the directoryslave is specified for the slavefiles.

masters { 10.0.0.1; }; This entry is only needed for slave zones. It specifiesfrom which name server the zone file should be transferred.

allow-update { ! *; }; This options controls external write access, which wouldallow clients to make a DNS entry — something which is normally not de-sirable for security reasons. Without this entry, zone updates are not allowedat all. Note that with the above sample entry, the same would be achievedbecause! * effectively bars any clients from such access.

A.2.4 Structure of Zone Files

Two types of zone files are needed. One serves to assign IP addresses to hostnames. The other does the reverse: supplies a host name for an IP address.

‘.’ has an important meaning in the zone files here. If host names are givenwithout ending with a‘.’ , the zone be appended. Thus, complete host namesspecified with a complete domain must end with a‘.’ so the domain is notadded to it again. A missing point or one in the wrong place is probably the mostfrequent cause of name server configuration errors.

The first case to consider is the zone fileworld.zone which is responsible forthe domainworld.cosmos , as in FileA.2.5on the next page.

Line 1: $TTL defines the standard TTL that applies for all the entries in this file,here 2 days. TTL means “time to live”.

Line 2: TheSOA control record begins here:

117


1. $TTL 2D2. world.cosmos. IN SOA gateway root.world.cosmos. (3. 2001040901 ; serial4. 1D ; refresh5. 2H ; retry6. 1W ; expiry7. 2D ) ; minimum8.9. IN NS gateway10. IN MX 10 sun11.12. gateway IN A 192.168.0.113. IN A 192.168.1.114. sun IN A 192.168.0.215. moon IN A 192.168.0.316. earth IN A 192.168.1.217. mars IN A 192.168.1.3

File A.2.5: The File /var/named/world.zone

• The name of the domain to administer isworld.cosmos in the first po-sition. This ends with a‘.’ , because otherwise the zone would be ap-pended a second time. Alternatively, a‘@’ can be entered here. Then, thezone would be extracted from the corresponding entry in/etc/named.conf .

• After IN SOA is the name of the name server in charge as master for thiszone. The name is extended fromgateway to gateway.world.cosmos ,because it does not end with a‘.’ .

• Afterwards, an e-mail address of the person in charge of this name serverwill follow. Since the‘@’ sign already has a special significance,‘.’ en-tered here instead — [email protected] , root.world.cosmos. .The ‘.’ sign at the end cannot be neglected. Otherwise, the zone wouldbe added here.

• A ‘(’ follows at the end here, including the following lines up until‘)’into the SOA record.

Line 3: Theserial number is an arbitrary number that is increased each timethis file is changed. It is needed to inform the secondary name servers (slaveservers) of changes. For this, a ten-digit number of the date and run number,written as YYYYMMDDNN, has become the customary format.

Line 4: The refresh rate specifies the time interval at which the secondaryname servers verify the zoneserial number . In this case, 1 day.

Line 5: Theretry rate specifies the time interval at which a secondary nameserver, in case of error, attempts to contact the primary server again. Here, 2hours.

Line 6: The expiration time specifies the time frame after which a sec-ondary name server discards the cached data if it has not regained contactto the primary server. Here, it is a week.

118


Line 7: Theminimum time to live states how long the results of the DNSrequests from other servers can be cached before they become invalid andneed to be requested again.

Line 9: IN NS specifies the name server responsible for this domain.gatewayis extended togateway.world.cosmos because it does not end with a‘.’ .There can be several lines like this, one for the primary and one for eachsecondary name server. Ifnotify is not set tono in /etc/named.conf ,all the name servers listed here will be informed of the changes made to thezone data.

Line 10: The MX record specifies the mail server that accepts, processes, andforwards e-mails for the domainworld.cosmos . In this example, this isthe hostsun.world.cosmos . The number in front of the host name is thepreference value. If there are multiple MX entries, the mail server with thesmallest value is taken first and, if mail delivery to this server fails, an attemptwill be made with the next higher value.

Line 12–17: These are now the actual address records where one or more IPaddresses are assigned to the host names. The names are listed here with-out a ‘.’ , because they are entered without a domain added and can all beappended withworld.cosmos . Two IP addresses are assigned to the hostgateway , because it has two network cards.

The pseudodomainin-addr.arpa is used to assist the reverse lookup of IP ad-dresses into host names. This will be appended, for this purpose, to the networkcomponents described here in reverse order.192.168.1 is thus translated into1.168.192.in-addr.arpa . See FileA.2.6.

1. $TTL 2D2. 1.168.192.in-addr.arpa. IN SOA gateway.world.cosmos.

root.world.cosmos. (3. 2001040901 ; serial4. 1D ; refresh5. 2H ; retry6. 1W ; expiry7. 2D ) ; minimum8.9. IN NS gateway.world.cosmos.10.11. 1 IN PTR gateway.world.cosmos.12. 2 IN PTR earth.world.cosmos.13. 3 IN PTR mars.world.cosmos.

File A.2.6: Reverse Lookup

Line 1: $TTL defines the standard TTL that applies to all entries here.

Line 2: ’Reverse lookup’ should be activated with this file for the network192.168.1.0. Since the zone is called ’1.168.192.in-addr.arpa’ here, it is,of course, undesirable to add this to the host name; therefore, these are all

119


entered complete with domain and ending with‘.’ . The rest corresponds tothe previous example described for world.cosmos.

Line 3–7: See the previous example for world.cosmos.

Line 9: This line also specifies the name server responsible for this zone. Thistime, however, the name is entered completely with domain and ending with‘.’ .

Line 11–13: These are the pointer records linked to an IP address at the respec-tive host name. Only the last part of the IP address is entered at the beginningof the line missing the last‘.’ . Now, if the zone is appended to this and the.in-addr.arpa is neglected, the entire IP address will be backwards.

A.3 DNS Sample Configuration

In the sample configuration of a name server illustrated here, we will make thefollowing assumptions: Your domain name is world.cosmos, you have a gatewayhost that establishes the Internet connection, and there are two company internalnetworks connected to each other. This host will be our name server and willreceive the name “gateway”. Your network appears as follows:

Network 1 includes the hosts:

• gateway IP 192.168.1.1

• earth IP 192.168.1.2

• mars IP 192.168.1.3

Network 2 includes the hosts:

• gateway IP 192.168.0.1

• sun IP 192.168.0.2

• moon IP 192.168.0.3

The hosts earth and mars are only connected with sun and moon via the gateway,just as all hosts can only access the Internet via gateway.

The following files are necessary for configuring the name server:

named.conf the central configuration file

world.zone the host table

192.168.1.zone for the subnetwork with the hosts earth and mars

192.168.0.zone for the subnetwork with the hosts sun and moon

localhost.zone contains the IP address of the local host

127.0.0.zone loopback

120


root.hint the Internet root servers

The localhost.zone , 127.0.0.zone , and root.hint files are automati-cally created during installation of BIND 8.The file /etc/named.conf must be adjusted as in FileA.3.1.

acl internal { 127.0.0.1; 192.168.1/24; 192.168.0/24; };

options {directory "/var/named";allow-query { internal; };

# forwarders { 10.0.0.1; };# listen-on port 53 {127.0.0.1; 192.168.0.1; 192.168.1.1;};# query-source address * port 53;

cleaning-interval 120;statistics-interval 0;notify no;

};zone "world.cosmos" in {

type master;file "world.zone";

};


};


};

zone "localhost" in {type master;file "localhost.zone";

};


};

zone "." in {type hint;file "root.hint";

};

File A.3.1: File named.conf

acl is the access control list that defines from which IP addresses access can bemade to the DNS server.The directory entry specifies where the other configuration files are located./var/named/ is the default.The process ID ofnamed is stored in thepid-file .listen-on Port defines the port from which the name server receives re-quests.

121


zone entries specify the configuration files to which IP addresses and host namesare assigned to one another. These files must be set up in the next step in the/var/named/ directory.

The complete host table is entered in theworld.zone file (see FileA.3.2). Itconsists of the following.

$TTL 2D

world.cosmos. IN SOA gateway root.world.cosmos (2001040501 ; serial1D ; refresh2H ; retry1W ; expiry2D ) ; minimum

IN NS gatewayIN MX 10 sun

gateway IN A 192.168.0.1IN A 192.168.1.1

sun IN A 192.168.0.2moon IN A 192.168.0.3earth IN A 192.168.1.2mars IN A 192.168.1.3

File A.3.2: The File /var/named/world.zone

The option ‘$TTL’ specifies the “time to live”. ‘SOA’ stands for “start of au-thority” and introduces the preset record: host name, e-mail address with‘@’substituted by a‘.’ , serial number (date and double-digit version number), andTTL. ‘ NS’ marks the name server. ‘A’ signals that the IP addresses of the hostswill follow in the domain. The name server “gateway” has two IP addresses,because it belongs to two subnetworks.

In the next two zone files, the reverse lookup takes place for both subnetworks.See the sample filesA.3.3on the next page andA.3.4on the facing page.

Now, before you can test your name server, the entry in the/etc/rc.configfile must be set toSTART_NAMED=yes. Subsequently, the other hosts can beinformed of the IP address of the name server as well, for example, viaYaST(‘System administration ’ → ‘Configure network ’ → ‘Configurationname server ’).

Now, if you enternslookup earth in a console, you should see an output ofthe name server with IP address as well as the IP address of the host earth. If thename server is not functioning, find the cause in the/var/log/messages file.

122


$TTL 2D

0.168.192.in-addr.arpa. IN SOA gateway.world.cosmos.root.world.cosmos. (

2001040501 ; serial1D ; refresh2H ; retry1W ; expiry2D ) ; minimum

IN NS gateway.world.cosmos.

1 IN PTR gateway.world.cosmos.2 IN PTR sun.world.cosmos.3 IN PTR moon.world.cosmos.

File A.3.3: The File 192.168.0.zone

$TTL 2D1.168.192.in-addr.arpa. IN SOA gateway.world.cosmos.

root.world.cosmos. (2001040501 ; serial1D ; refresh2H ; retry1W ; expiry2D ) ; minimum

IN NS gateway.world.cosmos.

1 IN PTR gateway.world.cosmos.2 IN PTR earth.world.cosmos.3 IN PTR mars.world.cosmos.

File A.3.4: The File 192.168.1.zone

123


A.3.1 For More Information

• Documentation on packagebind8 :/usr/share/doc/packages/bind8/html/index.html .

• A sample configuration can be found at:/usr/share/doc/packages/bind8/sample-config

• the man page fornamed (man 8 named), in which the relevant RFCs arenamed along with the the man page fornamed.conf (man 5 named.conf )in particular.

124

B Proxy Server: Squid


The following chapter describes how caching web sites assisted by a proxy serverworks and what the advantages of usingSquid are. The most popular proxycache for Linux and UNIX platforms isSquid. We will discuss its configuration,the specifications required to get it running, how to configure the system to dotransparent proxying, how to gather statistics about the cache’s use with the helpof programs likeCalamaris andcachemgr, and how to filter web contents withsquidgrd.

B.1 What is a Proxy Cache?

Squid acts as a proxy cache. It behaves like an agent that receives requestsfrom clients, in this case web browsers, and passes them to the specified serverprovider. When the requested objects arrive at the agent, it stores a copy in a diskcache.

Benefits arise when different clients request the same objects: these will beserved directly from the disk cache, much faster than obtaining them from theInternet, and, at the same time, saving overall bandwidth for the system.

� �

�

TipSquid covers a wide range of features, including intercommunicating hierar-chies of proxy servers to divide the load, defining strict access control liststo all clients willing to access the proxy, and, with the help of other applica-tions, allowing or denying access to specific web pages. It also can obtainstatistics about the most visited web sites, user usage of the Internet, andothers.

Squid is not a generic proxy. It proxies normally only between HTTP connec-tions. It does also support the protocols FTP, Gopher, SSL, and WAIS, but itdoes not support other Internet protocols such as Real Audio, news, or video-conferencing. BecauseSquid only supports the UDP protocol to provide com-munication between different caches, many other multimedia programs will notbe supported.

125


B.2 Some Facts About Cache Proxying

B.2.1 Squid and Security

It is also possible to useSquid together with a firewall to secure internal networksfrom the outside using a proxy cache. The firewall denies all external servicesexcept forSquid, forcing all World Wide Web connections to be established bythe proxy.

If it is a firewall configuration including a DMZ, set the proxy there. In this case,it is important that all computers in the DMZ send their log files to hosts insidethe secured network.

One way to implement this feature is with the aid of a “transparent” proxy. Itwill be covered in SectionB.6 on page134.

B.2.2 Multiple Caches

“Multiple caches” means configuring different caches so that objects can be ex-changed between them, reducing the total system load as well as increasing thechances of finding an object already in the local network. It enables the configu-ration of cache hierarchies so a cache is able to forward object requests to siblingcaches or to a parent cache. It can get objects from another cache in the localnetwork or directly from the source.

Choosing the appropriate topology for the cache hierarchy is very important, be-cause it should not increase the overall traffic on the network. For example, ina very large network, it is possible to configure a proxy server for every subnet-work and connect it to a parent proxy, connected in its turn to the proxy cachefrom the ISP.

All this communication is handled by ICP (Internet Cache Protocol) runningon top of the UDP protocol. Data transfers between caches are handled usingHTTP (Hyper Text Transmission Protocol) based on TCP, but for these kindsof connections, it is preferable to use faster and simpler protocols capable ofreacting to incoming requests within a maximum of one or two seconds.

To find the most appropriate server from which to get the objects, one cachesends an ICP request to all sibling proxies. These will answer the requests viaICP responses with a HIT code if the object was detected or a MISS if it was not.If multiple HIT responses were found, the proxy server will decide which serverto download depending on factors such as which cache sent the fastest answer orwhich one is closer. If no satisfactory responses have been sent, the request willbe sent to the parent cache.

� �

�

TipTo avoid duplication of objects in different caches in our network, other ICPprotocols are used such as CARP (Cache Array Routing Protocol) or HTCP(HyperText Cache Protocol). The more objects maintained in the network,the greater the chances of finding the one we want.

126

B.3 System Requirements

B.2.3 Caching Internet Objects

Not all objects available in the network are static. There are a lot of dynamicallygenerated CGI pages, visitor counters, or encrypted SSL content documents.This is the reason not to cache any object like this: every time you access one ofthis objects, it will already have changed again.

The question remains as to how long all the other objects stored in the cacheshould stay there. To determine this, all objects in the cache are assigned threedifferent states:

1. FRESH: When this object is requested, it is sent without comparing it to thethe original object on the web to see if it has changed.

2. NORMAL: The original server is queried to see if the object has changed.If it changed, the cache copy is updated.

3. STALE: The object is no longer considered valid and will be downloadedagain from the server.

Web and proxy servers find out the status of an object by adding headers to theseobjects such as “Last modified” or “Expires” and the corresponding date. Otherheaders specifying that objects must not be cached are used as well.

Objects in the cache are normally replaced, due to a lack of free hard disk space,using algorithms such as LRU (Last Recently Used), which serve to replacecache objects. It consists of first replacing the less requested objects.

B.3 System Requirements

The most important thing is to determine the maximum load the system willhave to bear. It is, therefore, important to pay more attention to the load picks,because these might be more than four times the day’s average. When in doubt,it would be better to overestimate the system’s requirements, because havingSquid working close to the limit of its capabilities could lead to a severe loss inthe quality of the service.

B.3.1 Hard Disk

Speed: choosing fast hard disks

Speed plays an important role in the caching process, so should be of utmost con-cern. In hard disks, this parameter is described as “random-seek time”, measuredin milliseconds. As a rule of thumb, the lower this value, the better.

According to theSquid User’s Guide (http://www.squid-cache.org ), for asystem using only one disk, the formula for calculating the number of requestsper second from the seek time of the disks is quite easy:

requests per second = 1000 / seek time

127

http://www.squid-cache.org


Squid enables more disks to be used simultaneously, increasing the number ofrequests per second. For instance, if you have three disks with the same seektime of 12 milliseconds, using the following formula will result in:

requests per second = 1000 / (seek time / number of disks) = 1000 / (12/3) =250 requests per second

In comparison to using IDE or SCSI disks, SCSI is preferable. Newer IDE disks,however, have similar seek times as SCSI and, together with DMA-compatibleIDE controllers, increase the speed of data transfer without considerably increas-ing the system load.

Size of the Disk Cache

It depends on a few factors. In a small cache, the probability of a HIT (findingthe requested object already located there) will be small, because the cache iseasily filled up so the less requested objects will be replaced by newer ones. Onthe other hand, if1 GB is available for the cache and the users only surf10 MBa day, it will take more than 100 days to fill the cache.Probably the easiest way to determine the needed cache size is to consider themaximum transfer rate of our connection. With a1 MB/s connection, the maxi-mum transfer rate will be125 KB/s . If all this traffic ends up in the cache, in onehour it will add up to450 MB and, assuming that all this traffic is generated inonly 8 working hours, it will reach3.6 GB in one day. Because the connectionwas not used up to its maximum capacity (otherwise we would have procureda faster one), we could assume that the total amount of data going through thecache is about2 GB. In the example, to keep all the browsed data ofoneday inthe cache, we will require2 GBof disk space forSquid.Summing up,Squid tends to read and write smaller blocks from or to the disk,making it more important how fast it detects these objects on the disk than havinga fast disk.

B.3.2 RAM

The amount of memory required bySquid directly correlates to the amount ofobjects allocated in the cache.Squid also stores cache object references andfrequently requested objects in memory to speed up the retrieval of this data.The memory is one million times faster than a hard disk. (Compare the seektime of a hard disk, about 10 milliseconds, with the 10 nanoseconds access timeof the newer RAM memories)Every object in RAM memory has a size of72 bytes (for “small” pointer ar-chitectures likeIntel , Sparc , or MIPS. For Alpha, it is104 bytes ). If theaverage size of an object on the Internet is about8 KB and we have1 GBdiskfor the cache, we will be storing about 130,000 objects, resulting in close to10 MBRAM only for meta data.Squid also holds data in memory for lots of other stuff, such as a table with allused IP adresses, a fully qualified domain name cache, hot objects (the mostrequested), buffers, and access control lists.

128

B.4 Starting Squid

It is very important to have more than enough memory for theSquid process,because, if it has to be swapped, the system performance will be dramaticallyreduced. To assist in cache memory management, use the toolcachemgr.cgi, asdiscussed in SectionB.7.1on page135.

B.3.3 CPU

Squid is not a program that requires intensive CPU usage. The load of the proces-sor is only increased while the contents of the cache are being loaded or checked.Using a multiprocessor machine does not increase the performance of the sys-tem. To increase efficiency, it is better to buy faster disks or add more memory.

Some examples of configured systems runningSquid are available athttp://wwwcache.ja.net/servers/squids.html .

B.4 Starting Squid

Squid is already preconfigured in SuSE Linux, so you can start it easily right afterinstallation. A prerequisite for a smooth start is an already configured network,at least one name server and, of course, Internet access. Problems can arise ifa dial-up connection is used with dynamic DNS configuration. In cases such asthis, at least the name server should be entered clearly, becauseSquid will notstart if it does not detect a DNS in the/etc/resolv.conf .

To startSquid, enterrcsquid start at the command line at‘root’ . Forthe initial start-up, the directory structure will first have to be defined in/var/squid/cache . This is done by the start script/etc/init.d/squid automat-ically and can take a few seconds or even minutes. Ifdone appears to the rightin green,Squid has been successfully loaded. TestSquid’s functionality on thelocal system by enteringlocalhost andPort 3128 as proxy in the browser.To allow all users to accessSquid and thus the Internet, change the entry inthe configuration file/etc/squid.conf from http_access deny all tohttp_access allow all . However, in doing so, consider thatSquid is madecompletely accessible to anyone by this action. Therefore, you should, in anycase, define ACLs to control access to the proxy. More on this is available inSectionB.5 on page132.

If you have made changes in the configuration file/etc/squid.conf , instructSquid to load the changed file. Do this by enteringrcsquid reload or restartSquid with rcsquid restart . Also, the commandrcsquid status is im-portant. With it, determine whether the proxy is running. Withrcsquid stop ,halt Squid. The latter can take a while, sinceSquid waits up to half a minute(shutdown_lifetime ) before dropping the connections to the clients then willwrite its data to the disk. IfSquid is halted withkill or killall , this canlead to the destruction of the cache, which will then have to be fully removed torestartSquid.

If Squid dies after a short period of time, although it has seemingly been startedsuccessfully, it can be the result of a faulty name server entry or a missing/etc/

129

http://wwwcache.ja.net/servers/squids.html

http://wwwcache.ja.net/servers/squids.html


resolv.conf file. The cause of the start failure would then be logged bySquidin the /var/squid/logs/cache.log file.

If Squid should be loaded automatically when the system boots, reset the entrySTART_SQUID=noto START_SQUID=yes in the /etc/rc.config file.

An uninstall ofSquid will neither remove the cache or the log files. Manuallydelete the/var/squid directory.

B.5 The Configuration File /etc/squid.conf

All Squid proxy server settings are made in the/etc/squid.conf file. To startSquid for the first time, no changes will be necessary in this file, but externalclients will initially be denied access. The proxy needs to be made availablefor the localhost , usually with3128 as port. The options are extensive andtherefore provided with ample documentation and examples in the preinstalled/etc/squid.conf file. Nearly all entries begin with a‘# ’ sign (the linesare commented out) and the relevant specifications can be found at the end ofthe file. The given values almost always correlate with the default values, soremoving the comment signs without changing any of the parameters actuallyhas little effect in most cases. It is better to leave the sample as it is and reinsertthe options along with the modified parameters in the line below. In this way,easily interpret the default values and the changes.

If you have updated an earlierSquid version, it is recommended to edit the new/etc/squid.conf and only apply the changes made in the previous file. Ifyou try to implement the oldsquid.conf again, you are running a risk that theconfiguration will no longer function, because options are always being modifiedand new changes added.

General Configuration Options

http_port 3128 This is the port whereSquid listens for client requests. Thedefault port is3128 , but8080 is also common. You have the option here ofspecifying several port numbers separated by blank spaces.

cache_peer <hostname> <type> <proxy-port> <icp-port> Here, you can en-ter a parent proxy as “parent”, for example, or use that of the provider. As<hostname> , the name and IP address of the proxy to use are entered and,as<type> , parent . For <proxy-port> , the port number is to be enteredwhich is also specified by the operator of the parent for use in the browser,usually8080 . Set the<icp-port> to 7 or 0 if the ICP port of the parent isnot known and its use is irrelevant to the provider. In addition,default andno-query should be specified after the port numbers to strictly prohibit theuse of the ICP protocol.Squid will then behave like a normal browser as faras the provider’s proxy is concerned.

cache_mem 8 MB This entry defines the maximim amount of disk spaceSquidcan use for the caches. The default is8 MB.

130

B.5 The Configuration File/etc/squid.conf

cache_dir ufs /var/squid/cache 100 16 256 The entrycache_dir defines thedirectory where all the objects are stored on disk. The numbers at the endindicate the maximum disk space inMBto use, as well as the number of direc-tories in the first and second level. Theufs parameter should be left alone.The default is100 MB occupied disk space in the/var/squid/cache di-rectory and to create 16 subdirectories inside it which each contain 256 moresubdirectories. When specifying the disk space to use, always leave suffi-cient reserve disk space. Values from a minimum of fifty to a maximum ofeighty percent of the available disk space make the most sense here. Thelast two numbers for the directories should only be increased with caution,because too many directories can also lead to performance problems. If youhave several disks that share the cache, enter severalcache_dir lines.

cache_access_log /var/squid/logs/access.log path for log message

cache_log /var/squid/logs/cache.log path for log message

cache_store_log /var/squid/logs/store.log path for log messageThese three entries specify the path whereSquid will log all of its actions.Normally, nothing is changed here. IfSquid is experiencing a heavy usageburden, it might make sense to distribute the cache and log files over severaldisks.

emulate_httpd_log off If the entry is set toon, obtain readable log files. Someevaluation programs cannot interpret this, however.

client_netmask 255.255.255.255 With this entry, mask the logged IP addressesin the log files to hide the clients’ identity. The last digit of the IP addresswill be set to zero if you enter255.255.255.0 here.

ftp_user Squid@ With this, set the password whichSquid should use for theanonymous FTP login. The login‘anonymous’ and your e-mail address aspassword are generally used to access public FTP servers, which saves thetrouble of entering your user name and password each time you downloadFTP.Squid@ without the domain is the default, because the clients can orig-inate from any domain. It can still make sense, however, to specify a valide-mail address here, because some FTP servers can check these for validity.

cache_mgr webmaster An e-mail address to whichSquid sends a message ifit unexpectedly crashes. The default iswebmaster .

logfile_rotate 0 If you call up squid -k rotate , Squid can rotate securedlog files. The files will be enumerated in this process and after reaching thespecified value, the oldest file at that point will be overwritten. This valuehere normally is0, because archiving and deleting log files in SuSE Linuxis carried out by a cronjob in the configuration file/etc/logfiles . Theperiod of time after which the files are deleted is defined in the/etc/rc.config file via theMAX_DAYS_FOR_LOG_FILESentry.

append_domain <domain> With append_domain , specify which domain willautomatically be appended when none is given. Usually, your own domain isentered here, so enteringwwwin the browser suffices to guarantee access toyour own web server.

131


forwarded_for on If you set the entry tooff , Squid will remove the IP addressand the system name of the client from the HTTP requests.

negative_ttl 5 minutes; negative_dns_ttl 5 minutesNormally, you do not need to change these values. If you have a dial-upconnection, however, the Internet may, at times, not be accessible.Squid willmake a note of the failed requests then refuse to issue new ones, although theInternet connection has been reestablished. In a case such as this, changetheminutes to seconds then, after clicking onReload in the browser, thedial-up process should be reengaged after a few seconds.

never_direct allow <acl_name> To preventSquid from taking requests directlyfrom the Internet, use this command to force connection to another proxy.You need to have previously entered this incache_peer . If all is specifiedas the<acl_name> , force all requests to be forwarded directly to thepar-ent . This might be necessary, for example, if you are using a provider whichstrictly stipulates the use of its proxies or denies its firewall direct Internetaccess.

Options for Access Controls

Squid provides an intelligent system that controls access to the proxy. By imple-menting ACLs, it can be configured easily and comprehensively. This involveslists with rules processed sequentially. ACLs must be defined before they canbe used. Some default ACLs, such asall andlocalhost , already exist. Afterdefining an ACL, implement it, for example, in conjunction withhttp_access .

acl <acl_name> <type> <data> An ACL requires at least three specificationsto define it. The name<acl_name> can be arbitrarily chosen. For<type> ,select from a variety of different options in theACCESS CONTROLSsectionin the/etc/squid.conf file. The specification for<data> depends on theindividual ACL type and can also be read from a file, for example, via hostnames, IP addresses, or URLs. In the following are some simple examples:

acl mysurfers srcdomain .my-domain.comacl teachers src 192.168.1.0/255.255.255.0acl students src 192.168.7.0-192.168.9.0/255.255.255.0acl lunch time MTWHF 12:00-15:00

http_access allow <acl_name> http_access defines who is allowed to usethe proxy and also who can access what on the Internet. For this, ACLsmust be given.localhost andall have already been defined above, whichcan deny or allow access viadeny or allow . A list containing any numberof http_access entries can be created. They will be processed from topto bottom and, depending on which occurs first, access will be allowed ordenied to the respective URL. The last entry should always behttp_accessdeny all . In the following example, thelocalhost has free access toeverything while all other hosts are denied access completely.

http_access allow localhosthttp_access deny all

132

B.5 The Configuration File/etc/squid.conf

Another example, where the previously defined ACLs are used: The group‘teachers’ always has access to the Internet, while the group‘students’only gets access Monday to Friday during lunch time.

http_access deny localhosthttp_access allow teachershttp_access allow students lunch timehttp_access deny all

The list with thehttp_access entries should only be entered, for the sakeof readability, at the designated position in the/etc/squid.conf file —between the text

\# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

and the last

http_access deny all

redirect_program /usr/bin/squidGuard With this option, a redirector, such asSquidGuard, which is able to block unwanted URLs, can be specified. In-ternet access can be individually controlled for various user groups with thehelp of proxy authentication and the appropriate ACLs.SquidGuard is apackage in and of itself which can be separately installed and configured.

authenticate_program /usr/sbin/pam_auth If users must be authenticated onthe proxy, a corresponding program, such aspam_auth, can be specifiedhere. When accessingpam_auth for the first time, the user will see a loginwindow where the user name and password must be entered. In addition, anACL is still required so only clients with a valid login can surf the Internet:

acl password proxy_auth REQUIRED

http_access allow passwordhttp_access deny all

The REQUIREDafter proxy_auth can be replaced with a list of permitteduser names or with the path to such a list.

ident_lookup_access allow <acl_name> With this, you will manage to havean ident request run through for all ACL-defined clients to find out eachuser’s identity. If you applyall to the<acl_name> , this will be valid forall clients. Also, an ident daemon must be running on all clients. For Linux,install thepidentd package for this purpose. ForWindows , there is free soft-ware available to download from the Internet. To ensure that only clientswith a successful ident lookup are permitted, a corresponding ACL will alsohave to be defined here:

acl identhosts ident REQUIRED

http_access allow identhostshttp_access deny all

Here, too, replace theREQUIREDwith a list of permitted user names. Usingident can slow down the access time quite a bit, because ident lookups willdefinitely be repeated for each request.

133


B.6 Transparent Proxy Configuration

The usual way of working with proxy servers is the following: the web browsersends requests to a certain port in the proxy server and the proxy provides theserequired objects, whether they are in its cache or not. When working in a realnetwork, several situations may arise:

• For security reasons, it is recommended that all clients use a proxy to surfthe Internet.

• All clients must use a proxy whether they are aware of it or not.

• In larger networks already using a proxy, it is possible to spare yourself thetrouble of reconfiguring each machine whenever changes are made in thesystem.

In all these cases, a transparent proxy may be used. The principle is very easy:the proxy intercepts and answers the requests of the web browser, so that the webbrowser receives the requested pages without knowing where they are comingfrom. This entire process is done transparently, hence the name.

B.6.1 Kernel Configuration

First, make sure that the proxy server’s kernel has support for transparent proxies.Otherwise, add this option to the kernel and compile it again. More on this topicis available in theSuSE Linux Reference Manual.

In the entry corresponding to Networking Options, select ‘Network Firewalls ’then the options ‘IP: firewalling ’ and ‘IP: Transparent proxying ’.Now, save the new configuration, compile the new kernel, install it, reconfig-ure LILO if necessary, and restart the system.

B.6.2 Configuration Options in /etc/squid.conf

The options that need to be activated in the/etc/squid.conf file to get thetransparent proxy up and running are:

• httpd_accel_host virtual

• httpd_accel_port port 80, where the actual HTTP server listens

• httpd_accel_with_proxy on

• httpd_accel_uses_host_header on

The default configuration as defined by the file/etc/squid.conf gives accessto the proxy only fromlocalhost . Therefore, it may be necessary to defineadditional access rules. See SectionB.5 on page132.

134

B.7 Squid and Other Programs


In the following section, we will see how other applications interact withSquid.cachemgr.cgi enables the system administrator to check the amount of mem-ory needed for caching objects,squidgrd filters web pages, andCalamaris is areport generator forSquid.

B.7.1 cachemgr.cgi

The cache manager (cachemgr.cgi) is a CGI utility for displaying statistics aboutthe memory usage of a runningSquid process. It is also a more convenient wayto manage the cache and view statistics without logging the server.

Setup

First, we need a running web server on our system. To check ifApache is alreadyrunning, type, as‘root’ , rcapache status .

If a message like this appears:

Checking for service httpd: OKServer uptime: 1 day 18 hours 29 minutes 39 seconds

Apache is running on our machine. Otherwise, typercapache start to startApache with the SuSE Linux default settings. The last step to set it up is to copythe filecachemgr.cgi to the Apache directorycgi-bin :cp /usr/share/doc/packages/squid/scripts/cachemgr.cgi /var/www/cgi-bin

Cache Manager ACLs in /etc/squid.conf

There are some default settings in the original file required for the cache man-ager:

acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255

With the following rules:

http_access allow manager localhosthttp_access deny manager

The first ACL is the most important, as the cache manager tries to communicatewith Squid over the cache_object protocol.

The following rules assume that the web server andSquid are running on thesame machine. If the communication between the cache manager andSquidoriginates at the web server on another computer, include an extra ACL as inFile B.7.1on the next page.

Then add the rules as in FileB.7.2on the following page.

135


acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl webserver src 192.168.1.7/255.255.255.255 # IP of webserver

File B.7.1: Adding Extra ACLs

http_access allow manager localhosthttp_access allow manager webserverhttp_access deny manager

File B.7.2: Access Rules

We can also configure a password for the manager, if we want to have access tomore options like closing the cache remotely or viewing more information aboutthe cache. Then configure the entrycachemgr_passwd with a password for themanager and the list of options to view. This list appears as a part of the entrycomments in/etc/squid.conf .

Remember to restartSquid with the commandrcsquid reload every time theconfiguration file is changed.

Viewing the Statistics

Go to the corresponding web site:http://webserver.example.org/cgi-bin/cachemgr.cgi

Press ‘continue ’ and browse through the different statistics. More details oneach entry shown by the cache manager is in theSquid FAQ at http://www.squid-cache.org/Doc/FAQ/FAQ-9.html

B.7.2 SquidGuard

This section is not intended to go through an extensive configuration ofSquid-Guard, only to introduce it and give some advice on using it. For more in-depth configuration issues, refer to theSquidGuard web site athttp://www.squidguard.org

SquidGuard is a free (GPL), flexible, and ultra fast filter, redirector, and “accesscontroller plugin” forSquid. It lets you define multiple access rules with dif-ferent restrictions for different user groups on aSquid cache.SquidGuard usesSquid’s standard redirector interface.

SquidGuard can be used for the following:

• limit the web access for some users to a list of accepted or well known webservers or URLs.

• block access to some listed or blacklisted web servers or URLs for someusers.

• block access to URLs matching a list of regular expressions or words forsome users.

136

http://webserver.example.org/cgi-bin/cachemgr.cgi

http://www.squid-cache.org/Doc/FAQ/FAQ-9.html

http://www.squid-cache.org/Doc/FAQ/FAQ-9.html

http://www.squidguard.org

http://www.squidguard.org


• redirect blocked URLs to an “intelligent” CGI-based info page.

• redirect unregistered users to a registration form.

• redirect banners to an empty GIF.

• have different access rules based on time of day, day of the week, date, etc.

• have different rules for different user groups.

• and much more

Neither SquidGuard orSquid can be used to:

• Edit, filter, or censor text inside documents

• Edit, filter, or censor HTML-embedded script languages such as JavaScriptor VBscript

Using SquidGuard

Install the packagesquidgrd from the seriesn. Edit a minimal configurationfile /etc/squidguard.conf . There are plenty of configuration examples inhttp://www.squidguard.org/config/ . Experiment later with more com-plicated configuration settings.

The following step is to create a dummy “access denied” page or a more or lessintelligent CGI page to redirectSquid in case the client requests a blacklistedweb site. Again, usingApache is strongly recommended.

Now, tell Squid to use SquidGuard. Use the following entries in the/etc/squid.conf file:

redirect_program /usr/bin/squidGuard

There is another option calledredirect_children configuring how many dif-ferent “redirect” (in this caseSquidGuard) processes are running on the machine.SquidGuard is fast enough to cope with lots of requests (SquidGuard is quitefast: 100,000 requests within 10 seconds on a 500MHz Pentium with 5900 do-mains, 7880 URLs, 13780 in sum). Therefore, it is not recommended to set morethan 5 processes, because this may lead to an unnecesary increase of memory forthe allocation of these processes.

redirect_children 5

Last of all, send a HUP signal toSquid to have it read the new configuration:

rcsquid reload

Test your settings with a browser.

B.7.3 Cache Report Generation with Calamaris

Calamaris is a Perl script used to generate reports of cache activity in ASCII orHTML format. It works with nativeSquid access log files. The Calamaris HomePage is located athttp://Calamaris.Cord.de/

137

http://www.squidguard.org/config/

http://Calamaris.Cord.de/


The use of the program is quite easy. Log in as‘root’ , then:cat access.log.files | calamaris [options] > reportfile

It is important when piping more than one log file that the log files are chrono-logically ordered, with older files first.

The various options:

-a normally used for the output of available reports

-w an HTML report

-l a message or logo in the header of the report

Further information on the various options can be found in the manual pageman calamaris .

A typical example:cat access.log.2 access.log.1 access.log | calamaris -a -w >/usr/local/httpd/htdocs/Squid/squidreport.html

We place the report in the directory of the web server. Again,Apache is requiredto view the reports.

Another powerful cache report generator tool is SARG (Squid Analysis ReportGenerator), included in seriesn. Further information on this can be found in therelevant Internet pages athttp://web.onda.com.br/orso/

B.8 More Information on Squid

Visit the home page ofSquid: http://www.squid-cache.org/ . Here, findtheSquid User Guide and a very extensive collection of FAQs onSquid.

The Mini-Howto regarding transparent proxies in the packagehowtoen , under/usr/share/doc/howto/en/mini/TransparentProxy.gz

In addition, mailing lists are available forSquid at:[email protected] .

The archive for this is located at:http://www.squid-cache.org/mail-archive/squid-users/

138

http://web.onda.com.br/orso/

http://www.squid-cache.org/

[email protected]

http://www.squid-cache.org/mail-archive/squid-users/

C Network Security

C Network Security

C.1 SSH — Secure Shell, the Safe Alternative

In these times of increasing networks, accessing a remote system also becomesmore common. Whether e-mail is collected, a server maintained, or an articleadded to a web site of an editorial system, the person carrying out such actionswill always have to be authenticated.

Most users should know by now that the user name and password is only in-tended for individual use. Strict confidence pertaining to personal data is usuallyguaranteed between the employer, computer center, or service provider.

However, the ongoing practice of authenticating and transferring data in cleartext form is a frightening phenomenon. Most directly affected are the commonlyused servicesPost Office Protocol (POP) for retrieving mail andtelnetfor logging in on remote systems. Using these methods, user information anddata considered sensitive, such as the contents of a letter or a chat via the talkcommand, travel openly and unsecured over the network. This encroaches on theuser’s privacy and leaves such access methods open to misuse. Usually, this mis-use occurs by accessing one system to attack another or to obtain administratoror root permissions.

Any device involved in data transfer or operating on the local network, such asfirewall, router, switch, mail servers, or workstations, can also access the data.There are laws prohibiting such behavior, but it is difficult to detect.

TheSSH software provides the necessary protection. Complete authentication,usually user name and password, as well as the communication is encrypted.Even here, snatching the transferred data is possible, but the contents can at leastnot be deciphered by intruders without the key. This enables secure communi-cation via unsafe networks, such as the Internet. In SuSE Linux, the packageOpenSSH is available in thesec series.

C.1.1 The OpenSSH Package

As soon as you have installed theOpenSSH package, the following programswill be available:ssh, scp, andsftp, as alternatives totelnet, rlogin, rsh, rcp, andftp.

C.1.2 The ssh Program

Using thessh program, it is possible to log in to remote systems and work inter-actively there. It substitutes bothtelnet andrlogin. Due to its similarity torlogin,

139

C Network Security

the symbolic nameslogin points tossh. For example, log in to the hostsun byentering

hannah@earth:~> ssh sun

Then you are prompted for your password on thesun system:

hannah@sun password:

Following successful authentication, work from the command line there or useinteractive applications, like the SuSE administration tool YaST. If the local username is different from the remote user name, log in using a different login namewith

hannah@earth:~> ssh -l augustine sun

or

hannah@earth:~> ssh augustine@sun

Furthermore,ssh offers the option of running commands on another system, asdoesrsh. In the following example, we will run the commanduptime on thehostsun and create a directory with the nametmp . The program output will bedisplayed on the local terminal of the hostearth .

hannah@earth:~> ssh sun ’uptime; mkdir tmp’hannah@sun password:

1:21am up 2:17, 9 users, load average: 0.15, 0.04, 0.02

Apostrophes are necessary here to send both instructions with one command.

C.1.3 scp — Secure Copy

scp copies files to a remote machine. It is the secure and encoded substitute forrcp. For example,

hannah@earth:~> scp MyLetter.tex sun:

copies the fileMyLetter.tex from the machineearth to the machinesun . Togive a different user names, resort to theusername@machine format alreadymentioned. A-l option does not exist here.

After the correct password is typed in,scp starts the data transfer and shows aseries of stars, gradually marking the progress from left to right. In addition, theestimated time of arrival will be shown in the right margin. All output can besuppressed by giving the option-q .

scp also provides a recursive copying feature for entire directories.

hannah@earth:~> scp -r src/ sun:backup/

copies the entire contents of the directorysrc/ including all subdirectories tothe machinesun in the subdirectorybackup/ . If this subdirectory does notexist yet, it will automatically be created.

Via the option-p , scp leaves the time stamp of the files unchanged.-C com-presses the data transfer. This minimizes the data volume to be transferred, butcreates heavier burden on the processor.

140

C.1 SSH — Secure Shell, the SafeAlternative

C.1.4 sftp — Secure File Transfer

Instead ofscp, sftp can be used for secure file transfer. During the session,sftpprovides many of the commands used byftp. This may be an advantage over scp,especially when transferring data for which the file names are unknown.

C.1.5 The SSH Daemon (sshd) — Server-Side

To work with theSSH client programsssh and scp, a server, theSSH dae-mon, must be running in the background. This waits for its connections onTCP/IP port 22 .

The SSH daemon is a component of theSSH package and is automaticallystarted on a SuSE Linux system inrunlevel 3 and5. The variableSTART_SSHDis set toyes in /etc/rc.config .

The daemon generates two key pairs when starting for the first time. The keypairs consist of a private and a public key. Therefore, this procedure is referredto as public key–based. To guarantee the security of the communication viaSSH,only the system administrator can see the private key files. The file permissionsare restrictively defined by the default setting. The private keys are only requiredlocally by theSSH daemon and must not be given to anyone else. On the otherhand, the public key components (recognizable by the name extension.pub ) aresent to the communication partner and are readable for all users.

A connection is initiated by theSSH client. The waitingSSH daemon and therequestingSSH client exchange identification data comparing the protocol andsoftware versions and preventing connection to the wrong port. Since a childprocess of the originalSSH daemon replies to the request, severalSSH connec-tions can be made simultaneously.

The server will then send its publichost key and aserver key , regeneratedby theSSH daemon every hour. Both allow theSSH client to encrypt a freelychosen session key then send it to theSSH server. TheSSH client also tells theserver which encryption method (cipher) to use.

The private host and server keys absolutely necessary for decoding the ses-sion key cannot be derived from the public parts. Only theSSH daemon con-tacted can decipher the session key using its propietary keys (see also/usr/share/doc/packages/openssh/RFC.nroff ). This initial connection phasecan be watched closely by using theSSH client program’s error search option-v . It will end with the confirmation output of theSSH daemon, “Received en-crypted confirmation.”. By storing all public host keys after initial contact in~/.ssh/known_hosts on the client’s side, so-called “man-in-the-middle” ac-cess attempts can be prevented.SSH servers that try to fraudulently use namesand IP addresses of others will be exposed by a clear indicator. They will eitherbe noticed due to a wrong host key which differs from~/.ssh/known_hostsor they cannot decipher the session key in the absence of an appropriate privatecounterpart.

It is recommended to securely archive the private and public keys stored in/etc/ssh/ externally. In this way, key modifications can be detected and the

141

C Network Security

old ones can be used again after a new installation. This spares users the unset-tling warning. If it is verified that, despite the warning, it is indeed the correctSSH server, the existing entry regarding this system will have to be removedfrom ~/.ssh/known_hosts .

C.1.6 SSH Authentication Mechanisms

Now, the actual authentication will take place, which, in its simplest form, con-sists of entering a password as mentioned above. The goal ofSSH was to in-troduce a secure software that is also easy to use. As it is meant to replacershandrlogin programs,SSH must also be able to provide an authentication methodgood for daily use.SSH accomplishes this by way of another key pair generatedby the user. TheSSH package also provides a help program,ssh-keygen, forthis. After enteringhannah@sun:~> ssh-keygenGenerating RSA keys:

the key pair will be generated and you will be prompted for the base file name inwhich to store the keys:Enter file in which to save the key (/home/hannah/.ssh/identity):

Confirm the default setting and answer the request for a passphrase:Enter passphrase (empty for no passphrase):

Even if the software suggests an empty passphrase, a text from ten to thirtycharacters is recommended for the procedure described here. Do not use shortand simple words or phrases. After you have entered it, you will be promptedto confirm by repeating the passphrase. Subsequently, you will see where theprivate and public keys are stored, in our example, the filesidentity andidentity.pub .Enter same passphrase again:Your identification has been saved in /home/hannah/.ssh/identity.Your public key has been saved in /home/hannah/.ssh/identity.pub.The key fingerprint is:79:c1:79:b2:e1:c8:20:c1:89:0f:99:94:a8:4e:da:e8 hannah@sunWhen the private key (identity) is generated and located on a system you arenot administering or when retrieving your user directory over NFS, it is espe-cially important to use a passphrase. Usessh-keygen -p to change your oldpassphrase.

Copy the public key component (identity.pub) to the remote machine and save itthere at the location~/.ssh/authorized_keys . You will be asked to authen-ticate yourself with your passphrase the next time you establish a connection. Ifthis does not occur, verify the location and contents of these files.

In the long run, this procedure is more troublesome than giving your passwordeach time. Therefore, theSSH package provides another tool, thessh-agent,which retains the private keys for the duration of an X session. The entire Xsession will be started as a child process ofssh-agent. The easiest way to do thisis to set the variableusessh at the beginning of the.xsession file to yes andlog in via a display manager such asKDM or XDM. Alternatively, enterssh-agentstartx.

142

C.1 SSH — Secure Shell, the SafeAlternative

As soon as you have started your X session, enable your private key viassh-add. Unlessssh-add can access a terminal, for example, is started via a menu, agraphical entry screen,x11-ssh-askpass , will appear. Now you can usesshor scp as you normally would. Given that your private key is located as before,you should no longer be prompted for your password. Be sure to exit your Xsession or to lock your screen via a password lock program, such asxlock, whenleaving your machine.

C.1.7 X, Authentication, and Other Forwarding Mechanisms

Beyond the previously described security-related improvements,ssh also sim-plifies the use of remote X applications. If you runssh with the option-X , theDISPLAY variable will automatically be set on the remote machine and all Xoutput will be exported to the remote machine over the existing ssh connection.At the same time, X applications started remotely and locally viewed cannot beobserved by unauthorized persons anymore.

By adding the option-A , thessh-agent authentication mechanism will be car-ried over to the next machine. This way, you can work from different machineswithout having to enter a password, but only if you have distributed your publickey to the destination hosts and properly saved it there.

Both mechanisms are deactivated in the default settings, but can be permanentlyactivated at any time in the system-wide configuration file/etc/ssh/sshd_config or the user’s~/.ssh/config .

As with X forwarding, usessh to redirect TCP/IP connections. In the followingexample, the SMTP and POP3 port is redirected throughssh:

root@earth:~ # ssh -L 25:sun:25 sun

Here, each connection is redirected to “earth port 25”, SMTP to the SMTP portonsun via an encrypted channel. This is especially useful for those using SMTPservers without SMTP-AUTH or POP-before-SMTP features. From any arbi-trary location connected to a network, e-mail can be transferred to the “home”mail server for delivery.

In a similar manner, the following command forwards all port 110 and POP3requests onearth to the POP3 port ofsun

root@earth:~ # ssh -L 110:sun:110 sun

Both examples must be carried out by user‘root’ , because the connection ismade to privileged local ports. E-mail is sent and retrieved by normal users in anexistingSSH connection. The SMTP and POP3 host must be set to localhost forthis.

Additional information can be found in the manual pages for each of the pro-grams described above and also in the files under/usr/share/doc/packages/openssh .

143

C Network Security

C.2 Security and Confidentiality

C.2.1 Basic Considerations

One of the main characteristics of a Linux or UNIX system is its ability to handleseveral users at the same time (multiuser) and to allow these users to performseveral tasks (multitasking) on the same computer simultaneously. Moreover, theoperating system is network transparent. The users often do not know whetherthe data or applications they are using is provided locally from their machine ormade available over the network.

With the multiuser capability the respective data of different users must be storedseparately. Security and privacy need to be guaranteed. “Data security” was al-ready an important issue, even before computers could be linked through net-works. Just like today, the most important concern was the ability to keep dataavailable in spite of a lost or otherwise damaged data medium, a hard disk inmost cases.

This chapter is primarily focused on confidentiality issues and on ways to pro-tect the privacy of users, but it cannot be stressed enough that a comprehensivesecurity concept should always include procedures to have a regularly updated,workable, and tested backup in place. Without this, you could have a very hardtime getting your data back — not only in the case of some hardware defect,but also if the suspicion arises that someone has gained unauthorized access andtampered with files.

C.2.2 Local Security and Network Security

There are several ways of accessing data:

• personal communication with people who have the desired information oraccess to the data on a computer

• directly from the console of a computer (physical access)

• over a serial line

• using a network link

In all these cases, a user should be authenticated before accessing the resourcesor data in question. A web server might be less restrictive in this respect, but youstill would not want it to disclose all your personal data to any surfer out there.On a SuSE system, a few tweaks are sufficient to make it boot right into yourdesktop without even asking for a password, but, in most cases, that would notbe such a good idea, as anybody could change data or run programs.

In the list above, the first case is the one where the highest amount of humaninteraction is involved, such as when you are contacting a bank employee andare required to prove that you are the person owning that bank account. Thenyou will be asked to provide a signature, a PIN, or a password to prove that youare the person you claim to be. In some cases, it might be possible to elicit someintelligence from an informed person just by mentioning known bits and pieces

144


here and there to win the confidence of that person by using clever rhethoric. Thevictim could be led to gradually reveal more information, maybe without evenbecoming aware of it.

Some people are rather unmindful of what they say or act unconsciously in theway they give answers, so that even a question which they believe was left unan-swered might provide enough information to proceed with an even more precisequestion. Piece after piece gets added to the puzzle until the picture is nearlycomplete (“No, Mr. Smith is on vacation right now, it’s at least three weeksbefore he’ll be back in. He’s not my boss anyway, you know he’s up there inthe fourth floor while I’m here in the third!”). Among hackers, this is called“social engineering”. You can only guard against this by educating people andby dealing with language and information in a conscious way. Before breakinginto computer systems, attackers often try to target receptionists, service peopleworking with the company, or even family members and, in many cases, such anattack based on social engineering will only be discovered at a much later time.

A person wanting to obtain unauthorized access to your data could also use thetraditional way and try to get at your hardware directly. Therefore, the machineshould be protected against any tampering so that no one can remove, replace, orcripple its components. This also applies to backups and even any network cableor the power cord. Likewise, it might be necessary to secure the boot procedure,as there are some well-known key combinations which invoke special reactionsduring booting. Protect yourself against this by setting passwords for the BIOSand the bootloader.

Serial terminals connected to serial ports are still used in many places, but arerarely installed with new systems anymore. With regard to data access, serialterminals are a special case. Unlike network interfaces, they do not rely on anetwork protocol to communicate with the host. A simple cable, or maybe aninfrared port, is used to send plain characters back and forth between the devices.The cable itself is the weakest point of such a system: with an older printerconnected to it, it is really easy to record anything that runs over the wires. Whatcan be achieved with a printer can also be accomplished in other ways, dependingon the effort that goes into the attack.

Networks make it easier for us to access data remotely, but they do this withthe help of network protocols which are often rather complex. This might seemparadoxical at first, but is really indispensable if you want to remotely control acomputer or to retrieve data from it no matter where you are. It is necessary tohave abstract, modular designs with layers that are more or less separate fromeach other. We rely on such modular designs in many daily computing situa-tions. Modularity means that your text processor, for example, does not needto know about the kind of hard disk you use or your e-mail program should notbe concerned with whether you have a modem or an ethernet card. Componentsof your operating system, Linux in this case, provide the necessary functionsand make these available to the system through a predefined interface. With thismodularity, a text processor or a mail user agent (MUA) can function on a varietyof hardware platforms and you can run them from some place in the world withthe necessary equipment.

145

C Network Security

Regarding the data, there is no difference between opening a file from a com-mand line or looking at it with a web browser. The file could also be read via anetwork (using a telnet program or with a secure shell client — which is actuallya much better option as ssh encrypts all network traffic). To do so, the host andthe network need to be connected and the user needs to log in and authenticate.The possible actions are still restricted, however, by the file permissions.

Reading a file locally on a host requires other access rules than opening a networkconnection with a server on a different host. There is a distinction between localsecurity and network security. The line is drawn where data has to be put intopackets to be sent somewhere else.

Local Security

Local security starts with the physical environment in the location where thecomputer is running. Assume that your machine is set up in a place where secu-rity is in line with your expectations and needs.

The main goal of “local security” is to keep users separate from each other, sothat no user can assume the permissions or the identity of another one. This isa general rule to be observed, but it is especially true for the user‘root’ whoholds the supreme power on the system. User‘root’ can take on the identityof any other local user without being prompted for the password and read anylocally stored file.

For an attacker who has obtained access to local resources from the commandline, there is certainly no shortage of things that could be done to compromisethe system.

Passwords

On a Linux system, passwords are, of course,not stored as plain text and thetext string entered is not simply matched with the saved pattern. If this were thecase, all accounts on your system would be compromised as soon as someonegot access to the corresponding file. Instead, the stored password is encryptedand, each time it is entered, is encrypted again and the two encrypted stringsare compared. Naturally, this will only work if the encrypted password cannotbe reverse-computed into the original text string. This is actually achieved bya special kind of algorithm, also called “trapdoor algorithm,” because it onlyworks in one direction. An attacker who has obtained the encrypted string willnot be able to get your password by simply applying the same algorithm again.Instead, it would be necessary to test all the possible character combinations untila combination is found which looks like your password when encrypted. As youcan imagine, with passwords that are eight characters long, there are quite anumber of possible combinations to calculate.

In the seventies, it was argued that this method would be more secure than othersdue to the relative slowness of the algorithm used, which took a few seconds toencrypt just one password. In the meantime, however, PCs have become power-ful enough to do several hundred thousand or even millions of encryptions per

146


second. Because of this, encrypted passwords should not be visible to regularusers (/etc/shadow cannot be read by normal users). It is even more importantthat passwords are not easy to guess, in case the password file becomes visibledue to some error. Consequently, it is not really useful to “translate” a passwordlike “tantalise” into “t@nt@1ls3”.

Replacing some letters of a word with similar looking numbers is not safe enough.Password cracking programs which use dictionaries to guess words also playwith substitutions like that. A better way is to make up a word with no com-mon meaning, something which only makes sense to you personally, like thefirst letters of the words of a sentence or the title of a book, such as “The Nameof the Rose” by Umberto Eco. This would give the following safe password:“TNotRbUE9”. By contrast, passwords like “beerbuddy” or “jasmine76” areeasily guessed even by someone who has only some casual knowledge aboutyou.

The Boot Procedure

Configure your system so it cannot be booted from a floppy or from CD, eitherby removing the drives entirely or by setting a BIOS password and configuringthe BIOS to allow booting from a hard disk only.

Normally, a Linux system will be started by a boot loader, allowing you to passadditional options to the booted kernel. This is crucial to your system’s secu-rity. Not only does the kernel itself run with root permissions, but it is also thefirst authority to grant root permissions at system start-up. Prevent others fromusing such parameters during boot by using the options “restricted” and “pass-word=your_own_password” in/etc/lilo.conf . Execute the commandliloafter making any changes to/etc/lilo.conf and look for any unusual outputthe command might produce. If you forget this password, you will have to knowthe BIOS password and boot from CD to read the entry in/etc/lilo.conffrom a rescue system.

File Permissions

As a general rule, always work with the most restrictive privileges possible fora given task. For example, it is definitely not necessary to be‘root’ to read orwrite e-mail. If the mail program you use has a bug, this bug could be exploitedfor an attack which will act with exactly the permissions of the program when itwas started. By following the above rule, minimize the possible damage.

The permissions of the more than 200,000 files included in a SuSE distributionare carefully chosen. A system administrator who installs additional softwareor other files should take great care when doing so, especially when setting thepermission bits. Experienced and security-conscious system administrators al-ways use the-l option with the commandls to get an extensive file list, whichallows them to detect any wrong file permissions immediately. An incorrect fileattribute does not only mean that files could be changed or deleted. These modi-fied files could be executed by‘root’ or, in the case of configuration files, thatprograms could use such files with the permissions of‘root’ . This significantly

147

C Network Security

increases the possibilities of an attacker. Attacks like this are called cuckoo eggs,because the program (the egg) is executed (hatched) by a different user (bird),just like a cuckoo would trick other birds into hatching its eggs.

A SuSE Linux system includes the filespermissions , permissions.easy ,permissions.secure , andpermissions.paranoid , all in the /etc direc-tory. The purpose of these files is to define special permissions, such as world-writable directories or, for files, the setuser ID bits, which means the correspond-ing program will not run with the permissions of the user that has launched it,but with the permissions of the file owner,‘root’ in most cases. An admin-istrator may use the file/etc/permissions.local to add his own settings.The variablePERMISSION_SECURITY, set in/etc/rc.config , defines whichof the above files is used by SuSE’s configuration programs to set permissionsaccordingly. As a more convenient way to select the files, use the submenu ‘Se-curity ’ in YaST or YaST2. To learn more about the topic, read the commentsin /etc/permissions or consult the manual page ofchmod (man chmod).

File Race Conditions

Assume that a program wants to create a file in a directory which is world-writable (such as/tmp ). First, the program checks whether the file alreadyexists and, if that is not the case, creates it. However, between checking andfile creation, there is a short moment which can be used by an attacker to createa symbolic link, a pointer to another file. The program may then be tricked intofollowing the symbolic link, overwriting the target file with its own permissions.This is called a race because the interval during which the attacker can create a“symlink” is very short. The race is only possible if the checking and file cre-ation procedure is not atomic (indivisible). If the race is allowed to take placeat all, there is a chance that it may be won by the attacker. It is all a matter ofprobability.

Buffer Overflows and Format String Bugs

Special care must be taken whenever a program is supposed to process datawhich can or could be changed by a user, but this is more of an issue for theprogrammer of an application than for regular users. The programmer has tomake sure that his application will interpret data in the correct way, withoutwriting them into memory areas that are too small to hold them. Also, the pro-gram should hand over data in a consistent manner, using the interfaces definedfor that purpose.

A “buffer overflow” can happen if the actual size of a memory buffer is not takeninto account when writing to that buffer. There are cases where this data (asgenerated by the user) uses up some more space than what is available in thebuffer. As a result, data is written beyond the end of that buffer area, which, un-der certain circumstances, makes it possible that a program will execute programsequences influenced by the user (and not by the programmer), rather than justprocessing user data. A bug of this kind may have serious consequences, in par-

148


ticular if the program is being executed with special privileges (see SectionC.2.2on page147).“Format string bugs” work in a slightly different way, but again it is the userinput which could lead the program astray. In most cases, these programmingerrors are exploited with programs executed with special permissions — setuidand setgid programs — which also means that you can protect your data and yoursystem from such bugs by removing the corresponding execution privileges fromprograms. Again, the best way is to apply a policy of using the lowest possibleprivileges (see SectionC.2.2on page147).Given that buffer overflows and format string bugs are bugs related to the han-dling of user data, they are not only exploitable if access has been given to a localaccount. Many of the bugs that have been reported can also be exploited overa network link. Accordingly, buffer overflows and format string bugs should beclassified as being relevant for both local and network security.

Viruses

Contrary to what some people will tell you, thereare viruses that run on Linux.However, the viruses that are known were released by their authors as “proof ofconcept”, meaning that they were written to prove that the technique works asintended. On the other hand, none of these viruses have been spotted “in thewild” so far.Viruses would not be able to survive and spread without a host on which theycan live. In our case, the host would be a program or an important storage areaof the system, such as the master boot record, which needs to be writable forthe program code of the virus. Owing to its multiuser capability, Linux canrestrict write access to certain files, which is the case especially with systemfiles. Therefore, if you did your normal work with‘root’ permissions, youwould increase the chance of the system being infected by a virus. By contrast,if you follow the principle of using the lowest possible privileges as mentionedabove, chances of getting a virus are slim. Apart from that, you should neverrush into executing a program from some Internet site that you do not reallyknow. SuSE’s RPM packages carry a cryptographic signature as a digital labelthat the necessary care was taken to build them. Viruses are a typical sign thatthe administrator or the user lacks the required security awareness, putting at riskeven a system that should be highly secure by its very design.Viruses should not be confused with worms which belong to the world of net-works entirely. Worms do not need a host to spread.

Network Security

Local security is concerned with keeping different users on one system apartfrom each other, especially from‘root’ . Network security, on the other hand,means that the system needs to be protected from an attack originating in thenetwork.The typical login procedure requiring a user name and a password for user au-thentication is a local security issue. However, in the particular case of logging

149

C Network Security

in over a network, we need to differentiate between both security aspects. Whathappens until the actual authentication is network security and anything that hap-pens afterwards is local security.

X Window System (X11 authentication)

As mentioned at the beginning, network transparency is one of the central char-acteristics of a UNIX system. X11, the windowing system of UNIX operatingsystems, can make use of this feature in an impressive way. With X11, it is basi-cally no problem to log in at a remote host and start a graphical program that willthen be sent over the network to be displayed on your computer. The protocolto communicate between the X application and the X server (which is the localprocess that draws the windows with the help of your video card) is relativelylightweight as far as bandwidth usage is concerned. This is because the protocolwas designed in the eighties when network bandwidth was still a scarce resource.

Now if we want an X client to be displayed remotely using our X server, thelatter is supposed to protect the resource managed by it (i. e. the display) fromunauthorized access. In more concrete terms, certain permissions must be givento the client program. With the X Window System, there are two ways to dothis, called host-based access control and cookie-based access control. The for-mer relies on the IP address of the host where the client is supposed to run; theprogram to control this isxhost . Whatxhost does is to enter the IP address ofa legitimate client into a tiny database belonging to the X server. Note, however,that relying on IP addresses for authentication is not very secure. For example,if there were a second user working on the host sending the client program, thatuser would have access to the X server as well — just like someone stealing theIP address. Because of these shortcomings, we will not describe this authentica-tion method in more detail here, but you can learn about the way it functions ifyou read the man page ofxhost , which includes a similar warning.

In the case of cookie-based access control, a character string is generated whichis only known to the X server and to the legitimate user, just like an ID cardof some kind. This cookie (the word goes back not to ordinary cookies, but toChinese fortune cookies which contain an epigram) is stored on login in the file.Xauthority in the user’s home directory and is available to any X Windowclient wanting to use the X server to display a window. The file.Xauthoritycan be examined by the user with the toolxauth . If you were to rename.Xauthority or if you deleted the file from your home directory by acci-dent, you would not be able to open any new windows or X clients. Readmore about X Window security mechanisms in the man page ofXsecurity(man Xsecurity ).

Apart from that,ssh (secure shell) can be used to completely encrypt a networkconnection and forward it to an X server transparently without the encryptionmechanism being perceived by the user. This is also called X forwarding. Xforwarding is achieved by simulating an X server on the server side and settinga DISPLAY variable for the shell on the remote host. Before being displayed,the client opens a connection with sshd (secure shell daemon, the server sideprogram), which then gets the connections through to the real X server. If your

150


setup requires that X clients are displayed remotely, consider usingssh . Theman page ofssh has more information about the functionality of this program.Further details aboutssh can be found in SectionC.1on page139of this book.

� �

�

CautionIf you do not consider the host where you log in to be a secure host, do notuse X forwarding. With X forwarding enabled, an attacker could authenticatevia your ssh connection to intrude on your X server and sniff your keyboardinput, for instance.

Buffer Overflows and Format String Bugs

As discussed in the section on local security, buffer overflows and format stringbugs should be classified as issues concerning both local and network security.As with the local variants of such bugs, buffer overflows in network programs,when successfully exploited, are mostly used to obtain‘root’ permissions.Even if that is not the case, an attacker could use the bug to gain access to anunprivileged local account to exploit any other vulnerabilities which might existon the system.

Buffer overflows and format string bugs exploitable over a network link are cer-tainly the most frequent form of remote attacks in general. Exploits for these— programs to exploit these newly-found security holes — are often posted onthe security mailing lists. They can be used to target the vulnerability withoutknowing the details of the code. Over the years, experience has shown that theavailability of exploit codes has contributed to more secure operating systems,obviously due to the fact that operating system makers were forced to fix theproblems in their software. With free software, anyone has access to the sourcecode (SuSE Linux comes with all available source codes) and anyone who findsa vulnerability and its exploit code can submit a patch to fix the correspondingbug.

DoS — Denial of Service

The purpose of this kind of attack is to force down a server program or evenan entire system, something which could be achieved by various means: over-loading the server, keeping it busy with garbage packets, or exploiting a remotebuffer overflow.

Often a DoS attack is done with the sole purpose of making the service disappear.However, once a given service has become unavailable, communications couldbecome vulnerable to so-called “man-in-the-middle attacks” (sniffing, TCP con-nection hijacking, spoofing) and DNS poisoning, explained below.

151

C Network Security

Man in the Middle: Sniffing, TCP Connection Hijacking, Spoofing

In general, any remote attack performed by an attacker who puts himself betweenthe communicating hosts is called a “man-in-the-middle attack”. What almost alltypes of man-in-the-middle attacks have in common is that the victim is usuallynot aware that there is something happening. There are many possible variants,for example, the attacker could pick up a connection request and forward that tothe target machine himself. Now the victim has unwittingly established a con-nection with the wrong host, because the other end is posing as the legitimatedestination machine. The simplest form of a man-in-the-middle attack is called“sniffer” — the attacker is “just” listening to the network traffic passing by. As amore complex attack, the “man in the middle” could try to take over an alreadyestablished connection (hijacking). To do so, the attacker would have to analyzethe packets for some time to be able to predict the TCP sequence numbers be-longing to the connection. When the attacker finally seizes the role of the targethost, the victims will notice this, because they get an error message saying theconnection was terminated due to a failure.What often makes things easier for attackers is the fact that there are protocolswhich are not secured against hijacking through encryption, but only perform asimple authentication procedure upon establishing the connection. Finally, wewant to mention “spoofing”, an attack where packets are modified to containcounterfeit source data, mostly the IP address. Most active forms of attack relyon sending out such fake packets — something that, on a Linux machine, canonly be done by the superuser (‘root’ ).Many of the attacks mentioned are carried out in combination with a DoS. If anattacker sees an opportunity to abruptly bring down a certain host, even if onlyfor a short time, it will make it easier for him to push the active attack, becausethe host will not be able to interfere with the attack for some time.

DNS Poisoning

DNS poisoning means that the attacker corrupts the cache of a DNS server byreplying to it with spoofed DNS reply packets, trying to get the server to sendcertain data to a victim who is requesting information from that server. To foistsuch false information onto the server in a credible way, normally the attackermust have received and analyzed some packets from it. Given that many serversare configured to maintain a trust relationship with other hosts, based on IP ad-dresses or host names, such an attack may be successful in a relatively shorttime. On the other hand, it also requires quite an effort. In any case, the attackerwill need a good understanding of the actual structure of the trust relationshipsbetween hosts. The attacker often needs to target a well-timed DoS attack at thename server, as well. Protect yourself by using encrypted connections that areable to verify the identity of the hosts to which to connect.

Worms

Worms are often confused with viruses, but there is a clear difference between thetwo. Unlike viruses, worms do not need to infect a host program to live. Rather,

152


they are specialized to spread as quickly as possible on network structures. Theworms that appeared in the past, such as Ramen, Lion, or Adore, make use ofwell-known security holes in server programs likebind8 or lprNG . Protectionagainst worms is relatively easy. Given that some time will elapse between thediscovery of a security hole and the moment the worm hits your server, there isa good chance that an updated version of the affected program will be availableon time. Of course, that is only useful if the administrator actually installs thesecurity updates on the systems in question.

C.2.3 Some General Security Tips and Tricks

Information: To handle security competently, it is important to keep up withnew developments and to stay informed about the latest security issues. Onevery good way to protect your systems against problems of all kinds is to getand install the updated packages recommended by security announcements asquickly as possible. SuSE security announcements are published on a mail-ing list to which you can subscribe by following the linkhttp://www.suse.de/security . The [email protected] is a first-handsource of information regarding updated packages and includes members ofSuSE’s security team among its active contributors.The mailing [email protected] is a good place to discuss any se-curity issues of interest. Subscribe to it under the URL as given above [email protected] [email protected] is one of the best-known security mailing listsworldwide. We recommend that you read this list, which receives between 15and 20 postings per day. More information can be found athttp://www.securityfocus.com .The following is a list of rules which you may find useful in dealing with basicsecurity concerns:

• According to the rule of using the most restricive set of permissions possiblefor every job, avoid doing your regular jobs as‘root’ . This reduces the riskof getting a cuckoo egg or a virus and protects you from your own mistakes.

• If possible, always try to use encrypted connections to work on a remotemachine. Use “ssh” (secure shell) to replacetelnet , ftp , rsh andrlogin .

• Avoid using authentication methods based on IP addresses alone.

• Try to keep the most important network-related packages up-to-date and sub-scribe to the corresponding mailing lists to receive announcements on newversions of such programs (bind , sendmail , ssh , etc.). The same shouldapply to software relevant to local security.

• Change the/etc/permissions file to optimize the permissions of files cru-cial to your system’s security. If you remove the setuid bit from a program,it might well be that it cannot do its job anymore in the way it is supposed to.On the other hand, consider that, in most cases, the program will also haveceased to be a potential security risk. You might take a similar approach withworld-writable directories and files.

153

http://www.suse.de/security


[email protected]

[email protected]

[email protected]

[email protected]

http://www.securityfocus.com

http://www.securityfocus.com

C Network Security

• Disable any network services you do not absolutely require for your server towork properly. This will make your system safer, plus it prevents your usersfrom getting used to a service that you had never intended to be availablein the first place (the legacy problem). Open ports, with the socket stateLISTEN, can be found with the programnetstat . As for the options, wesuggest usingnetstat -ap or netstat -anp . The-p option allows youto see which process is occupying a port under which name.

Compare thenetstat results with those of a thorough port scan done fromoutside your host. An excellent program for this job isnmap, which notonly checks out the ports of your machine, but also draws some conclusionsas to which services are waiting behind them. However, port scanning maybe interpreted as an aggressive act, so do not do this on a host without theexplicit approval of the administrator. Finally, remember that it is importantnot only to scan TCP ports, but also UDP ports (options-sS and-sU ).

• To monitor the integrity of the files of your system in a reliable way, usethe programtripwire . Encrypt the database created bytripwire to pre-vent someone from tampering with it. Furthermore, keep a backup of thisdatabase available outside your machine, stored on an external data mediumnot connected to it by a network link.

• Take proper care when installing any third-party software. There have beencases where a hacker had built a trojan horse into the tar archive of a securitysoftware package, which was fortunately discovered very quickly. Only in-stall a binary package, if you have no doubts about the site from which youdownloaded it.

SuSE’s RPM packages are gpg-signed. The key used by SuSE for signingreads as follows:

ID:9C800ACA 2000-10-19 SuSE Package Signing Key <[email protected]>

Key fingerprint = 79C1 79B2 E1C8 20C1 890F 9994 A84E DAE8 9C800ACA

The commandrpm -checksig package.rpm shows whether the check-sum and the signature of an uninstalled package are correct. Find the key onthe first CD of the distribution and on most key servers worldwide.

• Check your backups of user and system files regularly. Consider that if youdo not test whether the backup will work, it might actually be worthless.

• Check your log files. Whenever possible, write a small script to search forsuspicious entries. Admittedly, this is not exactly a trivial task. In the end,only you can know which entries are unusual and which are not.

• Use tcp_wrapper to restrict access to the individual services running onyour machine, so you have explicit control over which IP addresses can con-nect to a service. For more information regardingtcp_wrappers , consultthe man pages fortcpd andhosts_access .

• Design your security measures to be redundant: a message seen twice ismuch better than no message at all.

154


C.2.4 Using the Central Security Reporting Address

If you discover a security-related problem (please check the available updatepackages first), write an e-mail [email protected] . Please include a de-tailed description of the problem and the version number of the package con-cerned. SuSE will try to send a reply as soon as possible. You are encouraged topgp encrypt your e-mail messages. SuSE’s pgp key is as follows:

ID:3D25D3D9 1999-03-06 SuSE Security Team <[email protected]>

Key fingerprint = 73 5F 2E 99 DF DB 94 C4 8F 5A A3 AE AF 22 F2 D5

This key is also available for download from:http://www.suse.de/security

155

[email protected]


C Network Security

156

D YaST and SuSE Linux License Terms


YaST Copyright (c) 1995 - 98 SuSE GmbH, Furth (Germany)

The object of this license is theYaST (Yet another Setup Tool) program, thename “YaST”, SuSE Linux the Linux Distribution of SuSE GmbHand all otherprograms of SuSE GmbH under this license, all programs derived from YaSTor another program under this licenseand all works or names derived in fullor in part thereof together with the use, application, archiving, reproduction andpassing on of a program under this license, all programs derived froma programunder this licenseand all works derived in full or in part thereof. The YaSTprogram, any other program under this license and all sources are the intellectualproperty of SuSE GmbH within the meaning of the Copyright Law. The nameYaST is a registered trademark of SuSE GmbH. In the following SuSE GmbHis the licensor and every user or processor of YaSTor any other program underthis license, works derived in full or in part thereof, together with every personwho reproduces, distributes or archives YaST, SuSE Linuxor any other programunder this license, is the licensee of SuSE GmbH.

The following license terms are recognised as a result of the processing, use,application, archiving reproduction and disseminationof the programs under thislicense.

Only this license gives the Licensee the right to use reproduce, to distribute orto amend YaST,any other program under this licenseor works derived thereof.These actions are forbidden by the copyright act, if this license is not recognised.If this license is recognised and complied with in full, it is also valid even withoutthe written consent of the Licensee.

1. Usage

YaST, SuSE Linuxand any other program under this licensemay be usedfor personal and commercial purposes if the copyright and license terms ofthe installed packages and programes are observed. The use of YaSTor anyother program under this license, even if a modified version is used, doesNOT exempt in particular the Licensee from the duty to take due care withregard to the license terms of the packages or programs installed throughYaST,any other program under this licenseor works based on it.

2. Processing

All programs derived from YaST,any other program under this licenseandall works derived thereof, in full or parts thereof are to be filled on the open-ing screen with the clear information “Modified Version”. Moreover the op-erator give his name on the opening screen, stating that SuSE GmbH is notproviding any support for the “Modified Version” and is excluded from any

157


liability whatsoever. Every amendment to the sources which are not con-ducted by SuSE GmbH are deemed to be a “Modified Version”. The Li-censee is entitled to change his copy from the sources of YaSTor any otherprogram under this license, whereby a work based onone of these programsis created, provided that the following conditions are satisfied.

a) Every amendment must have a note in the source with date and operator.The amended sources must be made available for the user in accordancewith section 3) together with the unamended license.

b) The Licensee is obliged to make all work distributed by him which isderived as a whole orin part from a program under this licenseor partsthereof to third parties as a whole under the terms of this license withoutroyalties.

c) The amendment of this license by a Licensee, even in part, is forbidden.

SuSE GmbH reserves the right to accept parts or all amendments of a modi-fied version of any program under this license into the official version of theconcerned programfree of charge. The Licensee has no bearing on this.

3. Dissemination

It is forbidden to reproduce or distribute data carriers which have been repro-duced without authorisation for payment without the prior written consent ofSuSE GmbH or SuSE Linux. Distributionof programs under this license,their sources, whether amended or unamended in full or in part thereof, andthe works derived thereof for a charge require the prior written consent ofSuSE GmbH.

All programs derivedfrom programs under this license, and all works de-rived thereof as a whole or parts thereof may only be disseminated with theamended sources and this license in accordance with 2b). Making YaST,or any other program under this licenseor works derived thereof availablefree of charge together with SuSE Linux on FTP Servers and mailboxes ispermitted if the licenses on the software are observed.

4. Guarantee

No guarantee whatsover is given for YaST,any other program under thislicense or for works derived thereofand SuSE Linux. The SuSE GmbHguarantee only covers fault-free data carriers.

SuSE GmbH will provideevery program under this licenseand SuSE LinuxAS IT ISwithout any guarantee whatever that it is fit for a specific purposeor use. In particular SuSE is not liable for lost profit, savings not made, ordamages from the claims lodged by third parties against the Licensee. SuSEGmbH is not liable either for other direct or indirect consequential losses, inparticular not for the loss or production of recorded data.

The observance of the respective licenses and copyrights of the installed soft-ware is incumbent solely upon the user ofthe relevant programand SuSELinux.

158


5. Rights

No other rights to YaST,any other program under this licenseor to SuSELinux are granted other than negotiated in this license. An infringementagainst this license automatically terminates the rights of the Licensee. How-ever the right of third parties who have received copies or rights under thislicense from the Licensee, are not terminated as long as all parts of his li-cense are recognised and observed. If the Licensee is subject to conditions,or obligations as a result of a court judgement, patent terms, license terms,or another reason, and these conditions or obligations contradict this licenseas a whole or in part, the Licensee shall only be exempted in full or in partfrom this license and its terms with the express prior written consent of SuSE,SuSE is entitled to withhold its consent without giving reasons.

6. Additional restrictions

If the distribution or use of YaST,any other program under this licenseandSuSE Linux or parts of SuSE Linux is restricted in a state either by patentsor by interfaces protected by copyright, SuSE GmbH can specify an explicitgeographic restriction of the distribution of theconcerned programor partsof SuSE Linux, in which these states are fully or partially excluded from dis-tribution. In such a case this license includes the whole or partial restrictionas if it was written down in this license.

159


160

Index

Index

AACLs

arranging . . . . . . . . . . . . . . . .50defining . . . . . . . . . . . . . . . . .49editing . . . . . . . . . . . . . . . . . .50Squid . . . . . . . . . . . . . . . . . .131

Adminhost . . . . . . . . . . .9, 11–28installing by updating .11–14installing new . . . . . . . .14–28troubleshooting . . . . . . . . . .97YaST2 module . . . . . . . . . . .14

administeringtools . . . . . . . . . . . . . . . . . . . .11

administratorschanging job of . . . . . . . . . . . .7

ApacheSquid . . . . . . . . . . . . . . . . . .131

attacks . . . . . . . . . . . . . . . . . . . . . .7detecting . . . . . . . . . . .101–104external . . . . . . . . . . . . . . . .103responding to . . . . . . . . . . .102

BBIND . . . . . . . . . . . . . . . . . . . .109

BIND8 . . . . . . . . . . . . 109, 110bind8 . . . . . . . . . . . . . . . . . . .120boot managers

YaST2 . . . . . . . . . . . . . . . . . .18boot parameters . . . . . . . . . . . .91

Ccertificates

authorities . . . . . . . . . . . . . . .55CAs . . . . . . . . . . . . . . . . . . . . .55creating . . . . . . . . . . . . . . . . .57distributing . . . . . . . . . . . . . .67exporting . . . . . . . . . . . . . . . .59FAS . . . . . . . . . . . . . . . . .55–59importing . . . . . . . . . . . . . . . .59revoking . . . . . . . . . . . . . . . . .58

chroot . . . . . . . . . . . . . . . . . . . . .87communication analysis . . . . .99

communication matrix . . . .99

compartment . . . . . . . . . . . . . . .87configuration files . . . . . . . . . .88

.xsession . . . . . . . . . . . . . . .138fas . . . . . . . . . . . . . . . . . . . . . .66firewall.rc.config . . . . .73, 74,

77–84, 89host.conf . . . . . . . . . . . . . . . .22

alert . . . . . . . . . . . . . . . . . . . . . .23multi . . . . . . . . . . . . . . . . . . . . .23nospoof . . . . . . . . . . . . . . . . . .23order . . . . . . . . . . . . . . . . . . . . .22trim . . . . . . . . . . . . . . . . . . . . . .23HOSTNAME . . . . . . . . . . . .26hosts . . . . . . . . . . . . . . . . .21, 70lilo.conf . . . . . . . . . . . . . . . .143modules.boot . . . . . . . . . . . .88named . . . . . . . . . . . . . . . . . . .89named.conf . . . . .89, 109, 110named/master . . . . . . . . . . . .89named/root.hint . . . . . . . . . .89named/slave . . . . . . . . . . . . .89networks . . . . . . . . . . . . . . . .22nscd.conf . . . . . . . . . . . . . . . .25nsswitch.conf . . . . . . . . . . . .23pam.d . . . . . . . . . . . . . . . . . . .89permissions . . . . . . . . . . . . .149permissions.local . . . .89, 144postfix . . . . . . . . . . . . . . . . . .89proxy-suite . . . . . . . . . . . . . .89rc.config .21, 77, 89, 126, 144rc.config.d . . . . . . . . . . . . . . .89rc.firewall . . . . . . . . . . . . . . .74resolv.conf . . . . . . .25, 89, 125route.conf . . . . . . . . . . . . . . .90runlevel.firewall . . . . . . . . . .90securetty . . . . . . . . . . . . . . . .90services . . . . . . . . . . . . . . . . .77shadow . . . . . . . . . . . . . . . . . .90squid.conf . 90, 125–131, 133squidguard.conf . . . . . . . . .133ssh . . . . . . . . . . . . . . . . . . . . . .90sshd_config . . . . . . . . . . . . .139su1.priv . . . . . . . . . . . . . . . . .90

syslog.conf . . . . . . . . . . . . . .90syslog.socks . . . . . . . . . . . . .90

configuringconfiguration disk . . . . . . . .88DNS . . . . . . . . . . . . . . . . . . .109Squid . . . . . . . . . . . . . . . . . .126

Ddisks

configuration disk . . . . . . . .88DMZ

interfaces . . . . . . . . . . . . . . . .78DNS . . . . . . . . . . . . . . . . . . . . . .84

BIND . . . . . . . . . . . . . . . . . .109configuring . . . . . . . . . . . . .109FAS . . . . . . . . . . . . . . . . .36–37forwarding . . . . . . . . . . . . .110logging . . . . . . . . . . . . . . . . .112options . . . . . . . . . . . . . . . . .110reverse lookup . . . . . . . . . .115sample configuration . . . .116security and . . . . . . . . . . . .148starting . . . . . . . . . . . . . . . . .109troubleshooting . . . . . . . . .109zones . . . . . . . . . . . . . . . . . .112

files . . . . . . . . . . . . . . . . . . . . .113documenting . . . . . . . . . . .30, 69

need for . . . . . . . . . . . . . . . . .11domain name

assigning . . . . . . . . . . . . . . . .35

FFAS . . . . . . . . . . . . . . . .11, 29–70

base module . . . . . . . . . .32–35certificates . . . . . . . . . . .55–59configuring . . . . . . . . . . .29–67DNS . . . . . . . . . . . . . . . . .36–37domain name . . . . . . . . . . . .35editing configurations . . . . .68firewall module . . . . . . .37–39firewall script . . . . . . . . . . . .37FTP . . . . . . . . . . . . . . . . .46–48FTP proxy . . . . . . . . . . . . . . .47

161

Index

fwadmin . . . . . . . . . . . . . . . . .27hard disk . . . . . . . . . . . . . . . .32host name . . . . . . . . . . . . . . .35HTTP proxies . . . . . . . .48–55IP filter . . . . . . . . . . . . . . . . . .37IPsec . . . . . . . . . . . . . . . .62–67kernel modules . . . . . . . . . . .39Keyring Module . . . . . .55–59logging . . . . . . . . . . . . . . . . . .39login . . . . . . . . . . . . . . . . . . . .29masquerading . . . . . . . . . . . .37network interfaces . . . . . . . .33ports . . . . . . . . . . . . . . . . .38–39Postfix . . . . . . . . . . . . . . . . . .43rinetd . . . . . . . . . . . . . . . .59–62root password . . . . . . . . . . . .32routing . . . . . . . . . . . . . . .34, 37saving configuration . . . . . .68SSH . . . . . . . . . . . . . . . . .45–46starting . . . . . . . . . . . . . . . . . .29syslog . . . . . . . . . . . . . . . . . . .35testing configuration . .68–69time server . . . . . . . . . . . . . . .59users . . . . . . . . . . . . . . . . . . . .29VPN . . . . . . . . . . . . . . . . .62–67

fas-devel . . . . . . . . . . . . . . . .13feedback . . . . . . . . . . . . . . . . .107Firewall Administration System

seeFASfirewall host . . . . . . . . . . . . . . . . .9

booting . . . . . . . . . . . . . . . . . .93firewalls

documenting . . . . . . . . . . . . .69need for . . . . . . . . . . . . . . . . . . .8implementing . . . . . . . . . . . .93ipchains . . . . . . . . . . . . . . . . .84monitoring . . . . . . . . . . . . . . .69protecting from internal . . .79required programs . . . . . . . .74scripts . . . . . . . . . . . . . . . . . . .73setups . . . . . . . . . . . . . . . . . . . .9term origins . . . . . . . . . . . . . . .8testing . . . . . . . .68–69, 94–95updates . . . . . . . . . . . . . . . . .100

FTPactive . . . . . . . . . . . . . . . . . . .81configuring firewall for . . . .46proxies . . . . . . . . . . . . . . .47, 86

Ggrep . . . . . . . . . . . . . . . . . . . . . .103

Hhelp . . . . . . . . . . . . . . . . . . . . . . .97

support . . . . . . . . . . . . . . . . .104host name

assigning . . . . . . . . . . . . . . . .35howtoen . . . . . . . . . . . . . . . . .134HTTP

ACLs . . . . . . . . . . . . . . . .49–51caching . . . . . . . . . . . . . . . . . .49content filter . . . . . . . . . .51–52content filters . . . . . . . . . . . .85MIME type filters . . . . .52–53proxies . . . . . . . . . . .48–55, 85

httpf . . . . . . . . . . . . . . . . . . . . . .85

IICMP

rules . . . . . . . . . . . . . . . . . . . .75ifconfig . . . . . . . . . . . . . . . . . . . .97implementing

requirements . . . . . . . . . . . . .93installing

support . . . . . . . . . . . . . . . . .104ipchains . . . . . . . . . . . .37, 72, 84IPsec . . . . . . . . . . . . . . . . . .62–67

Kkernel

modules . . . . . . . . . . . . . . . . .39kernel caps . . . . . . . . . . . . . . . .87kernels

security . . . . . . . . . . . . . .74, 83version required . . . . . . . . . .74

Llibcinfo . . . . . . . . . . . . . . . . .23Live CD . . . . . . . . . . . . . . . . .8, 71

advantages . . . . . . . . . . . . .104reason for . . . . . . . . . . . . . . .71services . . . . . . . . . . . . . . . . .72troubleshooting . . . . . . . . . .97

log filesanalyzing . . . . . . . . . . . . . . . .69mail . . . . . . . . . . . . . . . . . . . . .69messages . .69, 103, 109, 118Squid . . . . . . . . . . . . . .126, 127

log host . . . . . . . . . . . . . . . . . . . . .9logging . . . . . . . . . . . . . . . . . . . .76

log host . . . . . . . . . . . .9, 13, 35log level . . . . . . . . . . . . .39, 83syslog . . . . . . . . . . . . . . . . . . .35syslog-ng . . . . . . . . . . . . . . . .70value of . . . . . . . . . . . . . . . . .95

Mmagic user . . . . . . . . . . . . . . . . .86mail relays . . . . . . . . .seePostfixmasquerading . . . . . . . . . . .37, 75

activating . . . . . . . . . . . . . . . .79configuring . . . . . . . . . . . . . .77services . . . . . . . . . . . . . . . . .82

MIMEfilters . . . . . . . . . . . . . . . . . . .52

monitoring . . . . . . . . . . . . . . . . .69need for . . . . . . . . . . . . . . . . .11

Nname servers . . . . . . . . .seeDNSnetworks

attacks on . . . . . . . . . . . . . . . . .7configuration files . . . . .21–27configuring with YaST2 . . .20manual configuration . .21–27planning . . . . . . . . . . . . . . . . . .9troubleshooting . . . . . . .97–98

NSS . . . . . . . . . . . . . . . . . . . . . . .23databases . . . . . . . . . . . . . . . .23

OOpenSSH . . . . . . . . . . . .seeSSH

Ppackage

bind8 . . . . . . . . . . . . . . . . .120fas-devel . . . . . . . . . . . . . .13howtoen . . . . . . . . . . . . . . .134libcinfo . . . . . . . . . . . . . . .23squidgrd . . . . . . . . . . . . . .133syslog-ng . . . . . . . . . . . . . .13

packet filterscreating . . . . . . . . . . . . . . . . .84definition . . . . . . . . . . . . . . . .73

partitioningYaST2 . . . . . . . . . . . . . . .16–17

passwordsgood passwords . . . . . . . . . .30

portsDMZ . . . . . . . . . . . . . . . . . . . .39external access . . . . . . . . . . .39internal access . . . . . . . . . . .38scanning . . . . . . . . . . . . . . . . .68

Postfix . . . . . . . . . . . . . . . . . . . .84configuring . . . . . . . . . . . . . .43

protocolssupported . . . . . . . . . . . . . . . . .9

proxiesadvantages . . . . . . . . . . . . .121

162

Index

caches . . . . . . . . . . . . . . . . .121FTP . . . . . . . . . . . . . . . . .47, 86HTTP . . . . . . . . . . . .48–55, 85Live CD and . . . . . . . . . . . . .72parent . . . . . . . . . . . . . . . . . . .53rinetd . . . . . . . . . . . . . . . . . . .59Squid . . . . . . . . . . . . . . . . . .121transparent . . . . . . .38, 48, 130

Rroot

password . . . . . . . . . . . . . . . .18routing . . . . . . . . . . . . . . . . . . . .84

activating . . . . . . . . . . . . . . . .78configuring . . . . . . . . . . . . . .77FAS . . . . . . . . . . . . . . . . . . . . .37FAS configuration . . . . . . . .34rinetd . . . . . . . . . . . . . . . . . . .59

RPMsecurity . . . . . . . . . . . . . . . .150

Sscripts

fas_convertconfig.pl . . . . . .12firewall . . . . . . . . . . . . . .73–76

return values . . . . . . . . . . . . . .76starting . . . . . . . . . . . . . . .76, 78termination reasons . . . . . . . .74init.d . . . . . . . . . . . . . . . .26, 90

firewall . . . . . . . . . . . . . . .73, 76inetd . . . . . . . . . . . . . . . . . . . . .27network . . . . . . . . . . . . . . . . . .27nfsserver . . . . . . . . . . . . . . . . .27portmap . . . . . . . . . . . . . . . . . .27route . . . . . . . . . . . . . . . . . . . . .27sendmail . . . . . . . . . . . . . . . . .27squid . . . . . . . . . . . . . . . . . . . .125ypbind . . . . . . . . . . . . . . . . . . .27ypserv . . . . . . . . . . . . . . . . . . . .27ipsec.d/updown . . . . . . . . . .63modify_resolvconf . . . . . . .25sbin . . . . . . . . . . . . . . . . . . . . .90SuSEconfig . . . . . . . . . .21, 89

secumod . . . . . . . . . . . . . . . . . . .87security . . . . . . . . . . . . . . . . . .140

attacks . . . . . . . . . . . . . . . . .147booting . . . . . . . . . . . .141, 143bugs and . . . . . . . . . . .144, 147DNS . . . . . . . . . . . . . . . . . . .148file race . . . . . . . . . . . . . . . .144local . . . . . . . . . . . . . . . . . . .142networks . . . . . . . . . . . . . . .145passwords . . . . . . . . . . . . . .142

permissions . . . . . . . . . . . . .143policy . . . . . . . . . . . . . . . . . . .98protocols and . . . . . . . . . . .141reporting problems . . . . . .151RPM signatures . . . . . . . . .150serial terminals . . . . . . . . . .141server . . . . . . . . . . . . . . . . . . . .9Squid . . . . . . . . . . . . . . . . . .122SSH . . . . . . . . . . . . . . . . . . .135tcpd . . . . . . . . . . . . . . . . . . . .150tips and tricks . . . . . . . . . . .149updates . . . . . . . . . . . . . . . . .100viruses . . . . . . . . . . . . . . . . .145worms . . . . . . . . . . . . . . . . .148X and . . . . . . . . . . . . . . . . . .146

seriesdoc . . . . . . . . . . . . . . . . . . . . .23n . . . . . . . . . . . . . . 13, 133, 134zfw . . . . . . . . . . . . . . . . . . . . .12zfw1 . . . . . . . . . . . . . . . . . . . .13

Squid . . . . . . . . . . . .85, 121–134access controls . . . . .128, 131Apache . . . . . . . . . . . . . . . . .131cache size . . . . . . . . . . . . . .124cachemgr.cgi . . . . . . . . . . .131caches . . . . . . . . . . . . .121, 122Calamaris . . . . . . . . . . . . . .133configuring . . . . . . . . . . . . .126CPU and . . . . . . . . . . . . . . .125directories . . . . . . . . . . . . . .125features . . . . . . . . . . . . . . . .121hard disks and . . . . . . . . . .123log files . . . . . . . . . . . .126, 127object status . . . . . . . . . . . .123permissions . . . . . . . .125, 128protocols . . . . . . . . . . . . . . .121RAM and . . . . . . . . . . . . . .124reports . . . . . . . . . . . . . . . . .133SARG . . . . . . . . . . . . . . . . .134security . . . . . . . . . . . . . . . .122SquidGuard . . . . . . . . . . . . .132starting . . . . . . . . . . . . . . . . .125statistics . . . . . . . . . . . . . . . .131transparent proxies . . . . . .130uninstalling . . . . . . . . . . . . .126

squidgrd . . . . . . . . . . . . . . . .133SSH . . . . . . . . . . . . .87, 135–139

authentication mechanisms . . .138

configuring in FAS . . . .45–46daemon . . . . . . . . . . . . . . . .137key pairs . . . . . . . . . . .137, 138

OpenSSH . . . . . . . . . . . . . .135RSA keys . . . . . . . . . . . . . . . .90scp . . . . . . . . . . . . . . . . . . . .136sftp . . . . . . . . . . . . . . . . . . . .137ssh . . . . . . . . . . . . . . . . . . . . .135ssh-add . . . . . . . . . . . . . . . . .139ssh-agent . . . . . . . . . .138, 139ssh-keygen . . . . . . . . . . . . .138sshd . . . . . . . . . . . . . . . . . . .137X and . . . . . . . . . . . . . . . . . .139

support . . . . . . . . . . . . . . .97, 104contacting Support Team .105free . . . . . . . . . . .104, 107–108installation . . . . . . . . . . . . .104paid . . . . . . . . . . . . . . .105–106services

paid . . . . . . . . . . . . . . . . . . . . . .99support database . . . . . . . . .97training . . . . . . . . . . . . . . . .107

SuSE Linux AG . . . . . . . . . . .106services . . . . . . . . . . . . . . . . .99

SuSEconfig . . . . . . . . . . . . . . . .21syslog-ng . . . . . . . . . .seeloggingsyslog-ng . . . . . . . . . . . . . . . .13

TTCP

rules . . . . . . . . . . . . . . . . . . . .75testing

external . . . . . . . . . . . . . . . . .95firewalls . . . . . . . . . . . . .68–69internal . . . . . . . . . . . . . . . . . .94

tinyproxy . . . . . . . . . . . . . . . . . .85traceroute . . . . . . . . . . . . . .76, 77transproxy . . . . . . . . . . . . . . . . .85

UUDP

rules . . . . . . . . . . . . . . . . . . . .75updating

obtaining updates . . . . . . .100

XX

security . . . . . . . . . . . . . . . .146SSH and . . . . . . . . . . . . . . .139

xntpd . . . . . . . . . . . . . . . . . . . . .59

YYaST

Adminhost . . . . . . . . . . . . . . .13YaST2

Adminhost . . . . . . . . . . .12–13Adminhost module . . . . . . .14

163

Index

boot manager . . . . . . . . . . . .18graphics card . . . . . . . . . . . .19hard disks . . . . . . . . . . . . . . .16installing . . . . . . . . . . . . . . . .18keyboard . . . . . . . . . . . . . . . .15

language . . . . . . . . . . . . . . . .15monitor . . . . . . . . . . . . . . . . .19mouse . . . . . . . . . . . . . . . . . . .15navigating . . . . . . . . . . . . . . .15network . . . . . . . . . . . . . . . . .20

partitioning . . . . . . . . . . .16–17root password . . . . . . . . . . . .18time zone . . . . . . . . . . . . . . . .15

164

SuSE Linux Firewall on CD — VPN Editionleotardi.ddns.info/html/lan/download/USE Linux Firewall VPN...

Documents

Transcript of SuSE Linux Firewall on CD — VPN Editionleotardi.ddns.info/html/lan/download/USE Linux Firewall VPN...