Silicon Graphics Gauntlet Administrator's Manual

Download

Gauntlet™ for IRIX

™

Administrator’s Guide

Document Number 007-2826-004

CONTRIBUTORS

Written by John Raithel with updates by Pam Sogard Production by Julie Sheikman Engineering contributions by Ed Mascarenhas St. Peter’s Basilica image courtesy of ENEL SpA and InfoByte SpA. Disk Thrower

image courtesy of Xavier Berenguer, Animatica.

or in part, without the prior written permission of Silicon Graphics, Inc.

RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure of the technical data contained in this document by

the Government is subject to restrictions as set forth in subdivision (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 52.227-7013 and/or in similar or successor clauses in the FAR, or in the DOD or NASA FAR Supplement. Unpublished rights reserved under the Copyright Laws of the United States. Contractor/manufacturer is Silicon Graphics, Inc., 2011 N. Shoreline Blvd., Mountain View, CA 94043-1389.

Silicon Graphics and the Silicon Graphics logo are registered trademarks, and IRIX and InPerson are trademarks, of Silicon Graphics, Inc. Gauntlet and the TIS logo are trademarks of Trusted Information Systems, Inc. Netscape Navigator and Netscape Proxy Server are trademarks of Netscape Communications Corporation. Macintosh is a registered trademark of Apple Computer , Inc. Micr osoft and W indows ar e either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd. NFS is a registered trademark of Sun Microsystems, Inc.

Gauntlet™ for IRIX™ Administrator’s Guide Document Number 007-2826-004

Contents

List of Figures xvii About This Guide xix

Audience xix About This Guide xix Conventions Used in This Guide xxii Installation and System Requirements xxiii Additional Resources xxiii

Books xxiii Newsgroups xxiii Mailing Lists xxiii Frequently Asked Questions Lists xxiv White Papers xxiv

How to Get Latest Security Patches xxv

PART I Understanding the Gauntlet Internet Firewall

1. Understanding the Gauntlet Firewall 3

Understanding Gauntlet Firewall Concepts 3

Design Philosophy 3 Security Perimeter 4 Trusted and Untrusted Networks 4 Policy 6 Transparency 6

Understanding Gauntlet Firewall Components 7

Hardware and Software 7

iii

Contents

How a Firewall Works 10

Dual-Homed Bastion Host 12 Processing Packets and Requests 14

PART II Conﬁguring and Using Proxies

2. Managing SMTP Services 19

Understanding the Proxy 19 How It Works 20 Configuring the Firewall for SMTP 20

Planning 21 Configuring the Firewall 21 Configuring Network Services 22 Configuring the Proxy Rules 22 Advertising the Firewall as a Mail Exchanger 22 Configuring Your Internal Mail Hub 22 Verifying Your Setup 23

Using Mail 23

3. Managing POP3 Services 25

Understanding the Proxy 25 How the POP3 Proxy Works 26 Configuring the Firewall for POP3 26

Planning 27 Configuring Network Services 27 Configuring the Proxy Rules 27 Configuring Your Internal POP3 Mail Server 27 Setting APOP Passwords on the Firewall 28 Verifying Your Setup 28

Using POP3 to Exchange Mail 28

4. Managing Terminal Services 31

Understanding the Proxies 31 How the Proxies Work 32

Using the TELNET and Rlogin Proxies Without Network Access Control 33

Configuring the Firewall for Terminal Services 33

Planning 33 Configuring the Firewall 34 Configuring Network Services 34 Configuring the Proxy Rules 34 Creating Authentication User Entries 35 Verifying Your Setup 35

Using Terminal Services 35

TELNET, Rlogin, and TN3270 Without Authentication 35 TELNET and Rlogin With Authentication 36 TN3270 With Authentication 37

5. Managing FTP Services 39

Understanding the FTP Proxy 39 How the FTP Proxy Works 40 Configuring the Firewall for FTP Services 41

Planning 41 Configuring Network Services 41 Configuring the Proxy Rules 41 Creating Authentication User Entries 41 Verifying Your Setup 42

Using FTP Services 42

Using Authentication 42 Using Authentication With Some GUI FTP Tools 43

Running an Anonymous FTP Server 44

Contents

6. Managing Rsh Services 47

Understanding the Rsh Proxy 47 How It Works 48 Configuring the Firewall for Rsh Services 48

Planning 48 Configuring Network Services 48 Configuring the Proxy Rules 49 Verifying Your Setup 49

Using Rsh Services 49

Configuring the Remote Machine 49

7. Managing Gopher and WWW Services 51

Understanding the Proxy 51 How It Works 52

Authenticated HTTP 53 Gopher and FTP Services 54 SHTTP and SSL Services 54

Configuring the Firewall for WWW and Gopher Services 54

Planning 54 Configuring Network Services 55 Configuring the Proxy Rules 55 Creating User Authentication Entries 55 Verifying Your Setup 55

Using Web Services 55

Using Proxy-Aware Browsers 56

Using Non-Proxy-Aware Browsers 58 Using Gopher Services 59 Running a WWW Server 60

8. Managing RealAudio Services 61

Understanding the RealAudio Proxy 61

How It Works 62

Configuring the Firewall to Use the RealAudio Proxy 62

Planning 63 Configuring Network Services 63 Configuring the Proxy Rules 63 Verifying Your Setup 63

Using the RealAudio Proxy 63

To configure the RealAudio player: 64

9. Managing MediaBase Services 65

Understanding the MediaBase Proxy 65

How It Works 66

Configuring the Firewall to Use the MediaBase Proxy 66

Planning 66 Configuring Network Services 67 Configuring the Proxy Rules 67 Verifying Your Setup 67

Using the MediaBase Proxy 67

Contents

10. Managing X Window Services 69

Understanding the X11 Proxy 69

How the X11 Proxy Works 70

Configuring the Firewall for X11 Services 71

Planning 71 Configuring Network Services 71 Configuring the Proxy Rules 71 Verifying Your Setup 71

Using X11 Services 72

vii

Contents

11. Managing LP Services 75

Understanding the lp Proxy 75 How the lp Proxy Works 76 Configuring the Firewall for lp Services 76

Planning 76

Configuring Network Services 77

Configuring the Proxy Rules 77

Configuring the Sending Machine 77

Configuring the Receiving Machine 77

Verifying Your Setup 78 Using lp Services 78

12. Managing Sybase Services 79

Understanding the Sybase Proxy 79 How It Works 80 Configuring the Firewall for Sybase Services 81

Planning 81

Configuring Network Services 81

Configuring the Proxy Rules 81

Configuring Sybase Clients 82

Verifying Your Setup 82

viii

PART III Administering General

Gauntlet Firewall Services

13. Managing NNTP and General TCP Services 85

Understanding the Proxy 86 How It Works 87

Configuring the Firewall for NNTP 87

Planning 87 Configuring the Firewall 88 Configuring Network Services 88 Configuring the Proxy Rules 88 Informing Your News Feed 88 Configuring Your News Server 88

Verifying Your Setup 89 Using NNTP 89 Configuring the Firewall for Other Protocols 89

Planning 89

Configuring Network Services 90

Configuring the Proxy Rules 90

Configuring Your Service 91

Verifying Your Setup 91 Configuring Multiple Newsfeeds 91 Configuring Your NNTP Proxy for Reading News 92

Contents

14. Managing General TCP Services With Authentication 93

Understanding the Circuit Proxy 93 How It Works 94 Configuring the Firewall for Authenticated TCP Services 95

Planning 95

Configuring Network Services 96

Configuring the Proxy Rules 97

Verifying Your Setup 98 Using the Circuit Proxy 98

15. Managing Information Services on the Firewall 101

Understanding the Info Server 101 How It Works 102

HTTP and Gopher Server 102

FTP Server 102

How the Database Works 103

Contents

Configuring the Firewall 105

Planning 106 Configuring Network Services 106 Configuring the Proxy Rules 106 Verifying Your Setup 106

Using the Info Server 106

Planning 107 Creating Files 107 Placing Files on the Firewall 107 Adding Files to the Database 107 Creating FTP List Files 109 Creating Gopher Menu Files 109 Advertising Your Server 110

16. Using the Network Access Control Daemon 111

Understanding the Network Access Control Daemon 111 How It Works 112 Configuring the Network Access Control Daemon 112

Planning 113 Configuring Network Services 113 Configuring the Proxy Rules 113 Configuring Your Service 113 Verifying Your Setup 113

17. The Graphical Management Interface 115

First Time User Tips 116

Help Links 116 Hide and Unhide Buttons 116 Gauntlet Default Settings 117 When to Use Configure All 117

Using the Gauntlet Management Interface 117

Configuring Gauntlet Locally 118

Introductory Management Form 118

Networks and Interfaces Configuration Form 123

Trusted Networks 126

Trusted Interfaces 126

Untrusted Networks 127

Trusted Ports 127 Routing Configuration Form 128

Additional Routing Information 130 Proxy Servers Configuration Form 131

Remote (Network) Connections 131

Enabling Transparent Proxies 132

Enabling Individual Proxy Services 132 Domain Name Service (DNS) and Gauntlet 139 DNS Configuration Form 140

Configuring Fully Populated DNS Server 140

Configuring a Split DNS Server 142 Sendmail on Gauntlet Servers 146

Mail Hubs 146

Mail Relays 147

Gauntlet and Subdomains 147

Sendmail Configuration Form 148 swIPe Configuration Form 152

Authentication and Encryption Schemes 153

VPN Paths 154

Preparing a Server for swIPe Configuration 154

Configuring a Server for swIPe 156

Verifying Your Setup 159 Logfiles and Reports Configuration Form 159 Authorizing Users Form 163 Configuring Gauntlet for Remote Administration 168

Accessing the Administration Tool from a Browser 170

Accessing the Administration Tool from an X Display 170 Configuring Gauntlet for Secure Remote Administration 170

Contents

18. Managing User Authentication 173

Understanding the User Authentication Management System 173

How the Firewall Uses This Information 174 How Other Services Use This Information 174 The Pieces 175

Understanding Strong Authentication 176

Access Key II 176 APOP 176 SecurID 177 EnigmaLogic SafeWord 177 S/Key 177 Reusable Passwords 177

Configuring the User Authentication Management System 178

Configuring Third Party Systems 178 Configuring Network Services 179 Configuring Authentication Management System Rules 180 Verifying Your Installation 180

Managing Groups 180

Creating Groups 181 Disabling Groups 181 Deleting Groups 181

Managing Users 181

Creating Users 181 Creating Users with Access Key II 183 Changing User Names 184 Changing Groups 184 Changing Protocols 185 Changing Passwords 185 Enabling Users 186 Disabling Users 186 Deleting Users 187

xii

19. Using the Login Shell 189

Understanding the Login Shell Program 189 How It Works 189 Configuring the Firewall to use the Login Shell Program 190

Planning 190

Enabling Remote Login 190

Adding Support for the Login Shell 190

Creating User Accounts 191

Configuring the Proxy Rules 191

Configuring the Shell 191

Creating User Authentication Records 192

Securing Other Applications 192

Verifying Your Setup 193 Using the Login Shell Program 193

Accessing the Firewall from Trusted Networks 193

Accessing the Firewall from Untrusted Networks 193

Changing Password for User Account 194

Contents

20. Logging and Reporting 195

Understanding Logging and Reporting 195 Creating Logs 196 Configuring Logs 197

Configuring Additional Logging 197

Configuring Log Retention Time 197 Creating Reports 197

Service Summary Reports 198

Exception Reports 198 Configuring Reports 199

Configuring Events to Ignore 199

Configuring the Firewall 199 Reading Logs and Reports 200

Logs 200

Service Summary Reports 201

Exception Reports 201

xiii

Contents

21. Backups and System Integrity 203

Backing Up Your Firewall 203

Backup Considerations 203 Restoring the Firewall 204

Verifying System Integrity 204

Understanding System Integrity 204 Configuring the Files to Ignore 204 Protecting the Integrity Database 205 Verifying System Integrity 205 Understanding the Results 205

PART IV Appendixes

A. Gauntlet System Files 209

Viewing the Gauntlet File List 209

B. Netperm Table 215

Policy Rules 215 Application-Specific Rules 216

Proxies 216 Applications 217

Using This Information 217 Modifying the Netperm Table File 218 Netperm table Syntax 218

Precedence 218 Format 219 Keywords 220 Attributes 221

Creating New Policies 221 Adding Proxy Services 223 Denying Services By Network or Host 223

Denying Access From a Host or Network 223

Controlling Services by User, Group or Time 224

User or Group 225

xiv

Operation 225

Denying Access to a Host or Network 226 Attribute Reference 227

C. Virtual Private Networks 269

Understanding Virtual Private Networks 269

Privacy With Trust (Trusted Link) 271

Privacy Without Trust (Private Link) 272

Encryption Through Multiple Firewalls (Passthrough Link) 272 How It Works 273

Encrypting the Data 273

Decrypting the Data 273

Routing the Packet 274

D. Conﬁguring SSL on the Gauntlet Firewall 275

Getting Ready for SSL Configuration 275 SSL Configuration Procedure 276

Supplementary Instructions for Generating a Key Pair 277

Supplementary Instructions for Generating a Certificate 277

Saving the Email Reply from Your Certificate Authority 278

Supplementary Instructions for Installing Your Certificate 278

Contents

List of Figures

Figure 1-1 Gauntlet Internet Firewall Standard Configuration 11 Figure 1-2 Dual-Homed Bastion Host 13 Figure 3-1 Eudora Pro Configuration for APOP 29 Figure 7-1 Proxy Configuration for Netscape Navigator 2.0 for Windows 57 Figure 10-1 Example X Window Port Information 73 Figure 10-2 Example X Window Confirmation 74 Figure 17-1 Hide Button 116 Figure 17-2 Unhide Button 117 Figure 17-3 Gauntlet Introductory Management Form (1 of 3) 120 Figure 17-4 Gauntlet Introductory Management Form (2 of 3) 121 Figure 17-5 Gauntlet Introductory Management Form (3 of 3) 122 Figure 17-6 Networks and Interfaces Configuration Form (1 of 2) 124 Figure 17-7 Networks and Interfaces Configuration Form (2 of 2) 125 Figure 17-8 Routing Configuration Form 129 Figure 17-9 Example Gauntlet Host Routing Configuration 130 Figure 17-10 Proxy Servers Configuration Form (1 of 3) 136 Figure 17-11 Proxy Servers Configuration Form (2 of 3) 137 Figure 17-12 Proxy Servers Configuration Form (3 of 3) 138 Figure 17-13 DNS Configuration Form (1 of 2) 144 Figure 17-14 DNS Configuration Form (2 of 2) 145 Figure 17-15 Sendmail Configuration Form 151 Figure 17-16 Gauntlet Hosts Using swIPe in a VPN 153 Figure 17-17 swIPe Configuration Form 155 Figure 17-18 Add swIPe Key Form 157 Figure 17-19 Add swIPe Path Form 158 Figure 17-20 Reports and Logfiles Form (1 of 2) 161 Figure 17-21 Reports and Logfiles Form (2 of 2) 162

xvii

List of Figures

Figure 17-22 Authorizing Users Form 165 Figure 17-23 Add User Form 166 Figure 17-24 User Authentication 167 Figure C-1 Yoyodyne Virtual Private Network 270

xviii

Audience

About This Guide

This guide is intended for ﬁrewall administrators. It assumes familiarity with UNIX

system administration, networking and basic ﬁrewall concepts. System administrators should be familiar with TCP/IP, domain name service, sendmail, and router conﬁguration. Consult your local library, bookstore, network resources, and IRIX

administrator for additional references.

This guide is comprised of three parts and contains the following chapters:

Part I, “Understanding the Gauntlet Internet Firewall,” presents the initial information about the ﬁrewall.

• Chapter 1, “Understanding the Gauntlet Firewall,” presents an overview of what

ﬁrewalls are and why they are important. It presents an overview of how the

Gauntlet™ ﬁrewall system works.

Part II, “Conﬁguring and Using Proxies,” explains how to conﬁgure the various applications and proxies.

• Chapter 2, “Managing SMTP Services,” explains what the SMTP proxy does and

how it works. It presents instructions for conﬁguring the Gauntlet ﬁrewall, as well

as required and potential conﬁguration steps for mail applications.

• Chapter 3, “Managing POP3 Services,” explains what the POP3 proxy does and

how it works. It presents instructions for conﬁguring the Gauntlet ﬁrewall, as well

as required and potential conﬁguration steps for mail applications.

• Chapter 4, “Managing Terminal Services,” explains the types of terminal service

applications that the Gauntlet ﬁrewall supports. It explains what the TELNET and

Rlogin proxies do and how they work. It presents instructions for conﬁguring the

xix

About This Guide

Gauntlet ﬁrewall, as well as required and potential conﬁguration steps for the terminal applications.

• Chapter 5, “Managing FTP Services,” explains what the FTP proxy does and how it works. It presents instructions for conﬁguring the Gauntlet ﬁrewall, as well as required and potential conﬁguration steps for the FTP application. It also includes notes on running an anonymous FTP server.

• Chapter 6, “Managing Rsh Services,” explains what the Rsh proxy does and how it works. It presents instructions for conﬁguring the Gauntlet ﬁrewall, as well as required and potential conﬁguration steps for Rsh.

• Chapter 7, “Managing Gopher and WWW Services,” explains the types of information services the Gauntlet ﬁrewall supports. It explains what the HTTP proxy does for HTTP, SHTTP, SSL, and Gopher proxies and how it works. It presents instructions for conﬁguring the Gauntlet ﬁrewall, as well as required and potential conﬁguration steps for these applications.

• Chapter 8, “Managing RealAudio Services,” describes the RealAudio proxy, which securely handles requests to listen to audio data.

• Chapter 9, “Managing MediaBase Services,” describes the MediaBase proxy, which securely handles requests to play video and multimedia data.

• Chapter 10, “Managing X W indow Services,” explains what the X11 proxy does and how it works. It presents instructions for conﬁguring the Gauntlet ﬁrewall, as well as required and potential conﬁguration steps for the X11 applications.

• Chapter 11, “Managing LP Services,” explains what the lp proxy does and how it works. It presents instructions for conﬁguring the Gauntlet ﬁrewall, as well as required and potential conﬁguration steps for lp.

• Chapter 12, “Managing Sybase Services,” explains what the Sybase proxy does and how it works. It presents instructions for conﬁguring the Gauntlet ﬁrewall, as well as required and potential conﬁguration steps for Sybase.

Part III, “Administering General Gauntlet Firewall Services,” presents information on the other administrative tasks for the Gauntlet ﬁrewall.

• Chapter 13, “Managing NNTP and General TCP Services,” explains the types of News and network services the Gauntlet ﬁrewall supports. It explains what the plug proxy does and how it works. It presents instructions for conﬁguring the Gauntlet ﬁrewall, as well as required and potential conﬁguration steps for the News and network applications.

About This Guide

• Chapter 14, “Managing General TCP Services With Authentication,” explains what

the user authentication management system does, and how to use it with the supported strong authentication systems.

• Chapter 15, “Managing Information Services on the Firewall,” explains how the

system logs activity. It explains the different types of reports, how to conﬁgure them, and how to interpret them.

• Chapter 16, “Using the Network Access Control Daemon,” discusses ﬁrewall

backup and explains how to ensure that the ﬁrewall contains the ﬁles and data that it should.

• Chapter 17, “The Graphical Management Interface,” explains what the graphical

administrative interface does, how to access it from local and remote locations, and how to use it to conﬁgure your Gauntlet ﬁrewall.

• Chapter 18, “Managing User Authentication,” explains what the user

authentication management system does, and how to use it with the supported strong authentication systems.

• Chapter 19, “Using the Login Shell,”explains what the login shell does and how it

works. It presents instructions for conﬁguring the Gauntlet ﬁrewall for more secure access.

• Chapter 20, “Logging and Reporting,” explains how the system logs activity. It

explains the different types of reports, how to conﬁgur e them, and how to interpret them.

• Chapter 21, “Backups and System Integrity,” explains considerations for

incorporating the Gauntlet ﬁrewall in an administrator’s general backup schedule. It also presents considerations for restoring the Gauntlet ﬁrewall.

“Appendixes” present reference material.

• Appendix A, “Gauntlet System Files,” explains the format and precedence of the

trusted and untrusted network tables that the Gauntlet ﬁrewall uses.

• Appendix B, “Netperm Table,” explains the format and precedence of the

netperm-table, which contains conﬁguration information for the Gauntlet ﬁrewall, and the concepts behind policies.

• Appendix C, “Virtual Private Networks,” Virtual Private Networks, explains how

you can use your Gauntlet Internet Firewall to exchange encrypted trafﬁc with other Gauntlet Firewalls.

xxi

About This Guide

• Appendix D, “Conﬁguring SSL on the Gauntlet Firewall,” explains the Secure Socket Layer protocol and how to conﬁgure it to protect remote administration sessions of the Gauntlet ﬁrewall.

The Glossary presents deﬁnitions of terms used in this document.

Conventions Used in This Guide

These type conventions and symbols are used in this guide:

Bold—Literal command-line arguments.

Italics—Backus-Naur Form entries, executable names, ﬁlenames, IRIX commands, URLs, manual/book titles, new terms, onscreen button names, tools, utilities, variable command-line arguments, and variables to be supplied by the user in examples, code, and syntax statements.

Fixed-width type—Prompts, and onscreen text.

xxii

Bold fixed-width type—User input, including keyboard keys (printing and

nonprinting); literals supplied by the user in examples, code, and syntax statements (see also <>).

ALL CAPS—Environment variables.

““ (Double quotation marks)—Onscreen menu items and references in text to document section titles.

() (Parentheses)—Following IRIX commands, parentheses surround the reference page (man page) section number.

[] (Brackets)—Surrounding optional syntax statement arguments.

<> (Angle brackets)—Surrounding nonprinting keyboard keys, for example, <Esc>, <Ctrl-d>, and surrounding required variables in italicized text.

#—IRIX shell prompt for the superuser (root).

%—IRIX shell prompt for users other than superuser.

Installation and System Requirements

Refer to the release notes with your Gauntlet ﬁrewall product for information r egar ding software and hardware requirements as well as installation information.

Additional Resources

This collection of resources is presented as a starting point for your information. It is not an endorsement of any of the products or organizations.

Books

Building Internet Firewalls. Chapman, D. Brent & Zwicky, Elizabeth. O'Reilly & Associates, Inc. ISBN 1-56592-124-0.

Firewalls and Internet Security: Repelling the Wily Hacker. Cheswick, Steven M. & Bellovin, William R. Addison Wesley. ISBN 0-201-63357-4.

About This Guide

Newsgroups

comp.security.ﬁrewalls—Discussions of anything regarding network security ﬁrewalls.

Mailing Lists

The Firewalls mailing list is for discussions of Internet ﬁrewall security systems and related issues. Relevant topics include the design, construction, operation, maintenance, and philosophy of Internet ﬁrewall security systems.

To subscribe to the regular mailing list, send the following command in the body of an email message (NOT on the "Subject:" line!) to majordomo@greatcircle.com:

subscribe firewalls

T o subscribe to the digest version of the mailing list, send the following command in the body of an email message (NOT on the "Subject:" line!) to majordomo@greatcircle.com:

subscribe firewalls-digest

xxiii

About This Guide

Frequently Asked Questions Lists

The Internet Firewalls Frequently Asked Questions list is maintained by Marcus J. Ranum and located at:

http://www.v-one.com/pubs/fw-faq/faq.htm

White Papers

Application Gateways and Filtering Gateway: A Comparison of Firewall Designs Avolio, Frederick M. and Sebes, J. Data Security Letter, Number 59.

http://www.tis.com/Home/NetworkSecurity/Firewalls/FWComp.html

Firewalls Are Not Enough Avolio, Frederick M. Data Security Letter, Number 50.

http://www.tis.com/Home/NetworkSecurity/Firewalls/FirewallsNotEnough.html

A Network Perimeter with Secure External Access Avolio, Frederick M. and Ranum, Marcus

J. Internet Society Symposium on Network and Distributed Systems Security, February

1994.

xxiv

http://www.tis.com/Home/NetworkSecurity/Firewalls/isoc.html

ftp.tis.com /pub/ﬁrewalls/isoc94.ps.Z

Thinking About Firewalls Ranum, Marcus J. Presented at SANSII, 1993.

http://www.tis.com/Home/NetworkSecurity/Firewalls/ThinkingFirewalls.html

ftp.tis.com /pub/ﬁrewalls/ﬁrewalls.ps.Z

A Toolkit and Methods for Internet Firewalls Avolio, Frederick M. and Ranum, Marcus J.

http://www.tis.com/Home/NetworkSecurity/Firewalls/Usenix.html

ftp.tis.com /pub/ﬁrewalls/usenix-paper.ps.Z

How to Get Latest Security Patches

The CD-ROM containing the Gauntlet ﬁrewall software contains necessary security patches (if any) at the time of product release, so be sure to install those patches. Stay in touch with the WWW site for Silicon Graphics Security Headquarters at http://www.sgi.com/Support/Secur/security.html for new security patches and security advisories. Be sure to install any security patches that replace patches found on your CD-ROM.

About This Guide

xxv

PART ONE

Understanding the Gauntlet Internet Firewall I

Chapter 1

1. Understanding the Gauntlet Firewall

The Gauntlet Internet Firewall is a hardware- and software-based ﬁrewall system that provides secure access and internetwork communications between private networks and public networks (such as the Internet), and between subnets of private networks. The ﬁrewall offers application-level security services for both incoming and outgoing communications based on existing security practices or an organization’s security policies.

If the paragraph above does not make any sense, do not despair. This chapter provides an overview of the Gauntlet Firewall and how it works. However, it is not a thorough discussion of ﬁrewalls or security practices. Consult “Additional Resources” on page xxiii for a list of other resources that provide excellent introductory and advanced discussions of ﬁrewalls.

Understanding Gauntlet Firewall Concepts

Simply put, a ﬁrewall is a single point of defense that protects one side from the other. In networking situations, this usually means protecting a company’s private network from other networks to which it is connected. Firewalls can be as simple as a router that ﬁlters packets or as complex as a multi-machine, multi-router solution that combines packet ﬁltering with application gateways.

Design Philosophy

The Gauntlet Internet Firewall exempliﬁes a minimalist and reductionist approach. Simple is better than complex. It follows this paradigm:

That which is not expressly permitted is prohibited.

The ﬁrewall will only allow activities which are explicitly set, either through system defaults or through your own conﬁgurations. New services can’t slip through the

Chapter 1: Understanding the Gauntlet Firewall

ﬁrewall unless you allow them through. You must be able to identify and remove any “back doors” that may be surreptitiously put into place.

All of the software is written with the idea that simplicity is an important advantage. The number of lines of code for the various proxies and utilities are smaller than their standard IRIX counterparts. This makes the programs readable, understandable, and less prone to having an error hidden in some complex programming structure. Also, the source code for the Gauntlet ﬁrewall is provided so anyone can examine and conﬁrm the programs operation. They are also examinable by any Gauntlet customer, not hidden away in some sort of black box. The security of the Gauntlet Internet ﬁrewall does not depend on secret algorithms or source code.

Recognizing that most security breaches occur through a compromised user account, the Gauntlet Internet Firewall generally has no user accounts. While you can setup an administrator account, users do not need to log into the ﬁrewall to access information on the other side.

The Gauntlet Internet Firewall is auditable, controllable, and conﬁgurable. You can conﬁgure many options to match your security policies. The software logs the speciﬁed activities and processes fore review, so that if you suspect a security breach you can look back to the log ﬁles to see if and when it might have happened.

Security Perimeter

Establishing a network security perimeter involves designating a network of machines that you wish to protect and deﬁning the mechanisms used to protect them. The ﬁrewall is the communications gateway for all hosts within the perimeter. To have a successful network security perimeter ,all communications to hosts inside the perimeter must pass through the ﬁrewall.

Trusted and Untrusted Networks

Y our ﬁr ewall must be conﬁgur ed to differ entiate between the “good guys” and the “bad guys.” The ﬁrewall makes this determination using information you provide about different networks. It understands three types of networks: trusted, untrusted, and unknown.

Understanding Gauntlet Firewall Concepts

Trusted Networks

T r usted networks are the networks inside your security perimeter. T rusted networks ar e usually the ones that you are trying to protect. Often, you or someone in your organization administers the machines on these networks. Y our organization controls the security measures for these networks. Usually, they are within the physical security perimeter . They can also be connected by links you control in a Virtual Private Network, as explained in Appendix C.

When you set up the ﬁrewall, you explicitly conﬁgure the networks your ﬁrewall can trust. After initial conﬁguration, the trusted networks usually include the ﬁrewall itself and all networks behind the ﬁrewall.

Untrusted Networks

Untrusted networks are the networks outside your security perimeter. They are untrusted because they are outside of your control or knowledge. You have no control over the administration or security policies for these sites. They are the ones from which you are trying to protect your network. However, you still need to and want to communicate with these networks, even though they are untrusted.

When you setup the ﬁrewall, you explicitly conﬁgure the networks from which your ﬁrewall can accept requests, but which it does not trust. By default, after initial conﬁguration, the untrusted networks are all networks outside the perimeter.

The ﬁrewall applies different policies (sets of rules) for r equests from untrusted networks than it does for requests from trusted networks. For some types of requests (including TELNET, FTP, rlogin, rsh, and POP3), the ﬁrewall may use additional authentication before processing the request. For others, the ﬁrewall may deny the request altogether.

Unknown Networks

Unknown networks are those networks that are neither trusted or untrusted. They are unknown quantities to the ﬁrewall because you have not explicitly told the ﬁrewall that this network is a trusted or an untrusted network. By default, there are no unknown networks because the default list of untrusted networks covers everything that is not a trusted network.

Chapter 1: Understanding the Gauntlet Firewall

Consider a company that lists its own networks as the trusted network. The company lists the networks for three clients as the untrusted networks. All other networks on the Internet are now unknown networks and cannot pass requests through the ﬁrewall.

Policy

Just as you have a general security policy for your organization, the Gauntlet Internet Firewall uses policies to summarize its rules. The policies are collections of rules about what the ﬁrewall can and cannot do in particular situations. They indicate which proxies can run, and whether they require authentication, special logging, or other general settings. The ﬁrewall policies, which you create, should be based on your site security policies.

By default, the Gauntlet ﬁrewall includes one set of policies for requests from trusted networks and one set of policies for requests from untrusted networks. The ﬁrewall determines which policy applies by the source IP address of the request. The default policy for trusted networks does not require users to authenticate; the default policy for untrusted networks does require users to authenticate. When installed, all services are turned off. It is up to you to enable the services which your site needs.

Transparency

T ranspar ency indicates that your ﬁrewall is not visible to your users as they work. They can continue to TELNET to client sites without having to explicitly stop at the ﬁrewall.

The default Gauntlet ﬁrewall conﬁguration implements transparency inside your ﬁrewall for your trusted networks. This is accomplished by creating default routes that send all requests to untrusted networks through the ﬁrewall and by certain conﬁguration options on the ﬁrewall.

In contrast, the ﬁrewall does not implement transparency for requests from untrusted networks. In this case, you want users to be aware that they are entering your site through your ﬁrewall.

The advantage of transparent access is that you do not need to reconﬁgure your client systems or learn new procedures in order to use supported services. Non-transparent access is supported, but users must learn procedures to perform their tasks.

Understanding Gauntlet Firewall Components

Hardware and Software

The Gauntlet ﬁrewall uses hardware and software to protect your network.

Hardware

The speciﬁc hardware components of the Gauntlet Internet Firewall are the network interfaces. Multiple network interface cards can be used to physically separate networks from one another.

Software

The software components of the ﬁrewall include a “hardened” operating system, application-level security services, security programs, and other management utilities.

Operating System

Understanding Gauntlet Firewall Components

The operating system is a version of the standard Silicon Graphic’s IRIX operating system, “hardened” by the Gauntlet software (see “Introductory Management Form” on page 118 for information on minimizing exposure while implementing the Gauntlet software.) All known security holes are patched as of the release of the Gauntlet pr oduct (refer to “How to Get Latest Security Patches” on page xxv for information on security patches.) As part of the ﬁrewall, the operating system has been tailored to provide support for only the services necessary to run the ﬁrewall. For example, source routing is not honored, and ICMP redirects ar e rejected. These services change the directions that routed packets ﬂow and could direct networks to circumvent the ﬁrewall. Services such as NFS®, NIS, and RPC cannot easily be made secure and so should be disabled (refer to “Introductory Management Form” on page 118 for more information on minimizing exposure.)

Unsupported network services do not just report an error to the requesting site. The operating system logs these access attempts, providing information about probes of your system.

Chapter 1: Understanding the Gauntlet Firewall

Application-Level Security Services (Proxies)

The software on the Gauntlet ﬁrewall includes security services on a per-application protocol basis. As noted above, all packets, and therefore all application requests, go to the ﬁrewall. On the ﬁrewall, proxy software relays information from one side of the ﬁrewall to the other. The proxy prevents the applications on outside networks from talking directly with the applications on your inside network, and vice versa. No IP packets pass directly from one side of the ﬁrewall to the other. All data is passed at the application level. (The “trusted ports” feature in this implementation is an exception to this generalization.)

Each application generally talks through a different pr oxy that understands the protocol for that application. Currently, the Gauntlet ﬁrewall includes proxies for the following types of services:

• Terminal services (TELNET and rlogin)

• Electronic mail (SMTP and POP3)

• File transfer services (FTP)

• Remote Execution (Rsh)

• Usenet news (NNTP)

• Web services (HTTP, SHTTP, SSL)

• Gopher services (Gopher, Gopher+)

• X Window services (X11)

• Printing services (lp)

• SQL services (Sybase SQL Server)

• Audio service (Real Audio)

In addition, the Gauntlet ﬁrewall includes a generic plug-board proxy. This proxy connects TCP trafﬁc from a particular port on one side of the ﬁrewall to a particular port on another system on the other side of the ﬁrewall. As with the service speciﬁc proxies, no IP packets pass directly from one side of the ﬁrewall to the other. If you have not installed a proxy for a service, that type of trafﬁc does not pass through the ﬁrewall.

Because the proxies use the same protocols to communicate as the applications, you do not need to modify the original client or server applications. For example, when the TELNET application connects to the ﬁrewall it and the proxy both communicate using

Understanding Gauntlet Firewall Components

the standard TELNET protocol in RFCs 764 and 854. You can continue to use the same TELNET application to connect to remote sites.

All of the proxies are conﬁgurable. You can accept or reject requests to or from certain sites and networks, or set up other rules that the proxies use when passing requests through the ﬁrewall. You can also enable or disable individual proxies and run only the ones that you need. You can easily translate your security policies into conﬁguration rules.

The proxies log all activities to and through the ﬁrewall. You can use the logs to gather usage statistics or to look for potential attacks.

In addition, several of the proxies support strong user authentication systems. These one-time passwords or security token systems provide additional security because each time users access the network they use a different password that cannot be reused if “sniffed” by an attacker.

Additional Features

The Gauntlet Firewall provides additional security by using the IRIX IP ﬁlter utility ipﬁlterd (see ipﬁlterd(1M)). This allows Gauntlet to check IP packets based on several criteria (for example, address and protocol) and processes or r ejects the packets. It detects spoofed packets claiming to be from one network that are actually from another network. This software also allows Gauntlet to be transparent to your users for most activities.

Management Utilities

In addition, the Gauntlet ﬁrewall also contains several programs that ease the job of administering the ﬁrewall. These include management tools for conﬁguring the ﬁrewall, scripts for reporting activity through the ﬁrewall, and performing general administration.

The gauntlet-admin administrative tool provides access for most standard conﬁguration activities. You do not need to modify system ﬁles or conﬁguration ﬁles unless you want to further customize your conﬁguration.

The Gauntlet Firewall also includes shell scripts that assist in creating backups and checking integrity.

Chapter 1: Understanding the Gauntlet Firewall

How a Firewall Works

Consider a company, Yoyodyne, that has a connection to the Internet via an Internet service provider (ISP). They have installed a Gauntlet Internet Firewall to protect their corporate network (yoyodyne.com) from all other hosts on the Internet. They are using the standard conﬁguration shown in Figure 1-1.

Internet

Router

How a Firewall Works

Gauntlet Internet Firewall

Internal network

Figure 1-1 Gauntlet Internet Firewall Standard Conﬁguration

The Yoyodyne network is ﬁrst separated from the rest of the Internet by a router. The router only passes trafﬁc from the Internet to the Gauntlet ﬁrewall when that trafﬁc is bound for some part of the Yoyodyne internal network. More sophisticated routers can additionally strengthen a companies security perimeter by implementing certain security functions such as “IP spooﬁng ﬁlters”.

Chapter 1: Understanding the Gauntlet Firewall

The ﬁrewall is helping to establish a security perimeter to protect the internal network. It screens all requests that need to pass from one side of the ﬁrewall to the other. Using rules Y oyodyne cr eated based on their security policies, the ﬁrewall determines whether to accept or pass requests through (at the application level) to the other side.

Dual-Homed Bastion Host

In order to protect the inside network, the ﬁrewall must be able to see all of the packets intended for hosts on the inside network. While there are a number of ways to physically and logically accomplish this, the recommended conﬁguration is the ﬁrewall machine installed as a dual-homed bastion host.

As a dual-homed bastion host, the ﬁrewall machine has two network interface cards, and thus two connections: one to your network and one to the outside, as shown in Figure 1-2.

Router

Internet

204.2

54.155

10.0.1.253

.25

How a Firewall Works

Gauntlet Internet Firewall

ec0

ec1

Internal network

Figure 1-2 Dual-Homed Bastion Host

All outside network trafﬁc enters and exits the ﬁrewall through one network interface, such as ec0. Similarly, all inside network trafﬁc enters and exits through a network interface, such as ec1. To accomplish this, each interface has a separate IP address. Yoyodyne was assigned the 204.254.155 network, and chose 204.254.155.253 as the outside IP address and 10.0.1.253 for the inside IP address.

Chapter 1: Understanding the Gauntlet Firewall

Note: You can also use two ﬁrewalls to create a virtual private network (or a virtual

network perimeter), exchanging encrypted information across an untrusted network. Because of United States government export regulations, this feature is generally not available outside the United States and Canada. Refer to Appendix C for more information.

Processing Packets and Requests

The ﬁrewall follows a standard set of steps for the packets it receives on either interface:

1. Receive packet.

2. Check source and destination.

3. Check request type.

4. Run appropriate program.

5. Process the request.

As we examine each step of the process, consider a Yoyodyne employee working at a client site (outside the perimeter) who needs access to a machine at work via TELNET.

Receive Packet

Routing information on outside hosts and at the ISP directs all requests for the company to the ﬁrewall. In addition, the domain name system (DNS) on the ﬁrewall and other outside DNS servers advertises the outside IP address of the ﬁrewall as the only way to connect to anything on the inside network. Hosts on the inside network use routing information to direct all requests for outside networks to the inside address of the ﬁrewall.

For example, the client company machines consult their routing information and pass the TELNET request along until it reaches the Yoyodyne ﬁrewall.

Check Source and Destination

Once the ﬁrewall receives a packet, it must determine what to do. First, the operating system examines the destination of the packet and determines whether it needs to deliver the packet locally. Local delivery includes packets destined for hosts inside the ﬁrewall. The ﬁrewall grabs these packets and gives them to an appropriate proxy. If there is no

How a Firewall Works

proxy conﬁgured to accept a packet, the ﬁrewall drops the packet and drops the failed access.

Next, the ﬁrewall examines the source address of the packet and the interface on which it received the packet. This process veriﬁes the information against conﬁguration tables, which prevents the ﬁrewall from accepting IP spoofed packets. If this check indicates that this request could not possibly have come in through this interface, it rejects the packet and logs it. For example, if the Yoyodyne ﬁrewall receives a packet on ec0 (the outside interface) claiming to be from 10.0.1.10 (an inside address), the ﬁrewall ignores the packet.

In our TELNET example, the destination of the packet is the ﬁrewall. The ﬁrewall receives request on ec0, the outside interface. The address does not indicate that it came from an inside network. The ﬁrewall accepts the packet for local delivery and processing.

Check Request Type

Now that the ﬁrewall is conﬁgured to deliver the packet locally, it looks at the contents of the packet. The operating system checks various tables on the ﬁrewall to determine if it offers the requested service on the requested port. If it does not, it logs the attempt as a potential security alert and rejects the request.

In our TELNET example, the packet indicates that it is a TELNET request on port 23. The conﬁguration tables indicate that the ﬁrewall supports this type of service.

Run Appropriate Program

Now that the ﬁrewall is conﬁgured to offer the requested service, the operating system uses other conﬁguration information to start the appropriate program. In our TELNET example, the ﬁrewall starts the TELNET proxy, which processes the TELNET request.

Process the Request

The proxy or application now processes the request. It ﬁrst checks its conﬁguration information. The proxy determines how to handle the request based on the source (IP address) of the request. By default, it uses one policy (set of rules) for trusted networks and another policy for untrusted networks.

Once conﬁgured, the proxy processes the requests as the standard application would. The proxies follow the same protocols and handshakes as indicated in the RFCs or other

Chapter 1: Understanding the Gauntlet Firewall

documents. Requesting applications think they are talking to an actual server, not a proxy.

The proxies also check to determine if the request is permitted for the destination. For some services, the proxies can perform the additional step of authenticating the user. This veriﬁcation provides additional assurance that the user is really who they says they are. The proxy then passes the request to the appropriate program on the other side of the ﬁrewall using the standard protocol for that service.

In our TELNET example, the TELNET proxy uses the generic outside policy because the request came from an outside network. The outside policy permits TELNET to internal machines, but requires authentication. The ﬁrewall prompts the user to authenticate. Once the user authenticates, the proxy provides a small menu allowing the user to indicate the internal machine to which they wish to connect. The proxy then uses standard TELNET protocol to pass packets back and forth between the host on the outside network and the host on the inside network.

PART TWO

Conﬁguring and Using Proxies II

Chapter 2

2. Managing SMTP Services

For many people, electronic mail is an integral tool for conducting business. Exchanging electronic mail is often the reason that sites decide they need to connect to the Internet. Such connections are not without risks.

The protocol for transferring mail around the Internet is the simple mail transport protocol (SMTP). The transfer requests are handled by a message transfer agent, such as the sendmail program used on IRIX systems. The sendmail program is large and requir es many privileges. Our design philosophy of reductionism frowns upon the direct use of sendmail as a critical security component of the Gauntlet Firewall. The Gauntlet Firewall includes a two-part proxy that securely handles the transfer of SMTP mail between the inside and outside networks.

This chapter explains the concepts behind the proxy and how it works, how to conﬁgure the proxy for SMTP mail transfer , and how to conﬁgure these services to r un through the ﬁrewall.

Understanding the Proxy

The proxy for SMTP is actually two different processes: a client (smap) and daemon (smapd). Together, they provide conﬁgurable access control and logging mechanisms. The processes, which run on the ﬁrewall, transfer mail between internal and external mail servers, based on rules you supply. You can also conﬁgure the message transfer agent that the ﬁrewall uses to deliver the messages to other hosts.

The proxies also prevent versions of sendmail on the inside network from talking with versions of sendmail on the outside network. The proxies log all successful and unsuccessful mail connections, and the number of bytes transferred.

Chapter 2: Managing SMTP Services

How It Works

The ﬁrewall runs the client proxy (smap) as a daemon listening for requests on the standard SMTP port (25). When the ﬁrewall receives requests for SMTP services on this port, the smap client collects the mail from the sender, logs the message, and places the mail in a temporary directory. Periodically, based on a conﬁgurable value (by default every 60 seconds), the daemon (smapd) wakes up and checks to see if there is any new mail. The smapd daemon checks the headers of the mail for formatting problems. It then calls the conﬁgured message transfer agent (usually sendmail in delivery mode) for ﬁnal delivery.

Both the smap client and the smapd daemon run using a user ID you specify, such as uucp. Rather than running as a root process as sendmail often does, the smap and smapd processes run with as few or as many privileges as you assign. In addition, both programs change their root directory to the transfer directory you specify.

A common policy is to have one mail hub for the inside network. In this scenario, outside networks know (via DNS) that they should send all mail for the domains (yoyodyne.com) on the inside networks to the ﬁrewall (ﬁrewall.yoyodyne.com) itself for processing. An outside host informs the ﬁrewall it has mail by connecting to smap on the SMTP port. The smap client collects the mail from the outside host and writes it to a directory (/var/spool/smap) on the ﬁrewall.

At some system administrator-conﬁgurable interval, the smapd daemon awakens and looks for new mail on the ﬁrewall. It parses the mail headers, and callssendmail to deliver the messages. sendmail checks its conﬁguration information, which tells it where to deliver mail. For example, its conﬁguration ﬁles may tell it to deliver internal mail to an internal mail hub (mail.yoyodyne.com), in which case sendmail will transfer the mail to the mail hub using SMTP.

Conﬁguring the Firewall for SMTP

Conﬁguring the Gauntlet ﬁrewall involves planning, conﬁguring the ﬁrewall, conﬁguring the proxies to enforce your policy, advertising your mail exchanger, and conﬁguring your internal mail hub.

Configuring the Firewall for SMTP

Planning

1. Understand your existing mail conﬁguration: hosts, hubs, and so on.

2. Plan early to make your DNS changes for mail records. This may require contacting

an outside organization providing DNS service, such as an internet service provider (ISP). We cannot stress enough the importance of this step.

Conﬁguring the Firewall

If you wish to allow SMTP trafﬁc through the ﬁrewall, conﬁgure the ﬁrewall using the gauntlet-admin interface. The interface stores this information using conﬁgmail in conjunction with the auto-conﬁguring version of the sendmail.cf conﬁguration ﬁle.

To conﬁgure the ﬁrewall for SMTP, follow these steps:

1. Enter the external hostname of your ﬁrewall. For example, in Figure 1-2, the

external hostname is the name assigned to the ec0 interface.

2. Enter the domain name of your ﬁrewall. For example, yoyodyne.com.

3. Enter the hostname or alias for all relay hosts. A relay is a host inside the ﬁrewall

that determines where to send mail with an unknown address (you might have only one relay).

4. Provide subdomains to be recognized if you want outgoing mail addresses

rewritten to keep subdomain information. The sendmail program transforms sender addresses from the user@host.domain format (penny@dimension.yoyodyne.com) into the user@domain format (penny@yoyodyne.com). Recognized subdomains will not be stripped off, so user@host.corp.domain is rewritten to user@corp.domain if corp is a recognized subdomain, or user@domain if corp is not a recognized subdomain.

Warning: This rewriting affects only certain sender lines (such as From:). It

does not hide the names of your internal machines in the Received and other headers.

If you need an internal mail hub or multiple mail hubs, you must further customize the sendmail.cf ﬁle on the ﬁrewall so that it delivers inbound email to your hub or hubs instead of delivering the mail directly. Refer to the IRIX Advanced Site and Server Administration Guide for more information.

Chapter 2: Managing SMTP Services

Conﬁguring Network Services

You do not need to modify the IRIX conﬁguration ﬁles on the ﬁrewall to support SMTP trafﬁc. This is a standard service, and you can use gauntlet-admin to modify the conﬁguration ﬁles. If you need to, you can instruct gauntlet-admin to not make modiﬁcations so you can make the customizations for your site.

Conﬁguring the Proxy Rules

You should not need to modify the proxy rules for SMTP services. If you do decide to modify /usr/gauntlet/conﬁg/template.netperm-table, you may wish to add the badadmin attribute for debugging purposes. Information sent to this alias aids greatly in debugging mail delivery problems. See Appendix B, “Netperm Table” for mor e information onsmap and smapd options, netperm-table options, and order of precedence.

Advertising the Firewall as a Mail Exchanger

You need to advertise the ﬁrewall as the mail exchange site for your domain. The DNS conﬁguration in gauntlet-admin can do this for you. Consult the section on DNS conﬁguration for speciﬁc instructions.

Conﬁguring Your Internal Mail Hub

As long as you are using transparency to pass all packets for outside networks to the ﬁrewall, you do not need to conﬁgure your internal mail hub or mail agents. Because of the transparency, attempts to deliver to outside network hosts will be grabbed by the ﬁrewall.

If you are not using transparency, conﬁgure your internal mail hub to use the ﬁrewall as a mail forwarder , and direct clients to the internal mail hub. If you don’t have an internal mail hub, conﬁgure the clients to use the ﬁrewall directly as a mail forwarder.

Using Mail

Verifying Your Setup

Verify your conﬁguration by sending mail from an inside host to an outside host. W atch the logs on the ﬁrewall for error messages. Run Mail in verbose mode and send mail to the bouncing service listed below, which automatically generates a reply:

dimension-23: Mail -v bouncer@bbnplanet.com Subject: Test Configuring Mail and the Gauntlet Firewall

This is a test. ^D

The verbose mode ensures that you see the details of the delivery. The bouncer service sends you a return message shortly.

If you need to test header rewriting or other custom conﬁgurations, consider starting sendmail in debug mode.

The ﬁrewall and the smap and smapd proxies for SMTP trafﬁc are transparent to the user once the ﬁrewall, and possibly client machines, are conﬁgured

Chapter 3

3. Managing POP3 Services

The number and variety of computer systems at company sites today is expanding rapidly and, for a variety of reasons, it is not convenient to run a full mail transfer system using SMTP on these systems. The Post Ofﬁce Protocol Version 3 (POP3) is one of the protocols that allow a workstation to access a mail server . The POP3 proxy included with the Gauntlet Firewall allows administrators to selectively allow outside hosts to exchange mail with a POP3 mail server through the ﬁrewall. The POP3 server must use APOP for authenticating the user.

This chapter explains the concepts behind the proxy and how it works, how to conﬁgure the proxy for POP3 mail transfer , and how to conﬁgure POP3 services to r un through the ﬁrewall.

Understanding the Proxy

The Gauntlet POP3 proxy is an application-level gateway that provides conﬁgurable access control, authentication, and logging mechanisms. The POP3 proxy, which runs on the ﬁrewall, transfers mail between external workstations and internal mail servers, based on rules you supply:

• source IP address

• source hostname

• destination IP address

• destination hostname

• user name

Using these options, you can conﬁgure your ﬁrewall to allow speciﬁc hosts on outside networks to exchange mail with an internal mail server via POP3. For example, an employee working with a laptop PC running Windows™ needs to read mail while on travel. The employee can use the mail user agent (such as Eudora Pro™) on the laptop to collect their mail from the mail server inside the perimeter. The proxy uses the APOP

Chapter 3: Managing POP3 Services

command (part of the POP3 protocol) for strong authentication. The proxy logs all successful and unsuccessful mail connections, and the number of bytes transferred.

You can manually conﬁgure the POP3 proxy to allow inside workstations to exchange mail with POP3 servers outside the perimeter. However, in most security policies (including the Gauntlet Firewall default), this is not considered a good idea. The POP3 protocol assumes that the SMTP proxy has already checked the formatting in the headers of incoming mail messages. In addition, allowing POP3 clients to communicate with outside mail servers adds another level of complexity. It bypasses the central control center of the inside mail hub, which rewrites addresses and enforces other company policies. Y our mail server should be behind the ﬁr ewall on the inside network. All POP3 clients on the inside network can collect their mail from this mail server.

How the POP3 Proxy Works

The ﬁrewall runs the POP3 proxy (pop3-gw) as a daemon listening for requests on the standard POP3 port (110). When the ﬁrewall receives requests for POP3 services on this port, the proxy checks its conﬁguration information (in the netperm-table ﬁle) and determines whether the initiating host has permission to use POP3 services. If the host does not have permission, the proxy logs the connection attempt and displays an error message.

If the host has permission, the POP3 proxy authenticates the user using APOP and logs the connection. The proxy then passes the message on to the POP3 server on the internal mail hub, and authenticates on behalf of the user using APOP. The proxy remains active until either side terminates the connection or Gauntlet times-out the connection.

The default Gauntlet policy allows users on outside (untrusted) hosts to connect to a speciﬁc internal mail server to collect mail. The ﬁrewall itself cannot run a POP3 server, because the POP3 proxy is running on the standard POP3 port.

Conﬁguring the Firewall for POP3

Conﬁguring the Gauntlet ﬁrewall involves planning, indicating which daemons the system will run, conﬁguring the proxy to enforce your policy, conﬁguring your internal POP3 server, and creating APOP accounts for users who will need to authenticate.

Configuring the Firewall for POP3

Planning

Determine your policies for

• source and destination addresses

• user access to POP3

Conﬁguring Network Services

You do not need to modify the IRIX conﬁguration ﬁles on the ﬁrewall to support POP3 trafﬁc.

Conﬁguring the Proxy Rules

If you are using the Gauntlet Firewall default conﬁguration, you need to modify the proxy rules for POP3 services. This involves accessing the gauntlet-admin Proxies form, where you can enter the name of the destination POP3 server and modify the timeout value if you desire. See Appendix B for more information on pop3-gw options,

netperm-table options, and order of precedence

Conﬁguring Your Internal POP3 Mail Server

Conﬁgure your internal POP3 mail server:

1. Conﬁgure your POP3 mail server to accept POP3 requests from the ﬁrewall. If you

need to specify an IP address, remember to use the internal IP address for the ﬁrewall.

2. Ensure that the POP3 mail server is using the POP3 port (110).

3. Conﬁgure your POP3 mail server to support APOP.

4. Conﬁgure the APOP password for each user.

Chapter 3: Managing POP3 Services

Setting APOP Passwords on the Firewall

Use the authentication management system to add users to the Gauntlet user authentication database for any users who need to authenticate when using POP3 services. See Chapter 18, “Creating Users” on page 181 for details.

Verifying Your Setup

Verify your setup by retrieving mail (using POP3) from a host outside the perimeter . See “Using POP3 to Exchange Mail” on page 28 for instructions.

Using POP3 to Exchange Mail

Because the POP3 proxy requires authentication, users must follow dif ferent pr ocedures to use POP3 services.

To retrieve electronic mail using POP3 with authentication, follow these steps:

Note that the order of these steps may differ for different user agents.

1. Conﬁgure the mail user agent and set the name of the POP3 server to the ﬁrewall.

2. Retrieve mail, causing the user agent to connect to the ﬁrewall.

3. Authenticate to the proxy by supplying your APOP password.

4. Continue as though the ﬁrewall were not there.

The example below shows a user named John working on an outside network who needs to retrieve mail from the mail server on the inside network.

First, John conﬁgures his mail reader to get his mail via POP3 from the ﬁrewall. Figure 3-1 shows the conﬁguration screen for Eudora Pro for Windows, a popular mail application.

Using POP3 to Exchange Mail

Figure 3-1 Eudora Pro Conﬁguration for APOP

John, working on his laptop (cavalier .yoyodyne.com) at home, conﬁgures his mail reader to connect to the ﬁrewall (ﬁrewall.yoyodyne.com) to get his mail.

Next, John retrieves his mail. As part of the connection, the proxy requests authentication information from the user agent, which prompts him.

After authenticating, the proxy transfers the request to the internal POP3 mail server (mail.yoyodyne.com), authenticates using the user’s POP password as stored on the ﬁrewall, and retrieves his mail.

Chapter 4

4. Managing Terminal Services

T erminal service access to other computers can be a vital part of many network activities. The TELNET and rlogin protocols are used for making these terminal connections, and they are not without risk. The Gauntlet Firewall includes proxies for both the TELNET and rlogin protocols, which securely handle terminal services between the inside and outside networks.

This chapter explains the concepts behind the TELNET and rlogin proxies and how they work, how to conﬁgure the proxies, and how to use terminal services.

Understanding the Proxies

The Gauntlet TELNET and rlogin proxies are application-level proxies that provide conﬁgurable access control, authentication, and logging mechanisms. The TELNET and rlogin proxies, which run on the ﬁrewall, pass TELNET and rlogin requests through the ﬁrewall, using rules you supply. The TELNET proxy also passes TN3270 requests through the ﬁrewall. You can conﬁgure the proxies to allow connections based on

• source IP address

• source hostname

• destination IP address

• destination hostname

Using these options, you can conﬁgure your ﬁrewall to allow speciﬁc hosts on outside networks to connect to inside hosts or vice versa. Employees working at customer sites can access their workstations inside the perimeter.

The strong authentication features of the proxies allow administrators to r equire users to authenticate before connecting. The proxies log all successful and unsuccessful connection attempts, and the amount of data transferred.

Chapter 4: Managing Terminal Services

Used together, these access controls and log ﬁles allow you to have much more control over the connections to and from your system than you have when you use the standard IRIX TELNET and rlogin programs.

Note that you can use the TELNET proxy without the rlogin proxy, or rlogin without TELNET. You can conﬁgure different policies for hosts and authentication, as well.

How the Proxies Work

In the default conﬁguration, the IRIX system runs the network access control daemon (netacl) as a daemon listening for requests on the standard TELNET port (23). Whenever the ﬁrewall receives a TELNET request on this port, the netacl daemon checks its conﬁguration information (in the netperm-table ﬁle) and determines whether the initiating host has permission to use TELNET. If the host has permission, the netacl daemon starts the standard TELNET program (telnetd) or the TELNET proxy (tn-gw), depending upon the originating host. If the host does not have permission, the daemon displays an error message. Similarly, the netacl daemon running on the standard login (513) starts either the rlogin daemon (rlogind) or the rlogin proxy (rlogin-gw).

The default policy for this scenario is to allow all inside hosts to initiate TELNET or rlogin sessions without authenticating. The inside host passes TELNET requests to the ﬁrewall, which starts the netacl daemon. The netacl daemon checks its permissions, and determines that the inside host can use TELNET . Thenetacl daemon starts the proxy . The proxy logs the transaction and passes the request to the outside host. The proxy r emains active until either side closes the connection.

The default policy for this scenario allows outside hosts to initiate TELNET or rlogin sessions after authenticating. The outside host passes TELNET requests to the ﬁrewall, which starts the netacl daemon. The netacl daemon checks its permissions, and determines that the outside host can use TELNET. The netacl daemon starts the proxy. The proxy prompts the user for authentication. If it is successful, the proxy pr ompts the user for the inside host, logs the transaction, and passes the request to the inside host. The proxy remains active until either side closes the connection.

Note that users are not logging into the ﬁrewall directly. While users use the proxy on the ﬁrewall for authentication, the proxy simply passes the user’s TELNET or rlogin session on to the appropriate host.

Configuring the Firewall for Terminal Services

If you need to log in remotely to the ﬁrewall, you must use netacl to start the proxies. In this conﬁguration, administrators on either inside or outside hosts initiate TELNET requests to the ﬁrewall, which accesses the netacl daemon. The netacl daemon checks its permissions, and determines that the host can use TELNET . Thenetacl daemon starts the proxy. The proxy prompts the user for authentication. If it is successful, the proxy prompts the user for the host and logs the transaction. When the user indicates a wish to connect to the ﬁrewall itself (by specifying the destination “localhost”), the netacl daemon reviews the destination and starts the actual IRIX TELNET daemon on the ﬁrewall, thereby connecting the user to the ﬁrewall.

Using the TELNET and Rlogin Proxies Without Network Access Control

In this scenario, the ﬁrewall runs the TELNET (tn-gw) or Rlogin (rlogin-gw) proxies as daemons listening for requests on the standard TELNET port (23) and Rlogin port (513). Common policies allow inside hosts to connect without authentication, and outside hosts to connect with authentication.

This conﬁguration using just the TELNET and Rlogin proxies (without the netacl daemon) prohibits running either TELNET or Rlogin on the ﬁrewall itself (which would allow you to login to the ﬁrewall remotely). Because the proxies are running on the standard TELNET and Rlogin ports on the ﬁrewall, all requests start the pr oxy. There is no way to start the TELNET and Rlogin daemons needed to service these requests on the standard ports.

Conﬁguring the Firewall for Terminal Services

Conﬁguring the Gauntlet ﬁrewall involves planning, conﬁguring the ﬁrewall, indicating which daemons the system will run, conﬁguring the proxies to enforce your policy, and adding the users who will need to authenticate to the Gauntlet user authentication database.

Planning

1. Determine whether you wish to allow TELNET and TN3270 connections through

the ﬁrewall.

2. Determine whether you wish to allow rlogin connections through the ﬁrewall.

Chapter 4: Managing Terminal Services

3. Determine whether you wish to allow remote access to the ﬁrewall itself. Working from the physical ﬁrewall console is more secur e than connecting from another host on a network. If you work remotely to administer the ﬁrewall, you risk disclosure of the user authentication management database and disclosure of the authentication passwords. However, when circumstances sometimes prohibit physical access to the ﬁrewall, the ﬁrewall can be conﬁgured to allow remote access.

4. Determine your policies for authentication.

Conﬁguring the Firewall

If you wish to allow remote system administrator login to the ﬁrewall itself, conﬁgure the ﬁrewall using the gauntlet-admin interface to permit remote logins.

This setting actually changes the settings in the netperm-table ﬁle so that the TELNET and rlogin proxies will start the actual TELNET and rlogin daemons when you try to connect to the ﬁrewall itself using the “localhost” host name.

Conﬁguring Network Services

You do not need to modify the IRIX conﬁguration ﬁles on the ﬁrewall to support TELNET or rlogin trafﬁc.

Conﬁguring the Proxy Rules

If you are using the Gauntlet Firewall default conﬁguration, you do not need to modify the proxy rules for TELNET, rlogin and TN3270services. If you have chosen different welcome or other messages, you must modify /usr/gauntlet/conﬁg/template.netperm-table to reﬂect your conﬁguration. See Appendix B, “Netperm Table” for mor e information on tn-gw and rlogin-gw options, netperm-table options, and order of precedence.

Note that the settings for the TELNET proxy (tn-gw) affect both TELNET and TN3270 access through the ﬁrewall.

Creating Authentication User Entries

Use the authentication management system to add users to the Gauntlet user authentication database for any users who need to authenticate when using TELNET and rlogin services. See Chapter 18, “Creating Users” on page 181 for more information.

Verifying Your Setup

Verify your conﬁguration by connecting to an inside host from an outside host. See the section below for instructions.

Using Terminal Services

TELNET, Rlogin, and TN3270 Without Authentication

You can conﬁgure the proxies so that they are transparent to your users. Enable transparent proxies using gauntlet-admin to conﬁgure the proxies so that users working on the trusted networks behind the ﬁrewall do not see a change in their daily TELNET, rlogin, and TN3270 activities. For example, a transparent TELNET through ﬁrewall.yoyoyne.com might look like this:

dimension-26: telnet blaze.clientsite.com Trying 10.0.2.120 port 23... Connected to blaze.clientsite.com BSDI BSD/OS 2.0.1 (blaze) (ttyp5) login:

Using Terminal Services

If you do not enable transparent proxies for terminal services, or if you require user authentication, users must ﬁrst access the corresponding ﬁrewall proxy with a terminal service and, once established on the ﬁrewall, they may then connect to a host outside. The next section describes how to connect through the ﬁrewall when user authentication is in force.

Chapter 4: Managing Terminal Services

TELNET and Rlogin With Authentication

If you have conﬁgured any terminal services to require authentication, users must follow different procedures to use TELNET or rlogin.

For example, to TELNET using authentication, follow these steps:

1. TELNET to the ﬁrewall itself.

2. Authenticate to the proxy.

3. Connect to the desired host.

4. Continue as before.

The default policy for the TELNET proxy is to authenticate all requests from untrusted networks to or through the ﬁrewall. The example below shows a sample TELNET session from an untrusted network to a trusted network, using S/Key authentication at the ﬁrewall.

blaze.clientsite.com-28: telnet firewall.yoyodyne.com Trying 204.255.154.100... Connected to firewall.yoyodyne.com

Escape character is '^]'. Username: scooter Skey Challenge: s/key 651 fi19289 SAFE DUB RISK CUE YARD NIL

tn-gw> c dimension Trying 10.0.1.120 port 23... Connected to dimension.yoyodyne.com BSDI BSD/OS 2.0.1 (dimension) (ttyp5) login: scooter Password: #########

Welcome to dimension.yoyodyne.com 3:57PM up 16 days, 5:35, 4 users, load averages: 0.03, 0.01, 0.00 dimension-26:

Using Terminal Services

In this example, Scooter, working at a client site (blaze.clientsite.com), needs TELNET access to the dimension.yoyodyne.com system behind the ﬁrewall. He ﬁrst telnets to the ﬁrewall for Yoyodyne (ﬁrewall.yoyodyne.com). The TELNET proxy on ﬁrewall prompts him to authenticate. Scooter provides his authentication user ID (scooter). When the proxy prompts, he enters the response to the authentication challenge. The proxy authenticates scooter.

Scooter now indicates the host he needs to access (dimension). The TELNET proxy connects Scooter to dimension, and the TELNET daemon running on that machine. The TELNET daemon on dimension prompts Scooter for his user name and password on dimension. The TELNET daemon on dimension veriﬁes Scooter’s user name and password, and logs him in.

TN3270 With Authentication

If you have conﬁgured terminal services to require authentication, users need to follow different procedures to use TN3270. To use TN3270 with authentication:

1. TN3270 to the ﬁrewall itself, disabling true TN3270 support for the initial

handshake

2. Authenticate to the proxy

3. Connect to the desired 3270 host

4. Continue as before

The corporate policy that requires authentication before using TELNET from untrusted hosts to trusted hosts also applies to using TN3270. Generally, the only difference is in starting the TN3270 client:

blaze-55: X3270 -model 2 -efont 3270-12 a: fire-out.yoyodyne.com

Chapter 5

5. Managing FTP Services

Sometimes the easiest way to transfer information from one machine to another is to actually transfer the relevant ﬁles. The ﬁle transfer protocol (FTP) is one of several protocols that make this possible. The Gauntlet ﬁrewall includes a proxy that securely allows the transfer of ﬁles between trusted and untrusted networks.

This chapter explains the concepts behind the FTP proxy and how it works, how to conﬁgure the proxy, and how to use FTP services. A section also discusses considerations for running anonymous FTP servers.

Understanding the FTP Proxy

The Gauntlet FTP proxy is an application-level proxy that provides conﬁgurable access control, authentication, and logging mechanisms.

The FTP proxy, which runs on the ﬁrewall, passes FTP requests through the ﬁrewall, using rules you supply. You can conﬁgure the FTP proxy to allow ﬁle transfer activity based on

• source IP address

• source hostname

• destination IP address

• destination hostname

• FTP command (for example, STOR and RETR)

Using these options, you can conﬁgure your ﬁrewall to allow speciﬁc hosts on outside networks to transfer ﬁles to and from inside hosts. Employees working at speciﬁc customer sites can access ﬁles on their workstations. Similarly, you can conﬁgure your ﬁrewall to permit users on the inside network to copy ﬁles (using the FTP daemon RETR command) from hosts on the outside network, but not place ﬁles (using the FTP daemon STOR command) on these outside hosts.

Chapter 5: Managing FTP Services

The strong authentication feature of the FTP proxy allows administrators to r equire users to authenticate before transferring ﬁles. The FTP proxy logs all successful and unsuccessful ﬁle transfer attempts, and the number of bytes transferred.

Used together, these access controls and log ﬁles allow you to have much more control over the ﬁles entering and leaving your system than using the standard IRIX FTP programs.

How the FTP Proxy Works

In this most common scenario, the ﬁrewall runs the network access control daemon (netacl) as a daemon listening for requests on the standard FTP port (21). Whenever it receives an FTP request on this port, the netacl daemon checks its conﬁguration information (in the netperm-table ﬁle) and determines whether the initiating host has permission to use FTP. If the host has permission, the netacl daemon starts the standard FTP server (ftpd) or the FTP proxy (ftp-gw). If the host does not have permission, the daemon displays an error message.

The default policy for this scenario is to allow all inside hosts to initiate FTP sessions and transfer ﬁles without authenticating. The inside host passes FTP requests to the ﬁrewall, which starts the netacl daemon. The netacl daemon checks its permissions, and determines that the inside host can use FTP. The netacl daemon starts the ftp-gw. The proxy logs the transaction and passes the request to the outside host. The ftp-gw remains active until either side terminates the connection. The default policy also allows outside hosts to initiate FTP sessions. However, they must authenticate before accessing inside hosts.

The default policy does not allow either inside or outside hosts to FTP directly to the ﬁrewall itself. If you conﬁgure your Gauntlet ﬁrewall to allow anonymous FTP to the ﬁrewall, hosts connect to the ﬁrewall with an FTP request. The ﬁrewall starts the netacl daemon. The netacl daemon checks its permissions, and determines that outside hosts can use FTP to the ﬁrewall itself. The netacl daemon starts the standard FTP daemon (in a chrooted environment).

This conﬁguration using netacl allows a fair amount of ﬂexibility in conﬁguring FTP services. Users inside the perimeter can continue to interact with outside hosts, generally without authentication. Users outside the perimeter can interact with inside hosts, generally with authentication.

Conﬁguring the Firewall for FTP Services

Conﬁguring the Gauntlet ﬁrewall involves planning, indicating which daemons the system will run, conﬁguring the FTP proxy to enforce your policy, and creating user accounts for users who will need to authenticate.

Planning

1. Determine whether you wish to allow outside hosts to FTP through the ﬁrewall to

inside hosts or to the ﬁrewall itself. This decision will determine whether or you need to use the network access control daemon.

2. Determine your policies for

• requiring authentication

• allowing speciﬁc FTP commands (for example, RETR and STOR)

• permitting or denying speciﬁc sources and destination

Conﬁguring Network Services

Configuring the Firewall for FTP Services

You do not need to modify the IRIX conﬁguration ﬁles on the ﬁrewall to support FTP trafﬁc.

Conﬁguring the Proxy Rules

If you are using the Gauntlet Firewall default conﬁguration, you do not need to modify the proxy rules for FTP services. Use the gauntlet-admin Proxies form if you want to enable FTP or anonymous FTP. If you have chosen a different denial message, you must modify /usr/gauntlet/conﬁg/template.netperm-table to reﬂect your conﬁguration. See Appendix B for more information on ftp-gw options, netperm-table options, and order of precedence.

Creating Authentication User Entries

Use the authentication management system to add users to the Gauntlet user authentication database for any users who need to authenticate when using FTP services. See “Creating Users” on page 181 for more information.

Chapter 5: Managing FTP Services

Verifying Your Setup

Verify your conﬁguration by transferring ﬁles to an inside host from an outside host. For example, connect to your favorite FTP site and download their README ﬁle. See the section below for instructions.

Using FTP Services

The idea behind the FTP proxy is that most users working on the trusted networks behind the ﬁrewall will not see a change in their daily FTP activities. The default policy allows users on trusted networks to FTP to untrusted networks without authenticating. Users on the trusted networks do not need to change their FTP procedures.

Using Authentication

If you have conﬁgured any FTP activities to require authentication, users must follow different procedures to use FTP.

To FTP using authentication, follow these steps:

1. FTP to the ﬁrewall itself.

2. Authenticate to the proxy.

3. Connect to the desired FTP server.

4. Continue as before.

A common policy for the FTP proxy is to authenticate all requests from untrusted networks to or through the ﬁrewall. The example below shows a sample FTP session from an untrusted network to a trusted network, using S/Key authentication at the ﬁrewall.

blaze.clientsite.com-27: ftp firewall.yoyodyne.com Connected to firewall.yoyodyne.com 220-Proxy first requires authentication

220 firewall.yoyodyne.com FTP proxy (Version 3.1) ready. Name (firewall.yoyodyne.com:clancy): clancy 331 Skey Challenge: s/key 653 fi19289 Password: <password does not display> 230 User authenticated to proxy

Using FTP Services

ftp> user clancy@dimension 331- (-----GATEWAY CONNECTED TO dimension----) 331- (220 dimension FTP server ready.) 331 Password required for clancy. Password: ######### 230 User clancy logged in. ftp>

In this example, the user Clancy , working at a client site (blaze.clientsite.com), needs FTP access to a machine behind the ﬁrewall (dimension.yoyodyne.com). He ﬁrst FTPs to the ﬁrewall for Yoyodyne (ﬁrewall.yoyodyne.com). The FTP proxy on ﬁrewall prompts him to authenticate. Clancy provides his authentication user ID (clancy). When the proxy prompts, he enters the response to the authentication challenge, which does not display. The proxy authenticates clancy.

Clancy indicates the host he needs to access and his user name for that host (clancy@dimension). The FTP proxy connects Clancy to dimension and prompts him for his password on dimension. Clancy enters his password for dimension. The FTP server on dimension veriﬁes Clancy’s user name and password, and logs him in. Clancy can now transfer ﬁles using regular FTP commands.

Using Authentication With Some GUI FTP Tools

The FTP proxy can require you to authenticate twice. Some GUI FTP tools for Micr osoft Windows™ and the Macintosh® require you to specify the user name and password in a dialog box. These tools assume that once you supply this information, you are connected.

The FTP proxy displays the challenge and response information for authentication in FTP comments. Some Microsoft W indows and Macintosh operating system FTP tools do not display FTP comments. Unless users see the comment, they will have a really difﬁcult time trying to guess the current challenge. You can still use these FTP tools with S/key authentication, by combining the authentication and FTP host information.

To authenticate using some GUI tools, follow these steps:

1. For the hostname, supply the name of the ﬁrewall.

2. For the user name, supply the ﬁrewall authentication user name, the FTP host user

name, and the name of the FTP host, in the form

authentication-username@ftp-host-username@ftp-host.

Chapter 5: Managing FTP Services

3. For the password, supply the authentication response and the FTP host password in the form

authentication-response@ftp-host-password

You may need to TELNET to the ﬁrewall to see what the next challenge is.

The example below shows the information a user would enter in their FTP tool when going from an untrusted network to a trusted network, using S/Key authentication for the ﬁrewall:

host:firewall.yoyodyne.com username:clancy@clancy@dimension password:elk elba iris odd skim lee@#########

Because you cannot tell what the next challenge will be when using most other challenge-response authentication mechanisms, you may not be able to use these instructions with some GUI FTP tools.

Running an Anonymous FTP Server

By its very nature, an anonymous FTP server requires easy access by the public. If you place the anonymous FTP server behind the ﬁrewall, you are allowing an additional type of access within your security perimeter . If you place the FTP server on the ﬁrewall itself, you are allowing additional access to your ﬁrewall. Evaluate both setups for the possible security risks to your site and how your site security policy addresses this type of access.

Gauntlet for IRIX allows you to run the standard IRIX FTP server (ftpd) in an isolated chrooted environment as an anonymous FTP server (but you give up the ability to allow authenticated users from untrusted networks to use ftp-gw to access trusted networks).

The best solution is generally to place your anonymous FTP server on a machine outside the perimeter. Follow good host-oriented security practices for this machine:

• Turn off all other services.

• Create the minimum number of user accounts.

• Use strong authentication.

• Patch your operating system and applications with all current security patches.

Running an Anonymous FTP Server

• Use checksums to watch for ﬁle changes.

• Back up frequently.

You can also use the Info Server included with the Gauntlet ﬁrewall as an anonymous FTP server on the ﬁrewall itself. See “FTP Server” on page 102 for more information.

Chapter 6

6. Managing Rsh Services

Administration and support activities can be easier when you can just execute a shell on a remote machine. The Rsh service allows users to do this. The Rsh program is not without risks: it runs programs on another machine and requires some privileges to login. The Gauntlet ﬁrewall includes a proxy that securely handles the execution of Rsh requests from machines inside the network to machines outside the network.

This chapter explains the concepts behind the Rsh proxy and how it works, how to conﬁgure the proxy, and how to use Rsh services.

Understanding the Rsh Proxy

The Gauntlet Rsh proxy is an application level gateway that provides conﬁgurable access control, authentication and logging mechanisms. The Rsh proxy, which runs on the ﬁrewall, passes Rsh requests through the ﬁrewall, using rules you supply. You can conﬁgure the Rsh proxy to allow remote shell activity based on:

• source IP address

• source host name

• destination IP address

• destination host name

Using these options, you can conﬁgure your ﬁrewall to allow speciﬁc hosts on the inside network to start remote shells on outside hosts. Employees working behind the ﬁrewall can start remote shells on outside hosts at a customer site. The Rsh proxy logs all successful and unsuccessful remote shell attempts, and the number of bytes transferred.

These access controls allow you to have much more control over the Rsh requests entering and leaving your system than using the standard UNIX Rsh program. The logging capabilities are also much more extensive.

Chapter 6: Managing Rsh Services

How It Works

In this default conﬁguration, the ﬁrewall runs the Rsh proxy (rsh-gw) as a daemon listening for requests on the standard Rsh port (514). Whenever the system receives an

Rsh request on this port, the Rsh proxy checks its conﬁguration information (in the

netperm-table) and determines whether the initiating host has permission to use Rsh. If the

host has permission, the proxy logs the transaction and passes the request to the outside host. The rsh-gw remains active until either side closes the connection.

The default policy for this scenario allows inside hosts to Rsh without authenticating. Users on inside hosts can continue to Rsh as they did before the ﬁrewall was put into place. The default policy does not allow outside hosts to Rsh to hosts inside the perimeter.

The default policy and conﬁguration using just the Rsh proxy prohibit running an Rsh server on the ﬁrewall itself. Because the Rsh proxy is running on the standard Rsh port on the ﬁrewall all Rsh requests start the proxy. There is no way to start the Rsh daemon needed to service Rsh requests.

Conﬁguring the Firewall for Rsh Services

Conﬁguring the Gauntlet ﬁrewall involves planning, indicating which daemons the system will run, conﬁguring the Rsh proxy to enforce your policy, turning on the proxy, and rebooting your ﬁrewall.

Planning

Determine whether you wish to allow inside hosts to Rsh through the ﬁrewall to outside hosts.

Conﬁguring Network Services

You do not need to modify the UNIX conﬁguration ﬁles on the ﬁrewall to support Rsh trafﬁc.

Using Rsh Services

Conﬁguring the Proxy Rules

Conﬁgure the Rsh proxy to enforce your security policies. This involves modifying

/usr/local/etc/netperm-table. See Appendix B for more information on rsh-gw options,

netperm-table options and order of precedence. To conﬁgure the netperm-table:

1. Add the Rsh proxy to your trusted policies, as appropriate.

policy-trusted:permit-proxy rsh-gw

2. Conﬁgure other Rsh proxy options, as appropriate for your setup. These could

include the default directory and timeout values.

#Rsh proxy rules rsh-gw: timeout 300

Verifying Your Setup

Verify your conﬁguration by accessing a machine outside the perimeter from a machine inside the perimeter.

Using Rsh Services

Following some initial conﬁguration, the ﬁrewall and thersh-gw proxy are transparent to the user. Users can continue to use rsh to outside hosts as they did before.

Conﬁguring the Remote Machine

Before using Rsh, users must add their user name and the name of the ﬁrewall to their

.rhosts ﬁle on the remote machine:

user@ﬁrewall

where:

1. user is their user name within the domain from which the request comes. The user

does not actually need to have an account on the ﬁrewall itself. The Rsh request simply appears to be coming from the ﬁrewall.

2. ﬁrewall is the name (including domain if necessary) of the ﬁrewall. This name

should be the name of the interface on ﬁrewall closest to the remote machine.

Chapter 6: Managing Rsh Services

For example, Penny, who works at Yoyodyne, needs to execute something remotely using her account at Big University. She adds a line to the .rhosts ﬁle in her account at Big University:

penny@fire-out.yoyodyne.com

Chapter 7

7. Managing Gopher and WWW Services

What can we say about the W orld Wide Web? Your users probably argue that they really need it to do their jobs. There is a vast wealth of information stored on machines connected the Internet. The graphical interfaces of browsers and web pages make it much easier to access and digest this information. Along with this ease can come problems. World Wide Web (WWW) services allow for the transfer of a wide variety of ﬁle types and for running a number of different programs. This complexity means a greater potential for problems, especially in terms of security. These services are generic ﬁle transfer mechanisms and require logging and access control consistent with FTP and terminal services.

The HTTP proxy and authenticating HTTP proxy included with the Gauntlet Firewall securely handles requests for information via hypertext, Gopher, and ﬁle transfer. The proxy supports hypertext transfer via the HTTP, SHTTP, and SSL protocols; Gopher transfer via Gopher and Gopher+ protocols; and ﬁle transfer via FTP.

This chapter explains the concepts behind the HTTP proxy and how it works; how to conﬁgure the proxy for web services, Gopher services, and ﬁle transfer services; and how to conﬁgure these services to run through the ﬁrewall. In addition, it includes information on running HTTP and Gopher servers.

Understanding the Proxy

The Gauntlet HTTP proxy is an application-level proxy that provides conﬁgurable access control and logging mechanisms. The HTTP proxy, which runs on the ﬁrewall, passes HTTP, SHTTP, SSL, and Gopher requests, and FTP URLs and selectors through the ﬁrewall, using rules you supply. Y ou can conﬁgure the pr oxy to allow connections based on

• source IP address

• source hostname

Chapter 7: Managing Gopher and WWW Services

• destination IP address

• destination hostname

Using these options, you can conﬁgure your ﬁrewall to allow clients on the inside network to access Gopher sites on the outside network. You can also limit the web sites your employees can access from machines on the inside network. The proxies log all successful and unsuccessful connection attempts, and the amount of data transferred.

The Gauntlet authenticating HTTP proxy works in conjunction with the HTTP proxy to authenticate users. Using the authenticating HTTP proxy, you can conﬁgure the proxy to allow connections based on username. Y ou can require all users to user str ong or weak authentication before accessing information on the outside network.

You can conﬁgure the HTTP proxy to allow outside hosts to access web and Gopher servers behind your ﬁrewall on inside networks. However, in most security policies (including the Gauntlet Firewall default), this is not considered secure. By design, these services require easy access by people all over the Internet, and having a separate host outside the ﬁrewall is best. See the section on “Conﬁguring the Firewall for WWW and Gopher Services” at the end of this chapter.

How It Works

The IRIX system runs the HTTP proxy as a daemon listening for requests on the HTTP port (8080) and/or the gopher port. When the ﬁrewall receives requests for services (via HTTP, SHTTP, SSL, Gopher, or Gopher+), the proxy looks at the request and places it in one of several categories. The proxy then checks the appropriate conﬁguration information (in the netperm-table ﬁle) and determines whether the initiating host has permission to use the desired service to the desired destination. If the host does not have permission, the proxy logs the connection and displays an error message.

If the host has permission, the http-gw proxy passes the request to the desired host using the standard port (or the port speciﬁed in the request). As the outside host returns data to the requesting client, the ﬁrewall translates the data into the form the client expects and returns the data to the client. The proxy remains active until either side terminates the connection.

The default conﬁguration for HTTP requests allows all inside hosts to access any WWW sites. In this scenario, the web browser on the inside host passes a request with a URL for a particular web page to the ﬁrewall on port 80. The request is received by the http-gw

How It Works

proxy. The proxy examines the request and determines that it is a basic request for HTTP service. The proxy checks the source and destination ports in thenetperm-table ﬁle. It then sends the request to the web server speciﬁed in the URL. When it receives the requested data, it passes the data back to the requesting web browser.

If the request is for Gopher or FTP services (from a Web or Gopher client), it is still the http-gw proxy which receives the request, and it still uses the http-gw rules.

If the request is for some sort of secure HTTP transaction using either the SHTTP or SSL protocols, the proxy performs the appropriate hand-off with the secure server at the other end of the connection.

If you have not conﬁgured or can not conﬁgure the web browser to know about the HTTP proxy, the ﬁrewall still calls the HTTP proxy for requests on port 80. However, it does not handle requests for services on other ports (for example, 8080). You can, however, run a second or even a third HTTP proxy on popular alternate ports.

Authenticated HTTP

If you want to authenticate users before allowing them to access information, the ﬁrewall runs the authenticating HTTP proxy (ahttp-gw) as a daemon listening for requests on the HTTP port (8080). When the ﬁrewall receives requests for service on this port, it performs the normal conﬁguration checks to ensure that the initiating host has permission to use the desired service to the desired destination.

If the host has permission, ahttp-gw prompts the user to authenticate. It veriﬁes the information with Gauntlet authentication database. If the user provided proper authentication, ahttp-gw passes processing over to the HTTP proxy.

The proxy remains active as long as a persistent connection between the source and destination remains. Each time the connection breaks (due to inactivity, pressing the stop button, or selecting a link before the initial page ﬁnishes loading, or any other reason), the ahttp-gw proxy reauthenticates you. If you are using reusable passwords, your browser remembers this information and reauthenticates on your behalf. If you are using strong authentication, you must reauthenticate each time the connection breaks.

Chapter 7: Managing Gopher and WWW Services

Gopher and FTP Services

If the request is for Gopher services (from a Web or Gopher client), the ﬁrewall calls a second copy of the http-gw proxy, running as http-gw on port 70. It still uses the http-gw rules in the netperm-table.

If the request is for FTP services (from a Web client), the ﬁrewall still calls the http-gw proxy and uses the http-gw rules in the netperm-table if you have your FTP proxy set to the HTTP proxy. If you have not set an FTP proxy in your Web browser, the FTP proxy (ftp-gw) handles requests for FTP service.

SHTTP and SSL Services

If the request is for some sort of secure HTTP transaction using either the SHTTP protocol (on port 8080) or SSL protocol (on port 443), the proxy performs the appropriate hand-of f with the secure server at the other end of the connection.

If you have not conﬁgured or can not conﬁgure the web browser to know about the HTTP proxy as the security proxy, the ﬁrewall calls the SSL plug proxy for all requests on port

443.

Conﬁguring the Firewall for WWW and Gopher Services

Conﬁguring the Gauntlet ﬁrewall involves planning, indicating which daemons the system will run, and conﬁguring the proxies to enforce your policy.

Planning

1. Determine which services you will allow.

2. Determine your policies for source and destination sites.

3. Determine whether you wish to require authentication.

Using Web Services

Conﬁguring Network Services

You do not need to modify the IRIX conﬁguration ﬁles on the ﬁrewall to support HTTP, SHTTP, SSL, Gopher, or FTP.

Conﬁguring the Proxy Rules

If you are using the Gauntlet Firewall default conﬁguration, you do not need to modify the proxy rules for HTTP and Gopher services. If you have chosen other options, you must modify /usr/gauntlet/conﬁg/template.netperm-table to reﬂect your conﬁguration. See Appendix B for more information on http-gw options, netperm-table options, and order of precedence. Remember that the HTTP proxy uses its own rules for FTP transfers. If you have denied a particular site for the FTP proxy, you will want to deny it for the HTTP proxy as well.

Creating User Authentication Entries

Use the authentication management system to create authentication user entries for any users who authenticate when using the authenticating HTTP proxy. See Chapter 17 for more information. Consider using multiple authentication servers (as explained on page

6) if you wish to require strong authentication for other inbound services and weak authentication for outbound HTTP requests.

Using Web Services

Verifying Your Setup

Verify your setup by connecting to some of your favorite WWW, Gopher, and FTP sites. Connect to secure Web sites as well. See the section below for speciﬁc conﬁguration instructions.

Once you have conﬁgured a proxy-aware Web browser, the HTTP proxy is generally transparent to the user . When using a br owser that does not support pr oxies, users need to modify their activities.

Chapter 7: Managing Gopher and WWW Services

If you are using the authenticating HTTP proxy, users must use a proxy-aware browser. It must support persistent connections if you wish to use strong authentication. Once you have conﬁgured their web browser, they are aware of the proxy because they must authenticate to access outside sites.

Using Proxy-Aware Browsers

Many Web browsers, such as Netscape and Mosaic are aware of application proxies for different types of Web services. Once you conﬁgure these browsers, the browser sends the request to the appropriate proxy.

If you are using the authenticating HTTP proxy, ensure that the browser supports proxy authentication and persistent connections.

Conﬁguring Web Browsers

The steps vary depending upon the browser, operating system, and version. Some browsers allow you to indicate the information using a dialog box from a preferences menu, while others require you to edit a conﬁguration ﬁle, and others use environment variables.

If you are using the authenticating HTTP proxy, ensure that the browser supports proxy authentication and persistent connections.

To conﬁgure the browser, follow these steps:

1. Specify that you can only have one network connection at a time if you are using the authenticating HTTP proxy with strong authentication.

2. Specify the name of the ﬁrewall for the HTTP proxy and port 8080 as the HTTP port.

3. Specify the name of the ﬁrewall for the Gopher proxy and port 8080 as the Gopher port.

4. Specify the name of the ﬁrewall for the FTP proxy and port 8080 as the FTP port. Note that this is not the standard FTP port 23. When the ﬁrewall receives an FTP request on port 8080, the http-gw proxy does the actual FTP processing, not the ftp-gw proxy. This is because Web browsers use the HTTP protocol to communicate with the ﬁrewall proxy, not the FTP protocol.

5. Specify the name of the ﬁrewall for the security proxy and port 8080 as the security port.

Using Web Services

6. Specify the names of hosts for which you do not want to access the HTTP proxy in

the No Proxy section. These are generally hosts on your trusted networks. These include:

• inside IP address of your ﬁrewall (if you plan to use the graphical user interface to conﬁgure your ﬁrewall)

• host names of any internal or corporate HTTP servers

• localhost (127.0.0.1)

Note that if you use the IP address instead of the hostname, you must use the internal IP address of the ﬁrewall.

Figure 7-1 shows the conﬁguration screen for version 2.0 of Netscape Navigator™ for Microsoft Windows.

Figure 7-1 Proxy Conﬁguration for Netscape Navigator 2.0 for Windows

Accessing Web Services Without Authentication

Once conﬁgured, the proxy is transparent to the user. Users can continue to access the Web as they did before.

Chapter 7: Managing Gopher and WWW Services

If you have conﬁgured the proxies to block certain types of services (for example, no Gopher services) or to block certain destinations (for example, no educational [.edu] sites) users do see your denial messages.

Accessing Web Services with Authentication

Once conﬁgured, users are aware of the pr oxy . In a particular session, the pr oxy prompts for authentication the ﬁrst time you attempt to access a site on the outside network.

To use web service using weak authentication:

1. Open a URL

2. Authenticate to the proxy

3. Continue as before

Weak Authentication

If you are using weak authentication, enter your username and password when your browser prompts you to. The proxy r emembers this information and reauthenticates you if the connection breaks.

Strong Authentication

If you are using strong authentication, enter your username when your browser pr ompts you to. The proxy uses your user name to determine the type of authentication you are using. It prompts you a second time with the appropriate challenge. Enter your username and your response. Be prepared to reauthenticate each time your connection breaks.

Using Non-Proxy-Aware Browsers

Some older Web browsers are not aware of proxies. Using these browsers, you must explicitly send your requests through the ﬁrewall.

Conﬁguring Web Browsers

The steps vary depending upon the browser, operating system, and version.

T o conﬁgur e the browser, set up the default home page as the name of the ﬁrewall, using the internal ﬁrewall name, for example:

http://firewall.yoyodyne.com:8080

Accessing Web Services

For regular use of a web browser, if you cannot create a default home page, preﬁx each URL you enter with the internal name of the ﬁrewall and the proxy port. For example:

http://www.clientsite.com

becomes

http://firewall:8080/http://www.clientsite.com

where ﬁrewall is the hostname of the ﬁrewall (ﬁrewall.yoyodyne.com). You must also prepend all saved URLs in bookmarks and hotlists.

Using Gopher Services

The ﬁrewall conﬁguration for the http-gw proxy for Gopher services is transparent to the user if transparent proxies have been enabled using gauntlet-admin. Users can continue to point their Gopher clients to Gopher servers as they did before.

If you have disabled transparent proxies, then users must rewrite each Gopher addr ess. If a user has a set of bookmarks for Gopher servers that was created before you installed the ﬁrewall, the user must modify the bookmark information to include the name of the ﬁrewall. For example:

name: Big University Gopher Server host: gopher.bigu.edu port: 70 path:

becomes

name: Big University Gopher Server host: firewall.yoyodyne.com port: 8080 path: gopher://gopher.bigu.edu:70

Chapter 7: Managing Gopher and WWW Services

Running a WWW Server

By its very nature, a WWW server requires easy access by the public. If you place the WWW server behind the ﬁrewall, you are allowing an additional type of access within your security perimeter. If you place the WWW server on the ﬁrewall itself, you are allowing additional access to your ﬁrewall. Furthermore, most WWW servers are large and complicated pieces of software, and running such software on the ﬁrewall incr eases the likelihood that someone may be able to exploit bugs in the WWW server to break into your ﬁrewall

The best solution is generally to place your WWW server on a separate machine outside the perimeter. Follow good host-oriented security practices for this machine:

• Turn off all other services.

• Create the minimum number of user accounts.

• Use strong authentication.

• Patch your operating system and applications with the latest patches, especially security patches.

• Use checksums to watch for ﬁle changes.

• Back up frequently.

You can also use the Info Server included with the Gauntlet ﬁrewall as a WWW server on the ﬁrewall itself. See Chapter 15, “Managing Information Services on the Firewall,” for more information.

Chapter 8

8. Managing RealAudio Services

More and more people wish to listen to audio ﬁles found at sites on the Internet. As with other protocols, access to these ﬁles is not without risk, so they require logging and access control, as with other services.

The RealAudio protocol allows people to play and listen to audio material. The Gauntlet Firewall includes a RealAudio proxy that securely handles requests to listen to audio data.

This chapter explains the concepts behind the RealAudio proxy, how it works, and how to conﬁgure and use it.

Understanding the RealAudio Proxy

The Gauntlet RealAudio proxy is an application level proxy that provides conﬁgurable access control. The proxy, which runs on the ﬁrewall, passes RealAudio client requests through the ﬁrewall, using rules you supply. You can conﬁgure the RealAudio proxy to allow connections based on:

• source host name

• source IP address

• destination host name

• destination IP address

Using these options, you can conﬁgure the ﬁrewall to allow RealAudio clients on the inside network to access RealAudio servers on the outside network. You can also limit the RealAudio sites your users can access from machines on the inside network. The RealAudio proxy also logs all successful and unsuccessful connection attempts, as well as the amount of data transferred.

Note: You cannot conﬁgure the RealAudio proxy to allow access to RealAudio servers

that you have placed on the inside network.

Chapter 8: Managing RealAudio Services

Used together, these access controls and log ﬁles give you much more control over the RealAudio connections to and from your system than you would have without the ﬁrewall.

How It Works

The ﬁrewall runs the RealAudio proxy (rap-gw) as a daemon listening for requests on the default RealAudio port (7070). When the ﬁrewall receives requests for services on this port, the RealAudio proxy checks its conﬁguration information (in the netperm-table ﬁle) and determines whether the initiating host has permission to use RealAudio. If the host has permission, the proxy logs the transaction and passes the request to the outside host. The rap-gw daemon remains active until either side closes the connection. This proxy running on the RealAudio port 7070 only works if you have enabled transparent proxies. It does not require RealAudio players which can be conﬁgured to explicitly use a proxy.

The ﬁrewall also runs the proxy on the default RealAudio proxy port (1080). The proxy works as described above. However, you must conﬁgure your RealAudio player to use the RealAudio proxy that is running on port 1080. Only recent RealAudio players can be conﬁgured explicitly to use the RealAudio proxy on port 1080. The transparent proxy feature does not need to be enabled in this case.

The default policy allows inside hosts to use RealAudio. Users on inside hosts can continue to access RealAudio servers on outside hosts to download audio ﬁles and listen to live broadcasts.

The default policy does not allow outside hosts to connect to RealAudio servers running on the inside network.

This conﬁguration prohibits running a RealAudio server on the ﬁrewall itself. Because the RealAudio proxy is running on the RealAudio default player port on the ﬁrewall, all RealAudio requests access the proxy. There is no way to start the RealAudio server daemon needed to service RealAudio requests.

Conﬁguring the Firewall to Use the RealAudio Proxy

Conﬁguring the Gauntlet ﬁrewall involves planning, indicating which daemons the system will run, and conﬁguring the RealAudio proxy to enforce your policy.

Using the RealAudio Proxy

Planning

Determine which internal users and hosts can use these services, and determine whether you want to run the RealAudio proxy transparently on port 7070, or on port 1080.

Conﬁguring Network Services

You do not need to modify the IRIX conﬁguration ﬁles on the ﬁrewall to support the RealAudio server. This is a standard service, included in the default versions of these conﬁguration ﬁles on the Gauntlet ﬁrewall.

Conﬁguring the Proxy Rules

If you are using the Gauntlet ﬁrewall default conﬁguration, you do not need to modify the proxy rules for the RealAudio server. To enable the RealAudio server, use the gauntlet-admin Proxies form to enable the server.

Alternatively, you may modify /usr/gauntlet/conﬁg/template.netperm-table to reﬂect your conﬁguration. See Appendix B for more information on rap-gw options, netperm-table options, and order of precedence.

Verifying Your Setup

Verify your installation by using your RealAudio player to listen to audio ﬁles or live broadcasts from hosts on the outside network. See the section below for instructions.

Using the RealAudio Proxy

Most users and most sites do not need to change the way they access RealAudio ﬁles after installing the RealAudio proxy.

If you are using transparency on your ﬁrewall and you have installed the RealAudio proxy on the RealAudio default player port (7070), you do not need to change the way you access RealAudio ﬁles.

Chapter 8: Managing RealAudio Services

If you are not using transparency or you have installed the ﬁrewall on the RealAudio default proxy port (1080), you need to conﬁgure your RealAudio player to know about the proxy and the other port.

To conﬁgure the RealAudio player:

1. Select View.

2. Select Preferences.

3. Select Proxy.

4. Check the Use Proxy box.

5. Enter as the host the name for the inside interface of your ﬁrewall.

Now, when you point your web browser or RealAudio player at a RealAudio ﬁle, they use the proxy.

Chapter 9

9. Managing MediaBase Services

MediaBase is a collection of multimedia and hypertext that allows users to select and play videos using their W eb br owser. The Gauntlet Firewall includes a MediaBase proxy that securely handles outside user requests to view video data on a MediaBase server inside the ﬁrewall. This proxy also allows users inside the ﬁrewall to access MediaBase servers on outside networks.

This chapter explains the concepts behind the MediaBase proxy and how it works.

Note: For additional information on setting up the Gauntlet ﬁrewall for MediaBase, see

“Conﬁguring a MediaBase Proxy for the Gauntlet Internet Firewall” in the WebFORCE MediaBase Administrator’s Guide.

Understanding the MediaBase Proxy

The Gauntlet MediaBase proxy is an application level proxy that provides conﬁgurable access control. The proxy, which runs on the ﬁrewall, passes MediaBase client and server requests through the ﬁrewall, using rules that you supply. You can conﬁgure the MediaBase proxy to allow connections based on:

• source host name

• source IP address

• destination host name

• destination IP address

Using these options, you can conﬁgure the ﬁrewall to allow MediaBase clients on the inside network to access MediaBase servers on the outside network. You can also limit the MediaBase sites your users can access from machines on the inside network.

By default, verbose logging is not enabled on the MediaBase proxy. If you enable verbose logging, information on all connections is logged.

Chapter 9: Managing MediaBase Services

Used together, these access controls and log ﬁles give you much more control over the MediaBase connections to and from your system than you would have without the ﬁrewall.

How It Works

The ﬁrewall runs the MediaBase proxy (mbase-gw) as a daemon listening for requests on a series of ports: ports 6301, 6309, 6310, 6312, and 6313 handle control information; ports 6320 through 6323 and 6340 handle data information. When the ﬁrewall receives r equests for those ports, the MediaBase proxy checks its conﬁguration information (in the netperm-table ﬁle) and determines whether the initiating client has permission to use MediaBase. If the client has permission, the proxy logs the transaction and passes the request to the appropriate host.

The mbase-gw daemon is always active. This daemon requires that MediaBase players also be conﬁgured to use a proxy.

The default policy allows clients inside the network to connect to MediaBase servers; it does not allow outside clients such access, however. Because the ﬁrewall runs the MediaBase proxy on all MediaBase ports, all requests from outside clients access the MediaBase proxy rather than the server. This conﬁguration prohibits running a MediaBase server on the ﬁrewall itself—there is no way to start a MediaBase server to accept such requests.

Conﬁguring the Firewall to Use the MediaBase Proxy

Conﬁguring the Gauntlet ﬁrewall involves planning, indicating which servers may be accessed, and conﬁguring the MediaBase proxy to enforce your policy.

Planning

Determine which internal users and hosts can use MediaBase, and determine whether you want to run the MediaBase proxy.

Using the MediaBase Proxy

Conﬁguring Network Services

You do not need to modify the IRIX conﬁguration ﬁles on the ﬁrewall to support the MediaBase server. This is a standard service, included in the default versions of these conﬁguration ﬁles on the Gauntlet ﬁrewall.

Note: On IRIX 6.2 systems, system patches 1485 and 1418 are required.

Conﬁguring the Proxy Rules

If you are using the Gauntlet ﬁrewall default conﬁguration, you do not need to modify the proxy rules for the MediaBase server. To enable the MediaBase server, use the gauntlet-admin Proxies form to enable the server.

Alternatively, you may modify /usr/gauntlet/conﬁg/template.netperm-table to reﬂect your conﬁguration. See Appendix B for more information on mbase-gw options, netperm-table options, and order of precedence.

Verifying Your Setup

V erify your installation by using your MediaBase player to connect to MediaBase servers on the outside network. See the section below for instructions.

Using the MediaBase Proxy

Users must set up the client-side conﬁguration ﬁles to enable the MediaBase client to communicate with a MediaBase ﬁrewall proxy.

Chapter 10

10. Managing X Window Services

The X Window System provides many features and functions that allow machines to share input and output devices. A user running the X Window System on one machine can display the results of a graphical program on another machine running an X W indow client. This ﬂexibility is also the source of a number of well-known security problems. When you allow access to your display, you are essentially allowing access to your screen, mouse and keyboard. Most sites do not want to provide this sort of free access to their machines, but administrators recognize that these services can be useful. The X11 proxy included with the Gauntlet Firewall allows administrators to selectively allow X1 1 services through their ﬁrewall.

This chapter explains the concepts behind the X11 proxy and how it works, how to conﬁgure the proxy, and how to use X11 services through the ﬁrewall.

Understanding the X11 Proxy

The Gauntlet X11 proxy is an application-level proxy that provides conﬁgurable access control. The proxy, which runs on the ﬁrewall, passes X11 display requests through the ﬁrewall, using rules you supply. You can conﬁgure the proxy to allow display requests based on

• display name

• user

Using these rules, you can conﬁgure your ﬁrewall to allow only certain machines on the inside network to display information from machines on an outside network. An employee working on the inside network can conﬁgure his or her machine to display information from a program on a client's machine on the outside network. Similarly, you can conﬁgure your ﬁrewall to permit only certain users to use the X11 proxy.

Chapter 10: Managing X Window Services

The X11 pr oxy also requires the user to conﬁrm each new request for a connection to their display. Because of the lack of strong authentication systems for X11, this reconﬁrmation provides an additional opportunity to conﬁrm that you really want to accept the connection. You can watch for other people trying to hijack your display.

Because the X11 proxy works in conjunction with the TELNET and Rlogin proxies, you can still conﬁgure access based on the source or destination hostname or IP address. The strong authentication feature is also available. The TELNET and Rlogin proxies also log X requests and connections.

How the X11 Proxy Works

Unlike some of the other Gauntlet proxies, the ﬁrewall does not start the X1 1 proxy when it receives display requests. Instead, users must explicitly start the X1 1 pr oxy from either the TELNET or Rlogin proxy. The ﬁrewall denies all requests for services on the standard X port (6000).

A user TELNETs to the ﬁrewall, which runs the TELNET proxy. After checking permissions and authenticating users (as described in chapter 1), the TELNET proxy (tn-gw) displays a prompt for the user. At the prompt, the user indicates a wish to allow X displays across the ﬁrewall. The TELNET proxy starts the X11 proxy (x-gw) on port 6010 (corresponding to X display “:10”) or higher . The X1 1 proxy checks its conﬁguration information (in the netperm-table ﬁle) and determines whether the initiating user has permission to use X11 services related to the desired display.

If the user has permission, the proxy creates a “virtual display” on the ﬁrewall for the requesting client. When the outside X client requests access to the user’s display, the virtual display server passes a query display to the X server on the display machine. This X server displays the query window on the real display, prompting the user to conﬁrm the request. After the user conﬁrms the request, the real X server receives the display information from the virtual X server. The proxy remains active until either end closes the connection.

The default policy is to allow both inside and outside hosts to start the X11 proxy.

Conﬁguring the Firewall for X11 Services

Conﬁguring the Gauntlet ﬁrewall involves planning, indicating which daemons the system will run, and conﬁguring the proxies to enforce your policy.

Planning

1. Determine whether you wish to allow X11 display connections thr ough the ﬁrewall.

2. Determine which users and which displays can issue and receive display requests.

3. Ensure that your policies for X11 services and TELNET and Rlogin are compatible.

Conﬁguring Network Services

You do not need to modify your network ﬁles on the ﬁrewall to use the X11 proxy. The TELNET and Rlogin proxies are the only programs that can start the X proxy, and they read their conﬁguration information from the netperm-table ﬁle.

Configuring the Firewall for X11 Services

Conﬁguring the Proxy Rules

To enable the X11 proxy for TELNET and Rlogin users, use the gauntlet-admin Proxies form.

Alternatively, you may modify /usr/gauntlet/conﬁg/template.netperm-table to conﬁgure the X11 proxy to enforce more speciﬁc security policies. See Appendix B for more information on x-gw options, netperm-table options, and order of precedence.

Verifying Your Setup

TELNET to a machine outside the perimeter and display an X11 client on your machine inside the perimeter. See the section below for instructions.

Chapter 10: Managing X Window Services

Using X11 Services

Users need to follow slightly different procedur es to use X1 1 services thr ough a ﬁr ewall. The minimal time needed for these additional steps outweighs the time and money you would spend to recover after someone hijacks your display and thereby penetrates security.

To use X11 services, follow these steps:

1. Allow the ﬁrewall to access your display (remember, it is the ﬁrewall you permit to access your display, not the client).

2. TELNET (or Rlogin) to the ﬁrewall.

3. Authenticate to the proxy, if necessary.

4. Start the X proxy.

5. TELNET (or Rlogin) to the desired host.

6. Inform the client of the host and display information that the proxy provides.

7. Start the X client application.

8. Conﬁrm the display request on the real display.

The example below shows a user working on the inside network who needs to display information from a program running on a machine on an outside network.

Clancy Rawhide, working at his machine (dimension) on the inside network, needs to run an X program on a client machine (blaze.clientsite.com) on an outside network, and display the results on his display . He ﬁrst gives the ﬁr ewall access to his system’s display. He then TELNETs to the ﬁrewall for Yoyodyne (ﬁrewall.yoyodyne.com). The policy for his site does not require authentication for inside requests, so the ﬁrewall connects him to the TELNET proxy.

First, Clancy starts the X11 pr oxy and establishes a TELNET connection with the outside host:

dimension-27: xhost +firewall dimension-28: telnet firewall Trying 204.255.154.100... Connected to firewall.yoyodyne.com Escape character is '^]'. firewall.yoyodyne.com telnet proxy (Version 3.1) ready: tn-gw> x

Using X11 Services

Clancy indicates he wants to start an X proxy. The ﬁrewall displays an X status window on Clancy’s display, showing the port (see Figure 10-1).

Figure 10-1 Example X Window Port Information

He then TELNETs to the client machine (blaze.clientsite.com).

tn-gw> c blaze.clientsite.com

Connecting to blaze.clientsite.com .... connected

HP-UX blaze A.09.01 E 9000/710 (ttys1)

The TELNET daemon on blaze prompts Clancy for his user name (crawhide) and password on blaze. The TELNET daemon on blaze veriﬁes Clancy’s user name and password, and logs him in.

Please wait...checking for disk quotas You have mail. blaze.clientsite.com-1:

Next, Clancy provides the X display information to the client machine (blaze) and starts the client application. He uses the display information that the X proxy provided when he started the X proxy:

blaze.clientsite_1: setenv DISPLAY firewall.yoyodyne.com:10.0 blaze.clientsite_2: xclock & blaze.clientsite_3:

Clancy uses the information the proxy provided to tell X where to display information. Clancy then starts the program, and conﬁrms the display request on his machine (see Figure 10-2).

Chapter 10: Managing X Window Services

Figure 10-2 Example X Window Conﬁrmation

Finally, Clancy views the results on his screen inside the ﬁrewall.

Silicon Graphics Gauntlet Administrator's Manual

Specifications and Main Features

Frequently Asked Questions

User Manual