This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/00.00-Header_Freebsd_stable_release.htm 000644 000000 000000 00000001545 10433404271 027274 0 ustar 00root wheel 000000 000000Home______________________________________________________________________
usr/local/share/doc/FBSD_Install_Guide/00.00-web_style_sheet.css 000644 000000 000000 00000001005 10433404271 024574 0 ustar 00root wheel 000000 000000 a:link { color: rgb(255,102,51); } a:visited { color: rgb(0,204,204); } a:active { color: rgb(204,153,51); } body { font-family: Courier New; background-color: #CCFFCC; color: #000000;font-size:10pt; padding-left:10; padding-right:10; padding-bottom:0; line-height:100%; list-style-type:decimal } table { table-border-color-light: rgb(153,204,153); table-border-color-dark: rgb(153,204,153); } h1 { color: #FF6633;font-size:18pt; font-family:Times New Roman; font-weight:bold } usr/local/share/doc/FBSD_Install_Guide/00.01-Cover_Page.htm 000644 000000 000000 00000005547 10433404271 023441 0 ustar 00root wheel 000000 000000
A Step-by-Step How-To Instructional Guide to Installing FreeBSD from scratch.
The left frame contains the table of contents. It has it's own vertical slider bar to navigate through it.
The right frame is where the subjects you select from the table of contents is displayed, it has it's own vertical slider bar to move through the document.
The vertical bar that separates the two frames can be moved left or right to expose a larger display area.
The table of contents lists all the individual subjects contained in the guide organized in the order one would naturally follow in the fresh install customization process.
There are many references to external URL's. Clicking on the URL will launch a new window.
Start at the beginning of this guide, follow the step by step instructions and you will end up with a fully configured gateway server. In the process you will learn about all the things needed to become a real a1poweruser.
Previous Page Next Page
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/00.02-index_Menu.htm 000644 000000 000000 00000112754 10433404271 023522 0 ustar 00root wheel 000000 000000FREEBSD INSTALL GUIDE INDEX
Home
Getting Started
Installing
Post Install
Internet Access
Network Security
Local Area Network
DHCP Server
System Security
FBSD Basics
Email Services
Ports & Packages
Kernel Customizing
FTP & Telnet
Masquerading as Commercial User
1.0 Limits of Liability and Disclaimer of Warranty
2.1 Incremental Install Method
2.2 Minimum Hardware Requirements
3.2 Using MS/Windows to get ISO CD images
3.4 Starting Award BIOS setup utility
3.5 First time changes to PC BIOS
3.6 Loading FBSD to the Hard drive
4.0 Post Install Configuration
4.2 Gracefully Stopping your System
4.3 Navigating the File System Directory Tree
4.10 Enabling clear tmp directory
4.11 Using mouse copy/paste function
4.11.1 Enabling non-USB 2 button mouse copy/paste function
4.11.2 Enabling USB 2 button mouse copy/paste function
4.11.3 Testing mouse copy/paste function.
4.11.4 Further customizing the mouse arrow pointer
4.13 Assigning a Host name to your FBSD system.
5.1 Cable TV access to the Internet
5.1.2 Configuring a cable modem Internet connection
5.1.3 Test your cable modem connectivity
5.2 Products offered by the public telephone company
5.2.1 Analog voice dial up service to your ISP
5.2.2 Analog voice ISDN service
5.3 Enabling voice phone Modems
5.3.2 How to determine if FBSD found my modem at boot time
5.3.5 Determining if your external serial modem is connected to FBSD
5.3.7 PCI Modem found as <unknown card>
5.3.8 PCI Modem found and moved to sio4
5.3.9 Determining if your internal PCI modem is connected to FBSD
5.5.2 Configuring User PPP for modem dial out to ISP
5.5.4 Enable DialISP at boot time
5.6 Configuring User PPP to accept inbound modem calls
5.6.1 Inbound ppp.conf statements
5.6.2 Configure Incoming services
5.6.3 Configure Modem to answer call using HAYES Commands
5.6.4 How the Incoming call process works
5.6.5 Testing Incoming call function
5.7.1 Callback Feature on Incoming Calls
5.7.2 Summary of how Incoming callback works
5.7.4 Summary of how ISP callback works
5.8 PPPoE ppp.conf statements for DSL connection
6.0.3 Firewall Software Applications
6.4.2 Format of Logged Messages
6.7 Inclusive Rule set Example
6.8.6 Directing traffic to Lan Servers
6.8.7 FTP Special Nat Handling
6.9 IPFIREWALL (IPFW) Firewall
6.9.7 Logging Firewall Messages
6.9.10 Example Inclusive Rule Set
6.11 OpenBSD's Packet Filter Firewall
6.12 Inclusive Rule set Example
6.13 Defending Against Attacks
6.13.1 Know Who Your Attacker is
6.13.3 Stopping Web Server Attacks
6.14.1 Example Environment Description
6.14.4 Using Midnight Commander for SFTP
6.14.8 Fraudulent SSH Login Attempts
7.0 Setting up Local Area Network (LAN)
7.5 Manually Configuring the Gateway
7.6 Manually configuring FBSD LAN PCs
7.7 Manually configuring MS/Windows LAN PCs
8.0 DHCP (Dynamic Host Configuration Protocol)
8.1 What function does DHCP perform?
8.4 DHCP Configuration Instructions
9.1 Network packet Security options
9.1.1 Sysctl.conf Security Knobs
9.3 Highest Level of Security Paranoia
9.3.2 rc.conf securelevel option
9.3.3 Encrypting Disk Partitions
10.1 Introduction to the manual documentation
10.2 Basic FBSD Commands you will need to know
10.3 Controlling what messages go to what syslog files
10.3.1 LOG rotation and archiving
10.4 Setting System Date and Time
10.5 Capturing screen content to file
10.6 Cron Scheduling Application & System Management Reports
10.7.1 To format a FBSD file system floppy disk
10.7.2 To create /a floppy mount point
10.7.5 To remove floppy from drive
10.7.6 To mount MS/Windows formatted floppy disk
10.7.7 Easier way to mount MS/Windows floppies
10.7.8 To test auto floppy drive mount
10.9.1 Configure the pw Command
10.9.2 Examples of pw command usage
10.9.3 pw command embedded in a script
10.10 2 Change file permissions
10.11 Managing your configuration changes
10.11.2 Script to Backup /custom to floppy
10.11.3 Script to Restore floppy to /custom
10.12.1 Mini.iso FTP download script
11.1 Commercial, non-Commercial sendmail Users
11.2 Configure Sendmail to send enail through your ISP
11.4.1 Qpopper Installation Instructions
11.5 Configuring Microsoft Outlook for FBSD mail service
11.6 Fetchmail / Getting your ISP mail to FBSD
11.6.1 Fetchmail Installation Instructions
11.8.3 Creating / sending your mail
11.8.6 Replying to or creating new mail
11.9 Email Vacation Auto Responder
11.9.1 How vacation process works
12.1 Determining what to install
12.2 Finding the Application Download Name
12.5 Using the Package Collection
12.5.1 Alternate Access Method to package Collection
12.6 Using the Port Collection
12.6.1 Downloading make files for single port
12.6.2 Fetch Port Config Files Script
12.7 Ports/Package Install History Database Commands
13.2 Managing Multiple Kernels
13.4 Replacing /kernel with saved /kernel
14.1 Inetd, FBSD's Super server
15.0 Masquerading as a Commercial User
15.2 Verifying ports 25 & 80 are open
15.3 Masquerading Using ZoneEdit
usr/local/share/doc/FBSD_Install_Guide/01.00-disclaimer_copyright.htm 000644 000000 000000 00000007311 10433404271 025622 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
The author of this FreeBSD Installer Guide has used his best efforts in preparing this manuscript. These efforts include the development, research, and testing of the theories and the FreeBSD functions documented to determine their effectiveness and verify the FreeBSD functions perform as stated. The author makes no warranty of any kind, expressed or implied, with regard to the documentation contained in this FreeBSD Installer Guide. The author shall not be liable in any event for incidental or consequential damages in connection with or arising out of the use of this document. The author is not personally responsible for any damages incurred due to actions taken based on this document. This document is meant as a guide to installing the FreeBSD operating system, performing basic configuration and system administration. If you do not feel comfortable taking responsibility for your own actions, you should stop reading this document and hire a qualified professional to install your FreeBSD system for you.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
Please contact the Author at (FBSD_IG @ a1poweruser.com) with any comments, corrections or additions you would like to see added. The above email address is written that way to prevent auto harvesting for spam use.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/01.02-synopsis.htm 000644 000000 000000 00000017705 10433404271 023317 0 ustar 00root wheel 000000 000000Home______________________________________________________________________
There are two development branches to FreeBSD: FreeBSD-CURRENT and FreeBSD-STABLE.
FreeBSD-CURRENT is the "
bleeding edge" of FreeBSD development. It includes work in progress, experimental changes, and transitional mechanisms that might or might not be present in the next official stable release of the software. Users of FreeBSD-CURRENT are expected to have a high degree of technical skill and should be capable of solving difficult system problems on their own. This is technically the developers version and is not intended for the general public. FreeBSD-CURRENT releases are NOT suitable to run your company or business using it.FreeBSD-STABLE is the development branch from which major releases are made. Changes go into this branch at a different pace and with the general assumption that they have first gone into FreeBSD-CURRENT for testing. FreeBSD-STABLE major releases are referred to as the production versions. Meaning that it is so stable that its suitable to run your company or business using it and is intended for the general public.
This FreeBSD Installer Guide is purposely written to be your step by step instructional guide to installing FreeBSD-STABLE release version from scratch. The Author has tested everything written in this Guide on this stable release. As each new version of FreeBSD works its way through the development cycle in FreeBSD-CURRENT and finally becomes a production "Release" version from the FreeBSD-STABLE branch, this FreeBSD Installer Guide will be updated to match the new stable release version.
That being said, a large percent, 95% or better, of the content of this Guide is valid for older stable releases and to a somewhat lesser degree to the current development versions. If you are not using this FBSD Installer Guide to install the stable production release version 6.0 then you may experience differences and deviations from what is documented here.
The author voices his opinions throughout this Installer Guide. The deficiencies and poor design of some things are pointed out as well as the good points. This is done to give the reader a truthful and honest look into the real status of the FreeBSD operating system.
From this point on FreeBSD will be written as FBSD.
This FBSD Installer Guide is targeted at FBSD users who are inexperienced with FBSD or installing FBSD for the first time.
This FBSD Installer Guide presents a step-by-step method of installing FBSD from a CDROM creating the basic configuration of a gateway server with a local LAN as diagramed below.
The diagramed system is a gateway to the public Internet allowing all the PCs on the LAN to share the bandwidth of the connection to the public Internet. The xl0 symbol represents the connectivity to the internal private LAN and the rl0 symbol represents the connectivity to a external dial out modem or an Ethernet cable between a NIC connected to a DSL or cable modem. The X symbol represents MS/Windows or FBSD workstation on the LAN.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/01.03-Installer_pre-requirements.htm 000644 000000 000000 00000011342 10433404271 026744 0 ustar 00root wheel 000000 000000Home______________________________________________________________________
The person installing FBSD has to have some very basic understanding of what they are getting themselves into. The installer must be comfortable with opening the case of the PC and removing and installing cards in the PC's ISA or PCI expansion slots, must know how to access the PC's BIOS setup utility and how to make changes to the BIOS setting for the particular manufacture / model of PC. The FBSD installer should have the motherboard manual for the PC that is going to receive the FBSD system. If you know what the different items on the motherboard are and what all the BIOS setup options mean then you do not need the motherboard manual.
It is possible to install FBSD on a PC that already has MS/Windows or some other operating system installed so one or the other operating system can be selected at boot time. I have read about cases where experienced users have multiple versions of FBSD installed on the same hard drive and can select which version to boot from. Also there are reports of users with FBSD, Linux, OpenBSD, MS/Windows all bootable on the same PC.
This Guide's stated goal is to configure this fresh, new install of FBSD as a gateway server. As such, a gateway server is in use 7/24 so there is no other dual-bootable operating system needed or wanted on the system's hard drive.
Installing FBSD to share multiple hard drives with other operating systems is an advanced configuration which is beyond the scope of this Installer Guide.
This Installer Guide is based on using a hard drive that is empty or one you do not care about the data on it, because you will be re-formatting the hard drive and all the contents of the hard drive will be wiped clean.
This Installer Guide is not building a FBSD workstation, but a FBSD server gateway, so you will not have a GUI (graphical user interface) like MS/Windows. You will be working totally at the FBSD command line which is equivalent to the MS/DOS prompt command line.
The learning of FBSD basics as presented in this Installer Guide is going to take the first time user some time to complete (more that 15 hours). If the PC you are installing FBSD to is used as your main PC for everyday connection to the Internet, then you had better rethink what you are doing and how you are doing it, because once you start and commit the hard drive to FBSD you may find yourself offline for some time. My recommendation is to use two separate hard drives: one hard drive for the original operating system that you disconnect from the data ribbon and power supply, and a second hard drive for FBSD that you substitute for the original hard drive on the data ribbon. This way you can swap between the two operating systems while you learn FBSD.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/01.04-introduction.htm 000644 000000 000000 00000015714 10433404271 024151 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
FreeBSD is a cost free operating system based on the BSD 4.4-lite release from Computer Systems Research Group at the University of California at Berkeley. FreeBSD requires an ISA, EISA, VESA, or PCI based computer with an Intel 80386SX to Pentium CPU (or compatible AMD or Cyrix CPU) with 4 megabytes of RAM and 60MB of disk space.
Cost free in this case means there is no license fee to use the software and the software source code is available free of charge to anybody who wants it.
Some of FBSD's features are: preemptive multitasking with dynamic priority adjustment to ensure smooth and fair sharing of the computer between applications and users; multi-user access - peripherals such as printers and tape drives can be shared between all users; complete TCP/IP networking including SLIP, PPP, NFS and NIS; and memory protection, demand-paged virtual memory with a merged VM/buffer cache design. FBSD was designed as a 32-bit operating system. X Window Systems (X11R6) provides a graphical user interface. Binary compatibility with many programs built for SCO, BSDI, NetBSD, 386BSD, and Linux is provided. Thousands of ready-to-run 3rd party applications are in the FBSD ports collection. FBSD is source code compatible with most popular commercial Unix systems and thus most applications require few, if any, changes to compile. Shared libraries, a full compliment of C, C++, Fortran and Perl development tools and many other programming languages are included. Source code for the entire system is available.
FBSD is not a commercial operating system. There are no people getting paid to support the source code which makes up the system. FreeBSD was developed, maintained and is being enhanced by a core group of dedicated volunteers. The source code is freely available to all and is the vehicle used to upgrade in place to new versions as they are released. FBSD is just one flavor of many Unix like operating systems.
FBSD's popularity is based on its speed of processing a large number of simultaneous TCP/IP connections, its code stability over the other flavors of Unix like operating systems, the large selection of pre-packaged 3rd party software applications which can run on it and most important the lack of any licenses fees to use it.
FBSD is like having a complete workshop with all the tools and materials needed to build a Ferrari race car. The user needs to put forth the effort to learn how to use the equipment to form the materials into the parts needed to build the race car. If you have the patience and persistence, them over time you can learn to build yourself a very fast and reliable operation system that runs like a Ferrari race car.
FBSD was not and is not targeted at commercial users, even though many ISP do use it as the main workhorse of their environments. Basically FBSD is targeted at the advanced technical computer hobbyist, or the computer hobbyist who is technically inclined and wants to leave the Microsoft world.
On-line documentation is available, but leaves a lot to be desired. It is inefficient in conveying any useful meaning, due to its lack of background explanation information tying the system components together.
All the official FBSD documentation (IE: the handbook & the individual command manuals) are written as reference materials for users who already have an in-depth programmers knowledge of FBSD or its common heritage with other Unix-like operating systems. These sources are not learning aids for the newbie.
It became very apparent to me that some kind of user-friendly step-by-step configuration instructions based on a working example containing full and comprehensive documentation was needed. To that end I have written this FBSD Installer Guide. The documentation style used here has been in common use in the IBM mainframe environment for 25+ years. It has a proven track record, makes common sense, and presents the information in a logical progression of steps which build upon each other, giving the reader background information about the interrelationships of the operating system software components necessary to achieve an understandable functional solution -- a real follow-your-nose type of approach.
The author is not claiming to be a professional technical book writer or to be an expert on all subjects concerning the FreeBSD operating system. But the author does have 30 years of professional Computer Data Processing experience and witnessed the birth of the personal computer industry and the public Internet first hand as well as major participation in the integrating of these new technologies into many commercial businesses during his career as an Independent Data Processing Consultant. The contents of this Installer Guide can be considered as originating from an individual who has the background and experience to be an authority on the subject.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/02.00-preparing_pc_for_fbsd.htm 000644 000000 000000 00000021306 10433404271 025734 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
There are two FBSD environments. The FBSD workstation and the FBSD server.
The FBSD workstation environment is equivalent to a MS/Windows workstation. It has a GUI (graphical user interface) using an AGP video card, a sound card, a read/write CDROM device, scanner, and all the other devices one would expect on a MS/Windows workstation.
The FBSD server environment contains all the facilities the normal MS/Windows home user never sees because these services are provided by the users ISP, such as a Firewall, Mail server, Domain name server, and the like.
The intended final usage of the PC will dictate what FBSD components need to be installed and which are not needed. The primary difference is the GUI component is not normally installed for a server environment as it consumes a very large amount of disk space which penalizes you every time you do a system backup of your system.
This Installer Guide's stated purpose is the building of a FBSD gateway server, and as such will not have the GUI component installed.
Another area of consideration is the style of PC, Desktop or Laptop. FBSD does function on both.
Laptop PCs have some quirks when it comes to I/O devices such as NICs and modems. Laptops have been used for servers, but it is highly recommended that laptops only be used for workstations. Even though this document is written for the desktop style of PC, everything also applies to the laptop to some varying degree.
The desktop style of PC is the targeted PC this Installers Guide is written to.
I have found the brute force method of installing FBSD to result in a percentage of installs having problems. By brute force I mean, using a fully loaded PC, (IE: more than one IDE hard drive, using an AGP high resolution video card, using USB devices, ISA & PCI modems, RAID control cards with RAID hard drives as the installation target).
This Installers Guide uses the incremental method. The incremental method starts with a very simple basic hardware configuration which is specified below, and after FBSD is working on that, then additional components are added one at a time. This way you greatly reduce the number of variables that have to be considered when trying to debug installation problems.
Following the incremental method used here is not a mandatory requirement; its just a way to remove many of the areas where install problems occur due to outdated legacy hardware equipment or a maxed out PC hardware environment. The followings install instructions have been tested using the hardware Desktop PC starting base and have resulted in a repeatable successful install across a range of PC manufactures.
Desktop PC starting base
Any Intel 386 through Pentium CPU or clone thereof.
One IDE hard drive on the primary IDE controller
One IDE cdrom reader or r/w device on the secondary IDE controller
One floppy drive
Simple PCI VGA video card cheap type, no need for high speed graphics card
Any kind of mouse (serial or USB)
Any kind of monitor, cheaper the better
Things you may need later
External serial modem or internal PCI modem card (non-WinModem type)
Two internal PCI 10/100 NICs
Things to remove and not use
Sound card
USB port disk drives, zip drives
ISA modem card
ISA NIC
It became popular after 1999 for motherboard manufactures to include on the motherboard some or all of the functions listed below replacing the need for plug in expansion cards.
Sound card, USB ports, modem card, video card and 10/100 NIC.
If the PC you are using is of this type, then you must enter the PC BIOS setup utility and navigate around the menus looking for options to disable the onboard functions not required for the Desktop PC starting base.
Hard drives and CDROM drives are both IDE devices, but operate at different speeds. Your CDROM read or read/write drives must not be on the same IDE controller as your primary boot hard drive, as this will cause your hard drive to run at the speed of the slower CDROM drive, which is much slower than the speed of the hard drive. This results in significant hard drive performance degradation. The primary IDE controller should be reserved for master and slave hard drives of the same speed (UMDA 33, 66, or 100). The secondary IDE controller should be reserved for master and slave CDROM drives. Check how your hard drive and CDROM drives are cabled and change them right now if they are sharing the same IDE controller.
Installer Note:
Just to be absolutely clear. The Desktop PC starting base hardware requirements above are not the minimum needed for FBSD to run. It is what the FBSD target install system is to be stripped down to as the basic hardware configuration used by the incremental installation method used in this Guide. The legacy ISA expansion card slots on motherboards are being phased out by motherboard manufactures because they are so much slower than PCI slots. ISA modem cards and ISA NICs are not included as supported hardware in reference to this Guide as they are known to cause configuration problems, and this Guide does not give debugging procedures to address ISA IRQ problems. Do not try to use legacy ISA expansion boards. Get yourself PCI expansion cards if you need them. Also be aware that a lot of PCI modem cards are specially designed to work only with MS/Windows PCs. These types of modems are known as WinModems. FBSD only works with internal PCI modems that have onboard controllers. WinModems do not have onboard controllers and can usually be identified by the use of lucent chips on the circuit board.5.4 is the first release to no longer support pre Y2K legacy PC's. Install problems show up in legacy PC's using 40 pin UDMA33 hard drives, default memory sizes and CPU speeds under 1GHz. You can work around this be using an newer PC to install the system on the Hard drive then put the hard drive in an legacy PC to run.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/03.00-Installing_FBSD.htm 000644 000000 000000 00000033210 10433404271 024317 0 ustar 00root wheel 000000 000000Home______________________________________________________________________
FBSD is distributed on CDROM.
BSD Mall and FreeBSDmall sell a 4 CD set for $40.00 plus shipping. I bought this one time before I knew better. You only need the first CD, it contains the FBSD install, the rest of the other 3 remaining CDs contain selected applications ports that you can install on FBSD. These application ports can be outdated almost as soon as they are cut to the release CD, so one finds themselves using the online ports collection to install these applications anyway. The revenue from these sales is what supports the acquisition of server equipment and internet access for the services that the web sites use to administer the FBSD project. If you want to do your part to support the FBSD project, then by all means purchase the 4 CD sets every time a new version is released, about four times a year.An alternative is just to purchase the FBSD 2 CD install set.
Linux Central sells the 2 CD set for $5.00 plus shipping. Cheap Bytes sells their FBSD 2 CD install set including cost of shipping for $7.00.This is the point where many new users start saying, but its suppose to be free. Well FBSD is free, free to use as in no licensing fee to pay, as in you have free access to the source code, and free access to download the ISO CD images of the 4 CD set from a FBSD FTP server. But the production of making the 3 CD set and the marketing of the install CD set is not free. You have to pay for that service.
The FBSD 2 CD set is available from many FBSD FTP sites. Many people think they can just download the ISO image, burn it to CD and away they go. Well here's a news flash for you: its not that easy. ISO is simply a compression standard. The people who build the FBSD release CDROMs compress the CDROM contents into a single flat ISO file for easy downloading. These ISO files are populated to all the FBSD FTP mirror sites. The list of all world wide FBSD FTP sites can be found here
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.htmlThere are 13 USA sites. Change the X in the following URL to a number between 1 and 13 to get a USA sit
ftp://ftpX.FreeBSD.org/pub/FreeBSD/. For example ftp://ftp5.FreeBSD.org/pub/FreeBSD/ would get the fifth FBSD FTP mirror site in the USA.The CDROM ISO images would be found at this directory path
ftp://ftp5.FreeBSD.org/pub/FreeBSD/releases/i386/ISO-IMAGES/
at that location you would find these files,
6.1-RELEASE-i386-disc1.ISO, 6.1-RELEASE-i386-disc2.ISO, 6.1-RELEASE-i386-bootonly.ISO, and CHECKSUM.MD5.
The 6.1-RELEASE-i386-disc1.ISO file contains everything needed to install FBSD. The 6.1-RELEASE-i386-disc2.ISO file contains a selection of the most used ports from the 45,000+ ports system. As new releases come out, the path stays the same except the release number changes in the path. So to get release 6.5 you would replace the 6.1 with 6.5 and every thing else stays the same.
The CHECKSUM.MD5 files holds the checksum values of the 3 files. If you used a FBSD system to FTP these files you should also download the CHECKSUM files and use the checksum hash values to verify your downloaded ISO file is complete and correct by running these steps to verify the download is good.
ls -l to verify file sizes
md5 6.1-RELEASE-i386-disc1.ISO >> CHECKSUM.MD5
to create a checksum value of your downloaded file & append it to the end of the downloaded CHECKSUM.MD5 file'
cat CHECKSUM.MD5
to display the file, and review the last 2 lines of the file
In this example the first line contains the CHECKSUM value of the 6.1-RELEASE-i386-disc1.ISO file when it was created at the FBSD ftp site. The last line contains the CHECKSUM value of your downloaded ISO image you just created using the md5 command. If the 2 values do not match then your download is no good and you have to download it again.
First of all the .ISO file extension is not supported in the native MS/Windows world. Sure you can download it from one of the FBSD FTP sites and burn it to a CD using MS/Windows, but you end up with a data disk where the ISO file is a single file, not a bootable CD containing the FBSD directory tree which you need to install from. The second major problem is you need a fast Internet connection, (IE: ISDN, DSL, CABLE) to download over. Using a 56K modem will take over 28 hours per CD if you are lucky enough that your ISP does not cut you off or the FTP server does not get busy and suspend your session. To resolve this problem of using a MS/Windows box to obtain the FBSD install CDROM image you will need a MS/Windows FTP program that can restart the ftp download where it left off at, if it gets terminated during the initial download. I used SMARTFTP from www.smartftp.com. Then you need a MS/Windows program that can burn ISO files to CDROM. I used Nero from www.nero.com. The downloaded demos from these sites work just fine to do what you have to do to create your FBSD mini install CDROM. Uninstall them, but keep the downloaded install zip files for them and next time you need to retrieve a FBSD .ISO file, just reinstall to get a new 30 day demo.
So lets be realistic, the first time installer of FBSD should purchase at the bare minimum the $3.00 single install CD from www.linuxcentral.com to get started. Doing so will result in you installing the current production version of FBSD and enabling you to receive the maximum level of support from the FBSD questions mailing list. Many of the experienced users who respond to questions on the list will only answers questions about the current version of FBSD.
The first thing your PC does after being powered on or when rebooting is the motherboard BIOS ROM chip gets control and it interrogates all the hardware ports on the motherboard to determine what I/O devices are attached. This is called the POST process. As part of this POST process the user changeable BIOS values stored in a CMOS chip on the motherboard are read and used to configure the PCs hardware. These BIOS values are changed using the BIOS setup utility. The most common BOIS chip in use today is manufactured by Award. If your PC does not use an Award BIOS chip then you have to read the manual that came with your PC for details.
All Award BIOS's display a summary screen at the completion of the post process which list all the devices found, there names and which IRQ number was assigned by the BIOS to that I/O device. IBM PCs do not show this summary screen by default, some other manufactures of PCs may also have selected to turn off this summary screen by default.
You the FBSD installer must enter the BIOS setup utility and activate this summary screen display.
This summary screen information is very helpful in debugging FBSD hardware problems, because it tells you what your PC hardware is and how the IRQ numbers are assigned. IRQ stands for interrupt request. An interrupt is the doorway the I/O device uses to tell the CPU that it wants its turn at getting some processing cycles. This is how the CPU shares service time among all the devices attached to the motherboard.
During the power up/reboot POST process you will see in the lower left corner of the monitor screen the message Press DEL to enter setup. While this message is showing press the keyboard delete key and the Award BIOSs setup utility main menu displays on the screen.
Navigate around the menus using the keyboard arrow keys looking for the following options. Your PC BIOS may not have all of these.
Virus Warning=, set this option to disable. Its a firmware check of the hard drive boot sector looking for MS/Windows boot virus. This will stop FBSD booting from the install CDROM.
plug-n-play=, set this option to disable. FBSD is not sensitive to Microsoft plug-n-play standard and may refuse to install, or cause PCI cards not to be found.
Disable or set to auto any BIOS option to assign IRQ numbers to PCI expansion slots.
Disable any ISA expansion slots.
Operating system type=, set to other or any Unix type of operating system, dont set to MS/Windows.
Disable all power management options.
boot sequence=, set this option to (CDROM,C) Since you are installing FBSD from CDROM you must tell the PC what I/O device to boot from.
Follow the BIOS menu instructions to save your changes and exit. The PC will reboot it self.
Keep in mind that some older CDROM drives and older legacy PC BIOS do not support booting off CDROM. Generally with PCs manufactured after 1999 this is not a problem.
If you do run into this, you have a really old PC and you will need to create boot floppies to boot from. This is outside the scope of this document. Please read the FBSD Handbook at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-pre.html#INSTALL-FLOPPIES
Legacy BIOS also are incompatible with the larger hard disk sizes and the faster 66 and 100 UDMA drives.
Unicore Inc, manufactures and sells replacement BIOS chips. Check out www.unicore.com web site for instructions on how to get the technical information about your computer's BIOS chip so they can cross-reference it to their product line, or call their sales dept at 1-800-800-2467. A replacement BIOS chip costs around 80.00 USA Dollars.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/03.05-loading_fbsd_to_the_hard_drive.htm 000644 000000 000000 00000037051 10433404271 027575 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
Installer Note:
The FBSD sysinstall application is very old and outdated. There has been talk for many years of changing it. There has even been some projects started to address this problem to streamline it and make it more easier to understand what is happening and why. There is no documentation with the sysinstall application that describes the different configuration options as to what the option means, what the valid values are for the option, or why one would select the option. These options only make sense to experienced users who already know the internals of FBSD. New users to FBSD or users who do not know how IP addressing works find the configuration options meaningless.The boot from the FBSD install CDROM executes the sysinstall application. Its the mandatory vehicle required to initially install FBSD to your hard drive.
This section presents you with the minimum responses to the sysinstall application install prompts necessary to install FBSD on your hard drive. In most cases the response is no. You will learn how to manually configure a FBSD server outside of the sysinstall application option prompts. This way the next time you use the sysinstall application you will understand what it is asking for and how to respond.
Put the FBSD install CD in to the CD reader device. Power on the PC.
The PC boots from the CD and you will first see some stuff scroll across the screen and then display the FreeBSD boot option screen with the words "Free BSD" on the right. There is a 10 second count down after which the default option is taken. You will see this boot option screen every time you boot FBSD. The normal response is to press the enter key or just let the 10 second timer expire and the normal boot process will continue.
Hit [Enter] to boot immediately using the default.
Some more stuff will scroll across the screen and then display an menu to select your country.
Then the sysinstall main menu will be displayed.
Use the down arrow to highlight the Standard installation and press enter.
A message will display telling you the next step is to create the FBSD slice on your hard drive.
Press enter to continue.
The FBSD FDISK partition editor will display the a screen similar to this.
The FBSD FDISK partition editor is used to manage the space on hard disk drives by deleting old allocations and allocating new allocations. In the above screen shot of the FBSD FDISK partition editor screen, you see under the column heading Desc the word fat for the second line, which tells you that the hard drive you are trying to install on has a MS/Windows partition, followed by unused free space. Since you have already been told in this Guide that the hard drive to be used has to be empty or contain data you dont care about, you are going to delete all the existing allocations as the first step.
Use the down arrow key to position the blue highlight bar down one line so it covers the line that has the word fat under the Desc column. Press the D keyboard key to delete the allocation
You should see just one single line marked as unused under the Desc column. If you have more than one used allocation, repeat deleting until there is only a single line displayed with unused under the Desc heading.
You are now going to allocate the whole hard drive to the FBSD system.
Press the keyboard A key
Then the keyboard Q key
to quite out of this screen.
You will then be asked if you want to install the FBSD boot manager. Use the down arrow key to highlight the Install the standard MBR (no FBSD boot manager) line and then press enter to continue.
An informational message will display saying you are now going to create FBSD partitions inside the FBSD allocation space you just created. Press enter to continue.
The FBSD Disklabel program will be launched and display a screen which looks like this.
Disklabel can automatically create partitions for you and assign them default sizes.
Press the A keyboard key
to allocate the auto defaults. These values are designed to service the needs of the general user and is what you are going to use. Selecting the auto default will display a screen similar to this. Yours will not match this display and thats ok.
Sysinstall Disklabel Editor With Auto Defaults
Now Press the Q keyboard key
to exit the Disklabel program and accept the defaults.
The next step is to choose the distribution set you want to install.
Choose Distributions
Use the arrow key to move the blue highlight bar down to
[ ] 6 Kern-Developer Full binaries and doc, kernel source only
You are installing a FBSD server and have no need for X-Windows. You are not going to be developing any new FBSD program code, but you do need the Kernel program source so you can re-compile the kernel to add options you may need for your server.
Press enter to select.
A window pops up asking if you want to install the ports collection. Use tab key to
highlight NO and press enter.
You return to the Choose Distributions window. Use tab key to highlight the OK button and press enter
The Choose Installation Media screen displays. The option number 1 (Install from CDROM) is highlighted. If you have more than one CD or CD/RW drive you will see a window asking to select the CDROM drive to install from.
Press enter to select
The User Confirmation Requested screen displays. Up to this point you have not made any changes to the hard drive yet. This is your last chance to abort the install.
YES is highlighted; press enter and your hard drive gets configured as you previous specified and FBSD Distribution you selected get installed on the hard drive.
A bunch of windows pop up showing you the progress of the install as data is copied from the install CDROM to your hard drive. There are no user prompts to answer during this phase of the install, so just set back and watch it happen.
At the completion of the population of your hard drive a MESSAGE screen displays saying Congratulations FBSD is installed on your system. Just press enter.
Now starts a bunch of question windows asking you if you want to configure some function options. You are to answer NO to these prompts.
Would you like to configure any Ethernet or SLIP/PPP devices? = NO
Do you want this machine to function as a network gateway? = No
Do you want to configure inetd and the network services that it provides? = NO
Do you want to have anonymous FTP access to this machine? = NO
Do you want to configure this machine as a NFS server? = NO
Do you want to configure this machine as a NFS client? = NO
Do you want to select a default security profile for this host = NO
An informational message window displays about "medium" security, press enter
Would you like to customize your system console settings? = NO
Would you like to set this machine's time zone now? = NO
Would you like to enable Linux binary compatibility? = NO
Does this system have a non-USB mouse attached to it? A NO answer will bypass the followings instructions a through h below. You really do want to configure the mouse so the mouse daemon will automatically start at boot time because you want the mouse copy and paste feature activated. An answer of YES means you have a serial mouse, you will be prompted with the following configuration windows,
a. Use the arrow key to move the blue highlight bar to option number 3 select Mouse protocol type
b. New window pops up with highlight bar on option number 1(Auto), Press enter.
c. You return to the configure your mouse menu, this time select option number 4 (Select mouse port) press enter.
d. New window pops up with highlight bar on option number 1(PS/2), Press enter.
e. You return to the configure your mouse menu, this time select option number 2 (Enable) press enter
f. A new window pops up with mouse pointer showing. Move mouse to see the pointer move.
g. If the mouse arrow pointer moves, press enter.
h. You return to the configure your mouse menu, this time select exit and press enter.
The FreeBSD package collection is a collection of thousands of ready-to-run applications, from text editors to games to WEB servers and more. Would you like to browse the collection now? = NO
Would you like to add any initial user accounts to the system? Adding at least one account for yourself at this stage is suggested since working as the "root" user is dangerous (it is easy to do things which adversely affect the entire system). = NO
Now you must set the system manager's password.
This is the password you'll use to log in as "root".
Press enter
Changing local password for root.
New password :
Retype new password :
Enter your secret password and press enter, You will be prompted to enter your secret password a second time. You must remember this password as it is needed to gain access to the Master account root. WRITE IT DOWN SOME WHERE YOU CAN FIND IT WHEN YOU NEED IT LATER.
Visit the general configuration menu for a chance to set any last options? = NO
You return to the Main Installation Menu. Use the tab key to highlight EXIT, press enter
Are you sure you wish to exit? The system will reboot (be sure to remove any floppies from the drives). Use tab key to highlight YES, press enter.
FBSD is now installed on your hard drive and will automatically reboot your system.
Be sure to remove the FBSD install CDROM or you will enter the install again.
On the first boot of your FBSD system after installing from CDROM, you have to return to the BIOS's setup configuration menu and change the boot sequence=CDROM to boot sequence=C this tells the PC to boot from the hard drive instead of the CDROM drive.
You now have the base installed for your FBSD server.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/04.17-Time_Zone.htm 000644 000000 000000 00000010725 10433404271 023325 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
The tzsetup utility reads a database of time zone information and presents a menu allowing the user to select a specific time zone. The selected time zone is installed as the FBSD operating systems default time zone. The tzsetup utility also determines whether any adjustment is necessary for systems where the hardware clock does not keep UTC. You only have to do this one time after installing FBSD from scratch.
Type tzsetup on the command line and hit enter and you receive the following.
User Confirmation Requested
Is this machine's CMOS clock set to UTC? If it is set to local time
or you don't know, please choose NO here! >
Yes [ No ]
Select [ Yes ] or [ No ]
according to how the machine's clock is configured and
press Enter.
Select Your Region
Use the arrow keys to highlight your region and then press Enter.
Select Your Country
Use the arrow keys to highlight your country and then press Enter.
Select Your Time Zone
Use the arrow keys to highlight your time zone and then pres Enter.
Confirmation
Does the abbreviation 'EDT' look reasonable?
[ Yes ] No
Confirm the abbreviation for the time zone is correct. If it looks okay,
press Enter.
At completion the Tzsetup utility creates a new file in /etc called localtime.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/04.00-Post_Install_Configuration.htm 000644 000000 000000 00000026052 10433404271 026726 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
At this point you have a bare bones FBSD system installed. It is a long way from being a usable system. There are many things that need to be configured yet and things you need to know so you can navigate and administer your FBSD system that are unique to Unix based systems. In this section you will be introduced to the basics of FBSD and configure the mandatory options to bring your system to life.
The FBSD Basics section has more good configuration options you should read about, but they are not needed to get your system running like the things covered here.
What is an account you ask? Each user you want to grant access to this system has to have a pre-defined account on the system. The major items that make up an account is a unique user ID and Password. The account called root is the master FBSD operating system administrator account which has no restrictions and is automatically built as part of the install. It is very powerful and can be very dangerous in the hands of somebody who wants to cause damage to your system, so it's very important you do not allow unauthorized people access to the root account. As the system installer you will be using the root account to configure the system startup options and to install any of the ports collection software applications you select. After you have completed the setup configuration of your system, you should create for yourself a personal account to use for all non operating system administration activities.
All the instructions in this Installers Guide are based on you being logged on to this system as user root.
When you boot FBSD, the last line displayed on the screen will be a login prompt. You type in the word root and press enter. The prompt password displays and you type in the password you selected during the install.
If you do not remember the password you entered during the install, then you are SOL (IE: shit out of luck). Put the install CDROM back in the drive and go through the install again. This is part of the FBSD learning experience; get used to it. Do not be afraid to take a leap of faith and just go ahead and do something. You cannot hurt your systems hardware if your find yourself locked out. You have to build personal self confidence in your own ability to configure your system and make changes to it. Consider your system as a your personal learning tool, safe in the knowledge that a reinstall will fix all your mistakes.
When the system accepts your login ID and password, you will then see the 'Welcome message' scroll by. The last line at the bottom of the screen is prefixed with a # sign. This is the FBSD command line. This is where you will be entering all your commands to the operating system.
When you want to log off, type the word exit on the command line and hit the enter key. You screen returns to the login prompt, waiting for an ID and password to start another console session.
When you are ready to stop your system for the day, you have to be logged in as root, type the halt command on the system's command line and hit enter. The system will go through a graceful shutdown where all the file systems are closed in an orderly fashion, so when you restart your system all the file systems are not corrupted. When the halt command has completed its tasks it issues these messages, The operating system has halted. Press any key to reboot. When you see this, you can power off the PC.
The reboot command goes through the same graceful shutdown process as the halt command does, but when its completed it does not issue any messages; instead it will issue the internal reset command to the system BIOS to start the boot process all over again. Some times the BIOS does not cooperate and you're left with a blank screen. You can power off and then power on to start the boot process again, or if your PC has a reset button on the front of the case, just push the reset button to restart the boot process.
The shutdown command goes through the same graceful shutdown process as the halt command does, but first it issues a message to all logged on users that the system is coming down. This command is only appropriate for gateway servers that have LAN users such as in a commercial business environment.
The FBSD directory tree is just like the MS/Windows directory tree. There are primary directories with sub-directories that have sub-directories. But FBSD does not have any command to show the directory tree like MS/windows has 'Windows Explorer'. There is a 3rd party application named 'ytree' which you may be interested in checking out from the port/package collections that displays the directory tree graphically. All directory tree navigation has to be done manually by hand using commands.
Perform the following example.
cd /etc/ppp change directory pointer two directories deep
pwd display the name of the current directory path
cd .. back down directory pointer one directory (to /etc)
pwd display the name of the current directory path
cd /root change directory pointer to the specified directory
pwd display the name of the current directory path
ls
Lists the names of the files and directories at this location, but you can not tell which ones are files and which ones are directories.
ls l
Lists all the detail data about the contents of the directory you are in. The first column on the left shows you the permissions of each file and directory. If the left most position of the permissions values contain the letter d then it means it's a directory name.
Example of ls l command output:
-rw-r--r-- 1 root wheel 880 Dec 24 10:20 .cshrc
-rwx--x--- 1 root wheel 378 Jun 30 2003 .fetchmailrc
-rw------- 1 root wheel 955 Dec 24 20:24 .history
drwxr-xr-x 2 root wheel 3072 Dec 24 10:46 bin
-rw-r--r-- 1 root wheel 622 Dec 28 13:05 ftp.PR
bin is a directory; it has d in left most position.
I know what you are thinking. Boy this is going to be a big pain in the butt to have to blindly navigate the directory tree this way. This sure is primitive. Everyone else and I agrees with you on this, but this is the way the very first Unix was coded to work and all the other Unix like operating systems function this same way. It's something you just have to learn to live with.
There is a way to configure FBSD to display the directory path as a prefix in front of the command line so you know where you are at in the directory tree at all times, thus eliminating the need to use the pwd command.
Perform the following
cd /etc # Change into directory
set prompt = "# %/ >" # thats "#space%/space>"
Now the command line looks like this
# /etc >
The problem is that this setting will only be in effect until you log off or reboot the system. Making this permanent so it happens every time you log in as root is covered in the next section on using the editor. You can also make this a permanent default for all the users you add to your system later.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/04.05-How_to_use_ee.htm 000644 000000 000000 00000024512 10433404271 024214 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
There are many file editors that come installed as part of the basic FBSD install and there are other editors in the ports system which you can install. The ee editor comes installed in the FBSD base system and it's the easiest editor to use for the beginner, so I will be using this editor for all the examples in this Guide.
Perform the following
cd /root # Change into directory
ls # List contents of directory
ee .cshrc # Edit file
This edits the default startup script for the root account. Use the arrow keys to scroll up or down and sideways on the line. You can use the delete key or backspace key to delete data on the line. The enter key inserts a blank line. Any lines that have a # means the text to the right of the # are comments.
As you can see, the front of the file we are editing has comments. A good habit to get into is to add your own comments to the file about what you are changing and the date you did it. Mark my words this will save your butt later sometime when you want to know what changes you did to the file and when. So add a comment like this:
# Changed by yourname date changed set prompt and default editor
Scroll down using the arrow key until you find:
setenv EDITOR vi
Use the arrow keys to position the curser on the s of setenv.
Press the # key to comment out this line.
Use the arrow key to move the curser back to the # you just entered.
Press enter to insert a blank line.
On the blank line type in:
setenv EDITOR ee
You just set the ee editor as your default editor.
Now continue scrolling down until you see an IF statement followed by a line containing:
set prompt = "'hostname -s'# "
You are going to do the same thing here as you did for the setnev.
Comment out the old line,
insert a blank line,
type in the following new command,
set prompt = "# %/ >"
The changed parts of the file should look like this.
The bold lines are what you should have changed.
#setenv EDITOR vi
setenv EDITOR ee
setenv PAGER more
setenv BLOCKSIZE K
if ($?prompt) then
# An interactive shell -- set some stuff up
set prompt = "# %/ >"
#set prompt = "`hostname -s`# "
Press ESC key to exit.
A window pops up that has the curser on leave editor option, press enter.
Another pop up window asks if you want to save changes, press enter to save.
You have just made your first FBSD configuration change.
To test your change, enter exit on the command line. When the system login prompt returns, log in as root again and your command line should look like this:
# /root >
No matter where in the directory tree you go, the command line will be prefixed with the directory path of your current directory location.
To make these settings the permanent global default for all users you add to your system later, you have to edit another file and add the following statements:
ee /etc/csh.cshrc
setenv EDITOR ee
set prompt = "# %/ >"
Save the file and when you add users later they will have these defaults.
When you login as root you receive the system wide Login Announcement. The text for this message is contained in a file /etc/motd. The /etc directory is the location of all the FBSD startup configuration files.
So lets change the Login Announcement file motd.
cd /etc # Change into directory
ls # List contents of directory
ee motd # Edit file
As you can see the text in the motd file is just instructions about how to change the contents of the motd file. I suggest you delete every thing in this file except the 'Welcome line'. But you can say anything you want.
Pressing the Ctrl key and the 'k' key on the keyboard at the same time will delete a whole line at a time. After saving your changes, enter exit on the command line to log out. Then log back in to see your new motd Welcome message.
Now that you have entered a few commands, I will introduce you to the command line history function. Your curser is the little white box and it's positioned on the blank command line, use the keyboard up arrow key and the last command you issued will be inserted on the command line. Each time you press the up arrow key the next previous command from the history list will be inserted on the command line. If you passed by the command you wanted, you can use the down arrow key to transverse the history list in reverse order. Hitting the enter keyboard key will execute the command on the command line.
Pressing the keyboard ALT key and one of the F1 through F8 keys will present you with another session login prompt. You can have up to 8 concurrent sessions all logged in as the same user. This is real handy when you want to copy some text from one file to an other file or when you are doing a kernel recompile and you still want to do something else on your system while the compile is running. You press ALT F2 and login as root and do whatever you want to do without effecting the status of your F1 session.
All the operating system logs are stored in the same location, /var/log.
Lets go look at the logs.
cd /var/log # Change into directory
ls # List contents of directory
ee messages # Edit file
We are only interested in the messages file at this time.
This file holds all the console messages for user root account. The operating system posts all of its error messages to user root console screen if the root user is logged in and a copy is posted to this messages file. No other user account will see any system messages.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/04.10-enabling_clear_tmp.htm 000644 000000 000000 00000023630 10433404271 025231 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
The /tmp directory is where FBSD places all of its temporary work files created during port installs, cvsup, and package installs. The problem is this directory never gets emptied and can start to consume a lot of hard disk space. Many users wonder why their system wide backups start taking longer and longer to complete. Its because the /tmp directory is growing. The /tmp directory can be cleared every time you boot the system. You have to customize /etc/rc.conf file to enable this function be adding this statement
ee /etc/rc/conf
clear_tmp_enable="YES" # YES has to be in capital letters
The mouse has a copy/paste function which defaults to a 3 button mouse. Many users are unaware the mouse copy/paste function even exists, because they have an industry standard 2 button mouse. Why the mouse program has not been updated to use the industry standard 2 button mouse as its default is unknown. You will find it very useful when editing a file or any time you want to copy & paste some message from your screen to a file. There is really no 'cut' function as you know it from MS/Windows. If you read the moused manual documentation, you will see that they call it cut and paste. That is a error in the documentation (it can not cut, as in remove the highlighted text from the screen or edit file) it only copies the highlighted text to the internal paste buffer. Just think of it as copy and paste.
The logical button 1 (logical left) selects a region of text on the console screen and copies it to the paste buffer. The logical button 3 (logical right) extends the selected region. The logical button 2 (logical middle) pastes the selected text at the text cursor position.
During the install process you were asked if you have an USB mouse. If not sysinstall presented you with options to configure your non-USB mouse, the results of which were inserted into the master start up configuration file /etc/rc.conf as a group of over ride options statements.
You have to customize /etc/rc.conf file to enable the non-USB 2 button mouse copy/paste function.
ee /etc/rc/conf
your /etc/rc.conf should look like this:
# Enable network daemons for user convenience.
# Please make all changes to this file, not to /etc/defaults/rc.conf.
# This file now contains just the overrides from /etc/defaults/rc.conf.
moused_enable="YES"
moused_port="/dev/psm0" # you may have different device
device here moused_type="auto"
Add this statement:
moused_flags="-m 2=3" # config for 2 button mouse
Also add this statement to enable the mouse and the blinking text curser on all virtual terminals:
allscreens_flags="-m on -c blink" # -m enable mouse curser on
# -c enable console curser to blink
Save the rc.conf file and reboot your system for your edit changes to take effect.
Your /etc/rc.conf should look like this:
ee /etc/rc.conf
# Enable network daemons for user convenience.
# Please make all changes to this file, not to /etc/defaults/rc.conf.
# This file now contains just the overrides from /etc/defaults/rc.conf.
usbd_enable="YES"
Add this statement to enable the mouse and the blinking text curser on all virtual terminals:
allscreens_flags="-m on -c blink" # -m enable mouse curser on
# -c enable console curser to blink
Save the changed file.
The /etc/usbd.conf file is where the USB 2 button mouse is specified at.
ee /etc/usbd.conf
Scroll to the bottom of the file until you find this statement:
attach "/usr/sbin/moused -p /dev/${DEVNAME} -I /var/run/moused.${DEVNAME}.pid"
You are going to change this line by adding the m 2=3 option in front of the p option so it looks like this:
attach "/usr/sbin/moused m 2=3 -p /dev/${DEVNAME} -I /var/run/moused.${DEVNAME}.pid"
Save the changed file and reboot your system for your edit changes to take effect.
With the mouse enabled you will now see two cursors on your console screen. The mouse cursor is a white arrow that moves with the mouse. The other cursor is a white block which is the UNIX text cursor.
Move the mouse arrow cursor to the start of some word that is displayed on your screen. Depress the left mouse button and hold it down while you drag the mouse to highlight the word you want to copy. Release the left mouse button at end of what you want to copy. Whatever you highlighted has been copied to the internal paste buffer. The UNIX white block text cursor is on the command line. Move the mouses white arrow to the command line; pressing the right mouse button will paste the selected text on the command line.
When using the ee editor the copy/paste function works fine. You just have to use the keyboard arrow keys to move the UNIX white block text cursor to the location you want to paste your text.
There is a kernel source option to change the mouse arrow pointer to a color red block. I found the white small arrow gets lost on the screen among all the white letters of the words. Sometime soon you will be building your own customized kernel source. So keep this mouse curser option in mind when you build your own custom kernel. Add the following statement to your kernel source and recompile.
options SC_ALT_MOUSE_IMAGE # Show red Block curser not arrow
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/04.12-Scroll_lock.htm 000644 000000 000000 00000024037 10433404271 023676 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
While your system boots, probe messages scroll across the console screen so fast that you can not read them. Or when you list the contents of a large directory the same thing happens. The messages may have scrolled off your screen, but they are still in the screen buffer. You can redisplay the messages from the screen buffer. You hit the keyboard 'scroll lock' button, (IE: top row right side) and then use the keyboard up arrow button to scroll back through the screen buffer to redisplay the message lines. The 'page up' and 'page down' buttons also work to move backward and forwards through the screen buffer one full screen page at a time. Hit the 'scroll lock' button again when you are finished to return to the command line prompt.
The default size of the screen buffer is to small to contain all the boot messages, so it should be increased to 200 lines.
This is how you increase the size of the screen buffer.
Add the -h 200 option onto the allscreens_flags= statement you already added to the /etc/rc.conf file
ee /etc/rc.conf
and make it look like this:
allscreens_flags="-m on -c blink h 200" # -m enable mouse
# -c enable curser to blink
# -h size of scroll lock
# buffer in number of lines
Save the changed file and reboot
your system for your edit changes to take effect.
Your FBSD operating system has internal software applications (like sendmail for one) that needs to know the fully qualified domain name of the PC it's running on. You do this by adding the option statement hostname= to /etc/rc.conf.
This is the format to use.
thisPCname.fakeDOMAINname.tld
Where thisPCname came be any name you want to identify this particular PC on your LAN. Since the goal of this Installation Guide is to build a FBSD gateway server, the name of this PC should be gateway.
Where .fakeDOMAINname can be any name you want as long as it's not a registered domain name on the public Internet (unless of course it's registered to you). Using FBSDyourlastname is a safe fake domain name to use here. So if your name was Tom Jones, you should use fbsdjones.
Where .tld can be any of the standard TLD's currently in use. Such as .com or .usa or .info or .cc, but since .com is the most commonly used TLD, I recommend using .com.
gateway.fbsdjones.com is a very acceptable fake host name to use.
ee /etc/rc.conf
and add this option statement to the file:
hostname="gateway.fbsdjones.com"
Save the changed file and reboot your system for your edit changes to take effect.
When the reboot stops at the login prompt, the line displayed just above it will now contain your host name you just added to rc.conf.
Installer Note:
If you have an official registered domain name that you want to use for your email sendmail server, then use that in the hostname= statement. Example, if my registered domain name was cyberman.com then hostname=cyberman.com is what I would code.
FBSD looks in this file first to reconcile private LAN domain names to IP address. This includes the domain name you assigned to this FBSD system with the 'hostname=' statement from the above step.
ee /etc/hosts
Find this statement:
127.0.0.1 localhost localhost.my.domain
Change this to:
127.0.0.1 localhost gateway.fbsdjones.com
Fetchmail looks for 127.0.0.1 localhost to work correctly.
Save the changed file and reboot your system for your edit changes to take effect.
By default, the console driver will not attempt to do anything special with your screen when it's idle. If you expect to leave your monitor switched on and idle for long periods of time then you should probably enable one of these screen savers to prevent phosphor burn-in.
Add the following statement to /etc/rc.conf and replace the xxxxxx with the keyword of the screen saver you want to use.
ee /etc/rc.conf
saver="xxxxxx"
Keyword Description
blank Simply blank the screen black>
daemon Animated BSD Daemon (text)
fade Fade out effect
fire Flames effect
green Green power saving mode (if support by monitor)
logo Animated BSD Daemon (graphics)
rain Rain drops
snake Draw a FreeBSD snake on your screen
star Twinkling Stars effect
warp Stars Warping effect
The default time interval is 300 seconds (5 minutes) of being idle before the screen saver is activated automatically. To change the time interval, add the following statement to /etc/rc.conf and substitute the interval time you want in seconds for the xxx value.
blanktime="xxx"
FBSD has a built in email server (MTA) mail transport agent called sendmail. It is preconfigured to be totally operational once you tell it the domain name it's to use to represent itself. You just did that in the previous step with hostname="gateway.fbsdjones.com". Sendmail will now handle all the mail services for account-name@gateway.fbsdjones.com. The main point being made here is that the email sever is all configured and ready to go without any additional changes needed. When you add users to your system, they have to belong to the "mail" group to retrieve mail from the sendmail server through the pop3 server qpopper.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/05.00-Accessing_the_internet.htm 000644 000000 000000 00000035721 10433404271 026077 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
-------- -------
|FreeBSD | | |<--> ISP's
| System |<----------->| Modem | Gateway
| | eth0 | |
-------- -------
This is what your configuration will look like after completing this section. The eth0 symbol represents the connectivity from an internal or external dial out modem, or an Ethernet cable between a system NIC connected to a DSL or cable modem. FBSD communicates across this outbound link to your ISP and from there out to the public Internet.
There are basically two providers of access to the public Internet in service today. The public telephone industry and the cable television industry. Both have copper wires connected to your house and in some cases to your business location. A marriage of satellite dish TV and the telephone has recently been marketed but has not penetrated the Internet access market. A new concept based on wireless radio waves has started to get some attention. It's a bleeding edge technology with high upfront costs, which needs a service area populated with a high density of subscribers to be profitable. Only the products offered by the public telephone industry and the cable television industry are covered here.
The following sections deal with enabling cable Internet access on your FBSD system. For public telephone industry access to the Internet, jump to the Products offered by the public telephone company section.
First of all, the street where you live must have been wired for cable TV. The cable service provider generally provides the cable modem as part of the Internet service. Some cable providers will let you chose what kind of cable modem to use. Do not select a USB cable modem. If the external cable modem has both USB and Ethernet ports on it, always use the Ethernet port. An Ethernet connection is more reliable than USB. The cable modem uses a short Ethernet cable with UTP-45 connector plugs on each end to plug into the cable modem and the Nic card in your FBSD system. Cable service is an "always on" service and has security implications. The user must make provisions for installing a firewall to keep out unwanted intruders. Most cable Internet service is based on wide area network technology and uses DHCP to provide all the necessary connection info to your PC. Get the specific details from your cable Internet access provider.
If you are following the 'incremental install method' recommended in this Installers Guide, then it's now time to install a single PCI NIC in your PC and cable it to your external cable modem. First make note of the manufacture of the NIC and what chips are used on the printed circuit board, as you may need this info to locate the correct device statement if the GENERIC kernel can not identify your NIC. With the power off to your PC, the cable modem, and with the PC case open, insert your PCI NIC into any of the PCI slots. Plug in the cable to the port on the external side of the NIC. Plug in the other end of the cable into the cable modem. Power on your PC and cable modem.
Remember that at this time your PC should only have a single NIC installed. There should not be any other PCI expansion cards installed as that is what this Installers Guide expects. PCI NICs come in different speeds. For the home user a 10Mbps speed NIC is more than adequate. Today prices have fallen so much on NICs that 10/100Mbps NIC are bargains and have almost forced the 10Mbps NICs out of the market.
On the first boot after installing your PCI NIC review the boot messages by hitting the 'scroll lock' keyboard key and then use the 'page up' key. You can also edit the /var/run/dmesg.boot log to verify that it was found.
This is what you are looking for in the boot log,
This means the GENERIC kernel found your NIC.
dc0: <Macronix 98715/98715A 10/100BaseTX> port 0xdc00-0xdcff mem
0xe30000ff irq 3 at device 19.0 on pci0
dc0: Ethernet address: 00:80:c6:f2:2e:3b
miibus0: <MII bus> on dc0
dcphy0: <Intel 21143 NWAY media interface> on miibus0
dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc0 is the NICs internal interface name. Yours will more than likely be different, and that's ok.
The GENERIC kernel contains device statements for most of the NICs currently on the market. If the /var/run/dmesg.boot log shows your NIC as:
pci0: <unknown card> (vendor=0x1274, dev=0x5000) at 19.0
or no message to indicate the probe of the BIOS found any new PCI devices, then you may have legacy BIOS on your PC which does not handle PCI cards very well. On older (IE: pre Y2K) PC BIOSs, it's very common for the system probe process of the BIOS to be unable to find one or more PCI cards. If this happens to you, you have to do some research to determine the problem.
Try the pciconf -lv command to see if it gives you any useful info. Then review the GENERIC source at /usr/src/sys/i386/conf/GENERIC to see if it contains a device statement comment about your NIC based on the manufacturer or chips used. If you do find a device statement in the GENERIC source for your NIC, then add this statement to your kernel source and recompile your kernel:
device pun
This device has additional code to probe your systems BIOS using different methods which in most cases results in your PCI NIC being found.
If the review of the GENERIC kernel source produces no results, then review the kernel source file named LINT at /usr/src/sys/i386/conf/ for comments that describe your NIC by manufacturer's name or chips used and copy the appropriate device statements to the GENERIC kernel source file. Then follow the instructions at Kernel Customizing. You will have to create a custom kernel from the GENERIC source including the device statement from the LINT source.
If you find no kernel device statements for your NIC, then its not supported and you have to get one that is.
Your cable provider has computers called DHCP (Dynamic Host Configuration Protocol) servers that will automatically provide your FBSD system with all the information it needs to communicate over the Internet. In order to communicate with the cable provider's DHCP servers, you must configure your systems NIC that is cabled to the cable modem to use the DHCP client software that is built into your system.
Assuming your cable modem is physically connected to your cable provider with a functioning circuit, that the cable service's ISP has provisioned the modem so they know your modem is authorized, and their DHCP server is running, you should be able to connect to your cable ISP.
First issue the following command to display all network interface parameters. You are looking for the NIC's interface device name.
ifconfig
If your NIC is found, it will show in this display.
dc0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
ether 00:80:c6:f2:2e:3b
media: Ethernet autoselect
status: no carrier
lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552
faith0: flags=8002<BROADCAST,MULTICAST> mtu 1500
The lp0, lo0, ppp0, and faith0 are all kernel default internal interfaces. The dc0 interface would be the interface name of your NIC. Yours will more than likely be different, and that's ok.
To active DHCP on that NIC, edit /etc/rc.conf and add the following statement:
ee /etc/rc.conf
ifconfig_dc0="DHCP"
Where dc0 is your NIC's interface name.
Reboot your system. After logging in issue:
ifconfig
This time you see the IP address assigned to you by your Cable ISP.
In this example it's 68.169.105.81
dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 68.169.105.81 netmask 0xffffff00 broadcast 68.169.105.255
ether 00:80:c6:f2:2e:3b
media: Ethernet autoselect (none)
status: no carrier
On the command line enter a ping command to some known Internet site:
ping -c2 216.136.204.21
This tests if you can reach the Internet. This is a site I know is there. But like everything else it may go away in time.
Now check out that your ISP DNS servers are functioning correctly.
ping -c2 freebsd.org
Check that resolv.conf name server statements have automatically been filled in with the IP addresses of your ISP's DNS servers.
ee /etc/resolv.conf
It should look something like this, but contain your ISP specific info:
ee /etc/resolv.conf
It should look something like this, but contain your ISP specific info:
search your.isp_dhcp_server.net
nameserver 168.168.240.222
nameserver 168.168.240.225
Issue ifconfig one more time.
dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 68.169.105.81 netmask 0xffffff00 broadcast 68.169.105.255
ether 00:80:c6:f2:2e:3b
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
The status is now active. You now have a working connection to the public Internet. Your system is wide open; you are now vulnerable to attacks from the public Internet. It's best to power off your PC when you are not working on it, at least until you get a firewall installed. You should now go to the Network-Security section.
If you are unable to get DHCP to connect you to your cable ISP, call your tech support department and request them to verify they have provisioned your modem and that they can ping it.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/05.02-Products_offered_by_phone_co.htm 000644 000000 000000 00000035155 10433404271 027274 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
This is what everybody commonly calls voice modem dial in service.
This has been around since the 1960's and used to be the only way to get speeds faster than analog voice dial in speeds. It's basically a leased line dedicated to computer usage. This Guide does not contain instructions on configuring legacy ISDN access to the public Internet.
DSL, or Digital Subscriber Loop, is a high-speed Internet access technology that uses the standard copper telephone lines. DSL provides a direct, dedicated connection to an ISP via the existing telephone company network. DSL is designed to run on up to 80% of the telephone lines available in the United States. By using line-adaptive modulation, DSL is capable of providing data speeds of 8 Mbps or more.
DSL services are now being aggressively marketed for home and small business use around the USA. DSL is typically priced below ISDN, and well below T1 service, yet can provide potentially even greater speeds than T1 without the cost, complexity, and availability issues of T1. Since DSL is a dedicated line, it provides "always on" service and avoids the delays and use charges that are common with ISDN, making this quite a nice technology for the bandwidth starved Internet power users. This "always on" service has security implications; the user must make provisions for installing a firewall to keep out unwanted intruders.
While all this sounds exciting, DSL does have some drawbacks. The quality of the DSL signal, and thus the connection, depends on distance (the length of the copper "loop") and various other factors. DSL service is basically limited to a 3 mile radius around the phone company's local substations. Also there is no such thing as standard "DSL". There are various flavors of DSL, and many, many ways DSL providers are implementing their networks.
There are PCI DSL internal modems available on the market. Some DSL providers will let you chose what kind on DSL modem to use. Do not select a USB DSL modem. If the external DSL modem has both USB and Ethernet ports, allways use the Ethernet port. Ethernet is a more reliable connection. The DSL modem uses a short Ethernet cable with UTP-45 connector plugs on each end to plug into the DSL modem and the NIC in your FBSD system. For more in-depth description on DSL see http://en.tldp.org/HOWTO/DSL-HOWTO/overview.html
These are referred to by the industry as T1 lines and have such a large capacity that home users or small businesses could never fully utilize one. This type of line is very costly. This Guide does not contain instructions on configuring T1 access to the public Internet.
If you are following the 'incremental install method' recommended in this Installer Guide, then it's now time to install your voice phone modem. Halt your system and power off the PC. While the power is off, you can cable your external serial modem to the PC com1 nipple or com2 nipple located on the back side of your PC. Or plug your internal PCI modem into any PCI slot.
Installer Note:
All instructions are based on 56K type modems. If you are using a legacy modem (9600, 14.4, or 33.6 max baud) its your responsibility to adjust the 115200 value to one that is applicable to your modem.
Internal PCI phone modems are manufactured for two target markets, MS/Windows (Winmodems) and every thing else. Winmodems are cheep because the hardware controller function is handled by the software you have to install into MS/Windows. This hardware controller function is normally contained in a chip on the modem circuit board. Winmodems are missing this chip and directs the modem to use driver software running in the MS/Windows system to perform the controller function. The most common Winmodem chips are manufactured by Lucent. There are many versions of this Lucent chip resulting in each chip version needing a different MS/Windows software driver version.
Up until version 4.4, FBSD did not have any solution to using Winmodems, but with the release of 4.4 the ports collection now contains the "Linux Winmodem 'ltmdm' driver" which was ported to FBSD. This port is very poorly documented, only works with a limited number of Lucent chip version, and can be somewhat unreliable. Your whole Internet connection is managed by your modem and trying to shoe horn a modem specially manufactured for the MS/Windows operating system into FBSD is not the way to achieve a satisfactory dialup Internet connection. This guide does not cover installing the ltmdm Lucent Winmodem driver port.
Internal ISA expansion slot modem sales has now dropped off to the point where you can no longer buy a new one. Motherboard manufactures have removed the ISA expansion slots from their motherboards. The ISA internal modems have been replaced with internal PCI modems.
The newest entry into the modem market is the USB external modem. FBSD supports USB plug in external modem devices. These are also Winmodem versions of external USB modems, so be careful what you plug into FBSD.
For the FBSD newbie, or for that matter, any FBSD user who wants dial up Internet connection with the least amount of effort, should use an external serial modem for connecting their FBSD box to the Internet. This method works using the default generic kernel, creates no IRQ conflicts with the motherboard BIOS, and will work right out of the box so to say. All external serial modems use the PC's serial port controller built into the motherboard. This has been the standard since PC's first came out. I recommend the Zoom model 3049L external modem; it works right out of the box.
If you want to use an internal PCI modem in FBSD, you have to get a PCI modem card that has an onboard controller and DSP. Even under MS/Windows it's better to use a internal PCI modem that has a hardware controller. These cost around $70.00 to $100.00 in the USA. I recommend the Zoom model 2920 internal PCI PLUS modem.
The boot log /var/run/dmesg.boot is where you look to find out if FBSD found your modem.
If you are using a external serial modem, the PC's BIOS must have the com ports enabled.
This is what you will see in dmesg.boot if your PC BIOS has the com ports enabled.
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
This is what you will see if your PC BIOS has the com ports disabled.
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 8250
sio1: configured irq 3 not in bitmap of probed irqs 0
sio0 = PC com1 nipple = FBSD device cuaa0
sio1 = PC com2 nipple = FBSD device cuaa1
The device name cuaa0 or cuaa1 is the device name you tell 'user ppp' to use to connect to your external modem.
FBSD has a program called 'tip'. This program talks directly to the physical PC com ports and to the logical serial com ports, commonly referred to as com1, com2, and com3, and com4. External modems use com1 and com2 because there are only two com port nipples on the back of the PC.
You are going to use the 'tip' command to test if FBSD can communicate with your modem. This test will verify that FBSD can connect to the external serial modem and also that it will respond to the Hayes commands you will issue to it.
The tip comx command uses the /etc/remote file for the definition of comx. I have listed the whole group of comx statements here so you can better find them in the /etc/remote file.
ee /etc/remote
# Finger friendly shortcuts
sio0|com1:dv=/dev/cuaa0:br#9600:pa=none:
sio1|com2:dv=/dev/cuaa1:br#9600:pa=none:
sio2|com3:dv=/dev/cuaa2:br#9600:pa=none:
sio3|com4:dv=/dev/cuaa3:br#9600:pa=none:
sio4|com5:dv=/dev/cuaa4:br#9600:pa=none:
sio5|com6:dv=/dev/cuaa5:br#9600:pa=none:
sio6|com7:dv=/dev/cuaa6:br#9600:pa=none:
sio7|com8:dv=/dev/cuaa7:br#9600:pa=none:
As you can see this file has not been updated to reflect the serial port baud rate of the modern modems currently on the market. These statements are configured for 9600 baud legacy modems which have not been manufactured in 10 years. The serial port baud rate is the speed that the serial port controller talks to the modem hardware. Its not the speed the modem connects to the remote modem.
Change all the 9600 to 115200 which is the serial port baud rate for 56K modems.
ee /etc/remote # and make it look like this
# Finger friendly shortcuts
sio0|com1:dv=/dev/cuaa0:br#115200:pa=none:
sio1|com2:dv=/dev/cuaa1:br#115200:pa=none:
sio2|com3:dv=/dev/cuaa2:br#115200:pa=none:
sio3|com4:dv=/dev/cuaa3:br#115200:pa=none:
sio4|com5:dv=/dev/cuaa4:br#115200:pa=none:
sio5|com6:dv=/dev/cuaa5:br#115200:pa=none:
sio6|com7:dv=/dev/cuaa6:br#115200:pa=none:
sio7|com8:dv=/dev/cuaa7:br#115200:pa=none:
After saving your changes you are now ready to test your modem.
On the command line enter;
tip comX where X is the com port your external modem is on.
The available choices are com1 or com2.
Connected
is displayed meaning 'tip' has made contact with the external modem.
Type AT and then hit enter. # 'AT' is the Hayes attention command.
'OK' is displayed.
This means the Hayes attention command was received by the modem and issued its normal reply of 'OK'. Your modem configuration has passed the test and is functional.
You now have to train the modem to use 115200 as the internal default baud speed. Enter the AT Hayes command 10 times, you will receive the OK reply from the modem each time. This is a very important step that has a very large impact on the performance of your modems throughput, do not bypass this step.
Use the keyboard ~ key followed by the . key to exit tip.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/05.03.6-Internal_PCI_modem.htm 000644 000000 000000 00000020777 10433404271 025234 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
Sometimes the GENERIC kernel cannot identify your internal modem and lists the offending PCI modem card as (unknown card) in the /var/run/dmesg.boot log. This problem can also be caused by PCs with pre-Y2K BIOS.
pci0: <unknown card> (vendor=0x1106, dev=0x3050) at 7.3
You will also get this message if your PCI modem is a Winmodem. Very seldom is the PCI modem physically labeled or marked as a Winmodem. Read the marketing information on the box your PCI modem came in, or check out the support web site for the PCI modem's manufacturer to verify it's a Winmodem. If your PCI modem is a Winmodem, replace it.
Try the pciconf -lv command to see if it gives you any useful info.
Some older PCs have BIOS which cannot correctly ID PCI modems. Your only remaining option is to customize the kernel source by adding the following device statement at the end of the kernel source and then recompiling.
device puc
This kernel option enables the 'puc' (PCI Universal Communications) driver which does additional probing during the boot process to help connect PCI-based serial ports to the 'sio' driver. I have not found a situation on desktop PCs where this did not fix the PCI modem <unknown card> problem, as long its not a Winmodem.
When the boot probe process finds a PCI modem it automatically moves it to sio4 as the dmesg.boot messages shows below.
sio0: <Zoom PCI Modem> port 0xe400-0xe407,0xe000-0xe0ff,
mem 0xe2000000-0xe20000ff irq 3 at device 19.0 on pci0
sio0: moving to sio4
sio4: type 16550A
Sio4 is internal device cuaa4.
You are going to use the 'tip' command to test if FBSD can communicate with your modem. This test will verify that FBSD can connect to the PCI modem and also that it will respond to the Hayes commands you will issue to it.
The tip comx command uses the /etc/remote file for the definition of comx. I have listed the whole group of comx statements here so you can better find them in the /etc/remote file.
ee /etc/remote
# Finger friendly shortcuts
sio0|com1:dv=/dev/cuaa0:br#9600:pa=none:
sio1|com2:dv=/dev/cuaa1:br#9600:pa=none:
sio2|com3:dv=/dev/cuaa2:br#9600:pa=none:
sio3|com4:dv=/dev/cuaa3:br#9600:pa=none:
sio4|com5:dv=/dev/cuaa4:br#9600:pa=none:
sio5|com6:dv=/dev/cuaa5:br#9600:pa=none:
sio6|com7:dv=/dev/cuaa6:br#9600:pa=none:
sio7|com8:dv=/dev/cuaa7:br#9600:pa=none:
As you can see this file has not been updated to reflect the serial port baud rate of the modern modems currently on the market. These statements are configured for 9600 baud legacy modems which have not been manufactured in 10 years. The serial port baud rate is the speed that the serial port controller talks to the modem hardware. Its not the speed the modem connects to the remote modem.
Change all the 9600 to 115200 which is the serial port baud rate for 56K modems.
Make your changes look like this:
ee /etc/remote
# Finger friendly shortcuts
sio0|com1:dv=/dev/cuaa0:br#115200:pa=none:
sio1|com2:dv=/dev/cuaa1:br#115200:pa=none:
sio2|com3:dv=/dev/cuaa2:br#115200:pa=none:
sio3|com4:dv=/dev/cuaa3:br#115200:pa=none:
sio4|com5:dv=/dev/cuaa4:br#115200:pa=none:
sio5|com6:dv=/dev/cuaa5:br#115200:pa=none:
sio6|com7:dv=/dev/cuaa6:br#115200:pa=none:
sio7|com8:dv=/dev/cuaa7:br#115200:pa=none:
After saving your changes you are
now ready to test your modem.
On the command line enter:
tip com5 # com5 is your PCI modem
Connected
is displayed meaning 'tip' has made contact with the PCI modem.
Type AT and then hit enter. 'AT' is the Hayes attention command.
'OK' is displayed.
This means the Hayes attention command was received by the modem and issued its normal reply of 'OK'. Your modem configuration has passed the test and is functional.
You now have to train the modem to use 115200 as the internal default baud speed. Enter the AT Hayes command 10 times. You will receive the OK reply from the modem each time. This is a very important step that has a very large impact on the performance of your modem's throughput. Do not bypass this step.
Use the keyboard ~ key followed by the . key to exit tip.
Remember, device cuaa4 is the device you tell user ppp to use.
NOTE: If you get this message;
Interrupt storm detected on irqX:, throttling interrupt source.
This means your PCI modem is sharing it's interrupt with another expansion board in your PC. Try moving the PCI modem card to different expansion slots on the motherboard until its not sharing it's IRQ with anything.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/05.04-Internet_access_protocols.htm 000644 000000 000000 00000040664 10433404271 026653 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
In the early 1990's there were 2 protocol standards for accessing the Internet (PPP & SLIP). The SLIP protocol never became accepted by the ISP community and has pretty much fallen by the way side. For all practical purposes it is dead and is only mentioned here as background information. If the ISP you want to use only offers SLIP access, you better look for a different ISP.
The PPP protocol is currently the standard access protocol in use at all ISP's in the USA and most other countries. FBSD has two different built in PPP software solutions. They are kernel PPP and user PPP. Kernel PPP (PPPD) was the original software solution and has been part of FBSD for a very long time. Kernel PPP is well known by its long time users as being very hard to configure and debug during the process to get it to dial and login to your ISP. Back in the 3.x versions kernel PPP got a complete rewrite to correct those problems and is now called user PPP. Kernel PPP has been left in FBSD for backward compatibility for the old timers who already have a working configuration. User PPP has become the standard. You really do not want to waste your time playing with legacy kernel PPP.
User PPP has none of the shortcoming of legacy kernel PPP. It is easy to configure using a single configuration file. It is versatile in that it supports modem dial up, ISDN, leased lines, DSL, and certain cable connection methods to the servicing ISP. It has a log that receives a complete record of the connection attempt for easy debugging. It can be configured for calling out to your ISP or for accepting inbound calls to your FBSD box. It also has a callback feature. User PPP is under maintenance and the only PPP service covered here.
In FBSD, user PPP comes as part of the base system. This means you do not have to do anything to activate it besides building its configuration file. When started, user PPP runs as a daemon task. The 'man ppp' manual contains all the details on starting the daemon and ppp.conf configuration statements. It is very, very large. 'man pppctl' contain documentation on the command line control program of the PPP daemon. For other sources of background information see:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/userppp.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/dialup.html
The following user PPP sections use the 'incremental method' of building additional functions on to the previous functions.
NAT stands for network address translation. This function is also sometimes referred to as "IP Aliasing", "Address Masquerading" or "Transparent Proxy". They all mean the same thing. This is necessary when your FBSD system is going to be a gateway for a LAN and all the workstations on the LAN are going to share the public Internet address. In a gateway/LAN environment each workstation must have an IP address to communicate across the LAN to the gateway box. This is accomplished by using private IP addresses that are reserved for that purpose. See the /etc/hosts file for a list of reserved IP address ranges. User PPP NAT translates the private IP address of packets from the LAN workstation to the public IP address to communicate across the public Internet, and when the reply packet returns it get translated from the public IP address to the private IP address of the LAN workstation that originated the packet. Another situation where NAT would be necessary would be when one or more modems are added to the FBSD box to answer incoming calls to share the connection to the Internet through the FBSD gateway system. If the FBSD box is a standalone system with no incoming remote users, or LAN, then user PPP NAT is not necessary at all.
User PPP has a single configuration file where all the standard functions it is capable of performing must be defined. To be technically correct, user PPP does have some other config files that can be used for very special purposes. They are so seldom used that the fact they even exist is only mentioned here as background information.
The only user PPP config file you need to work with is ppp.conf which lives in the /etc/ppp/ directory. The following ppp.conf statements listed below can be used just as is. It has been tested and works. You can copy and paste them right from this html file.
cd /etc/ppp/ # Move into directory where conf file lives
cp ppp.conf ppp.conf.org # Save copy of original
rm ppp.conf # delete original ppp.conf file
ee ppp.conf #edit file so it looks just like the following
Add the following statements
Read the embedded comments and do what they say.
######### start of the ppp.conf file ##################
#
# Note:
# Section header names start in position 1 like default:
# All embedded commands start in position 2.
#
default:
# The default section is processed every time
# user PPP is started. Everything set here applies
# to all of the following sections.
set log Phase Chat LCP IPCP CCP tun # for testing
#set log Phase tun
# use to avoid excessive log sizes
set speed 115200
# serial port speed for 56K modems
set timeout 0
# no idle time, will not disconnect
disable pred1 deflate lqr # compression features
deny pred1 deflate lqr # line quality reporting
disable ipv6
# turn off ipv6 challenge
# This label is the start of the commands
# for auto logon to ISP provider.
dialisp:
# Ensure that set device statement references
# the correct serial port for your modem.
# (External com1 = cuaa0, com2 = cuaa1)
# PCI modem com5 = cuaa4
# Only needed for dial out device.
set device /dev/cuaa4
# This dial string is needed for ISP's which
# use standard Unix style login.
# Which is most all ISP's.
#
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \
\"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"
# Edit the next three lines and replace the values with
# the values which have been assigned by your ISP.
set phone 7777777 # phone number to call ISP
set authname XXXXXXX # your ISP account ID
set authkey 555555 # your password
set redial 10 4
# if busy redial 4 times with 10 second pause
# If your ISP assigns you a (dynamic) different IP
# address each time you log in, then use the following
# statement. If your ISP issued you a (static never changes)
# IP address to use every time you log in, then comment
# out the next statement and uncomment the statements
# following it.
# Get dynamic IP address from ISP if that's how they do it.
set ifaddr 0.0.0.0/0 0.0.0.0/0 0.0.0.0 0.0.0.0
# Use static IP address from ISP if that's how they do it.
# Set static IP address your ISP assigned to you.
# s.s.s.s = your static IP address
# set ifaddr s.s.s.s 0.0.0.0/0 0.0.0.0 0.0.0.0
add default HISADDR # Add Mandatory sticky default route
# Gets the ISP's DNS IP address
# places them in resolv.conf for
# reference by FBSD.
disable iface-alias # Stop adding old IP address as alias
# when ppp redials because line was
# lost. These old IPs showed using
# ifconfig -a on tun0.
iface clear
# Remove all previous IP addresses
########## END OF PPP.CONF ##########################
You should have already made your changes to the above ppp.conf file for the phone number to dial to call your ISP and your account and password. You are now ready to do a manual test of your user PPP dialisp configuration.
Enter on the command line the following command to call your ISP and login.
ppp -background dialisp
ppp background means start user PPP immediately, processing the default section of ppp.conf
dialisp means ppp should process the statements in the dialisp section of ppp.conf.
You should hear the normal sounds from your modem as it dials out.
If the connection does not complete successfully you will not get any messages on your screen, you have to look in the ppp.log for the errors.
ee /var/log/ppp.log
No error messages means you connected and logged in successfully. You can still edit the ppp.log file and go to the bottom of the file to see what happened. Each new session appends its log messages to the end of the log file. So to see the current session you have to jump to the bottom of the ppp.log file.
To check out your connection to the Internet, do the following.
Enter ps ax on the command line to see the list of running tasks. You should see an entry that looks just like the command you entered to start user PPP. This means user PPP is running.
On the command line enter a ping command to some known Internet site.
ping -c2 216.136.204.21
This tests if you can reach the internet. This is a site I know is there, but like everything else it may go away in time.
ping -c2 freebsd.org
This test will check out that the DNS servers are functioning correctly.
Check that resolv.conf name server statements have automatically been filled in with the IP addresses of your ISP's DNS servers.
cat /etc/resolv.conf
It should look something like this, but contain your ISP specific info
search your.isp_domain.ttl
nameserver 68.168.240.222
nameserver 68.168.240.225
You stop user PPP by killing the task; there is no hang up command.
killall ppp
Issue the following command to see what the connection speed is;
cat /var/log/ppp.log | grep CONNECT
Every time you dial in to your ISP, the log of that session is appended to the end of the ppp.log. The above command will display all the connected speeds in that log, the last one being the current session or the last session.
To setup user PPP to dial your ISP automatically at FBSD boot time, you have to add the following statements to the /etc/rc.conf file. The ddial option means to redial every time the connection to the ISP gets dropped.
ee /etc/rc.conf
# Activate user ppp auto start at boot time
ppp_enable="YES" # Start User ppp task
ppp_mode="ddial" # ddial, auto redial, run in background
ppp_profile="dialisp" # section in ppp.conf to exec
User PPP has a packet filtering command set. They can be used to deny or accept selected packets from entering your environment. It also has a divert rule to the NAT function. You add your filter commands at the end of the dialisp section. See man ppp for details and /usr/share/examples/ppp/ for examples. User PPP filter rules are very seldom used, as a firewall is the appropriate and more convenient place to perform that function. The user PPP packet filtering command set is not covered in this Guide for that reason.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/05.06-PPP_accept_incoming_calls.htm 000644 000000 000000 00000050500 10433404271 026445 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
User PPP can be configured to wake up when a connected modem answers an incoming call. After successful authentication, the user is logged into your FBSD system. If this FBSD system also has public Internet access, then that user also has access to the public Internet. This function is commonly used to allow the owner of the system to use his FBSD system from a remote location, or to allow a friend to dial in so he can have free Internet access. This is like your FBSD system acting as a one user ISP. Technically you could have one modem for dial out to your ISP for a public Internet connection and up to 6 modems for incoming calls depending on how many PCI expansion slots there are on the motherboard and external serial com port nipples. Or you could have a PCI serial expansion board that shares one IRQ with up to 24 serial com nipples to service even more dial in phone lines. As a matter of fact, this is how the first ISP's did it in the early days.
It must be pointed out that the incoming function does have one drawback. Since there is a sending voice modem calling a receiving voice modem directly, the connection is limited to a max connection speed of 33.6 under the best connections in the USA. This is because of FCC regulation limiting the voltage allowed on the copper wires of the public phone system. This will be true even with 56k modems at both ends. Other countries around the world like Hong Kong, South Africa, and some places in the old USSR who use the old British type voice phone system have higher line voltages and do get higher connection rates using 56k modems at both ends.
The incoming function can be used without the dial your ISP function, like in the case where you have home cable or DSL access to the public Internet and you want to be able to call your home system from work to check your personal Email or to access the public Internet through your home system.
If you're adding the incoming function to your dial your ISP function, its absolutely necessary that you have the user PPP dial your ISP function tested and working first.
How ever you're going to use the incoming function, you must first follow the instructions at How to determine if FBSD found my modem at boot time? to verify the incoming modem is found and connected to your FBSD system.
If you want to use the incoming function without the dial your ISP function, you have to uncomment the commented out statements located at the beginning of the following statements and create a /etc/ppp/ppp.conf file that only contains these statements.
If you are adding the incoming function to your dial your ISP function statements then you can delete the commented out statements located at the beginning of the following statements and add the remaining statements to the end of your current /etc/ppp/ppp.conf file.
Incoming connections are just like LAN connections. Private, non-routable IP addresses must be assigned to the connections. You can copy and paste directly from this web page html file.
ee /etc/ppp/ppp.conf
#### start of section to process incoming modem call #########
#
# Note:
#Section header names start in position 1 like incoming: section header
# All embedded commands start in position 2.
#
# If you are going to use the incoming function without the
# dial your ISP function, then you have to uncomment the
# following statements, otherwise you can delete all the
# commented out statements up to the
# incoming: section header statement.
#
#default: # section header name
#
# set log Phase Chat LCP IPCP CCP tun command #do logging
# set timeout 0 # no idle time, will not disconnect
# disable pred1 deflate lqr # compression features and
# deny pred1 deflate lqr # line quality reporting
#
incoming: # section header name
enable pap # uses ppp.secret file
# SECURITY WARNING - It is VITAL that PAP is enabled.
# If it is not you are allowing any body to establish a
# dial in PPP session with your FBSD box using any
# ID/password. There is no authentication being done on
# incoming PPP connections if PAP is not enabled. SECURITY WARNING
allow users * # allow all users who pass authentication access
accept dns # give dial in connection access to
DNS lookup
# Each incoming sessions needs it own private non-routable
# IP address. The following assigns static private IP address to
# this dial in line and to the receiving FBSD host.
# 10.0.0.2 = Static IP address of this FBSD host
# 10.0.0.5 = Static IP address for this dial in line
set ifaddr 10.0.0.2 10.0.0.5 255.255.255.248
# The following is commented out and is here as a example.
# If I had 4 modems connected to this box, any mix of external
# or internal modems for dial in access and activated the
# appropriate ttyd statements in /etc/ttys file, this incoming
# ppp.conf section will work as is. The following set ifaddr
# command assigns dynamic IP address from
# a range of reserved IP address. 10.0.0.71 through 10.0.0.74.
# 10.0.0.1 is the private IP address assigned to this FBSD host.
# set ifaddr 10.0.0.1 10.0.0.71-10.0.0.74 255.255.255.0
########################### end of file ########################
Every user that will be using PPP dial in services must have an account created on this FBSD box using the adduser or pw commands and have their account ID and password added to the ppp.secret file to authorize them to login using this dial in service. When creating these users be sure to put them in the network group. Only the network group can use dial in services.
cp /usr/share/examples/ppp/ppp.secret.sample /etc/ppp/
ee /etc/ppp/ppp.secret
The ppp.secret file has a heading and will look like this. Add your users like user jones & his password 777666
# Authname Authkey Peer's IP address Label Callback
jones 777666
You have to create a script to launch the user PPP session telling it to read the incoming section. The program ppp belongs to the group network, so you have to change the file ppplogin's group to network and its permissions to read/write for the owner, read/execute for group, and none for everyone else.
cd /etc/ppp # change into directory
ee ppplogin # create new file & enter the following 2 lines
#! /bin/sh
exec /usr/sbin/ppp -direct incoming
Now you have to set the group this new file belongs to and its permissions:
chgrp network ppplogin # assign file ppplogin to network group
chmod 650 ppplogin # set file permissions
A parameter has to be added to the gettytab default section for automatic PPP recognition by specifying the pp capability. It points to the script we want launched. Add pp=/etc/ppp/ppplogin. Make the default look just like this:
ee /etc/gettytab
default:\
:cb:ce:ck:lc:fd#1000:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200:\
:if=/etc/issue:\
:pp=/etc/ppp/ppplogin:
Now you have to activate a tty serial terminal device in the /etc/ttys file to monitor the com port that the inbound modem is connected to. Com1 equates to ttyd0, com2 equates ttyd1, com3 equates ttyd2 and com4 equates ttyd3. You activate the serial terminal monitor ttyd device by changing the keyword off to on.
ee /etc/ttys
I have listed the whole group of serial terminals ttyd statements here so you can better find them in the /etc/ttys file.
#
# name getty
type status comments
#
# Serial terminals
# The 'dialup' keyword identifies dial in lines to login.
ttyd0 "/usr/libexec/getty std.9600" dialup off
secure
ttyd1 "/usr/libexec/getty std.9600" dialup off
secure
ttyd2 "/usr/libexec/getty std.9600" dialup off
secure
ttyd3 "/usr/libexec/getty std.9600" dialup off
secure
As you can see this file has not been updated to reflect the serial port baud rate of the modern modems currently on the market. These statements are configured for 9600 baud legacy modems which have not been manufactured in 10 years. The serial port baud rate is the speed that the serial port controller talks to the modem hardware. Its not the speed the modem connects to the remote modem.
Change all the std.9600 to std.115200 which is the serial port baud rate for 56K modems.
For a PCI modem you have to replicate the ttyd3 line and name it ttyd4 for com5. Remember that when the boot probe process finds a PCI modem it moves it to sio4 which is com5, which has a device name of cuaa4.
In our example of user PPP configuration for incoming calls we are using a PCI 56k modem. You have to create the ttyd4 statement and change the off to on to enable it.
ttyd0 "/usr/libexec/getty std.115200" dialup off secure
ttyd1 "/usr/libexec/getty std.115200" dialup off secure
ttyd2 "/usr/libexec/getty std.115200" dialup off secure
ttyd3 "/usr/libexec/getty std.115200" dialup off secure
ttyd4 "/usr/libexec/getty std.115200" dialup
on secure
Reboot to enable your changes, you will see the ttyd4 serial terminal device you enabled above in the active task list using the ps ax command.
If you want the dial in user to have access to the public Internet you have to add a additional options statements to rc.conf file. Your FBSD system will have to become a gateway.
ee /etc/rc.conf
gateway_enable="YES"
ALL external and internal PCI voice modems since they were first developed have been manufactured to comply to the Hayes standard. When you turn on your modem or reset it, your modem loads the active configuration profile into non-volatile memory (NVRAM). The active configuration profile is a group of configuration settings, derived from the values of the modems internal S registers, that define how the modem will operate. The active configuration profile can be either the factory default, or one of two user defined profiles. The first time your modem is turned on, the factory default profile is loaded into the active profile' in non-volatile memory (NVRAM). The factory default profile is stored in the modems read-only memory (ROM) and cannot be changed. The factory default profile contains standard settings which allow the majority of users to use their modem without ever knowing about the Hayes standard. Modems are not factory configured to answer incoming calls by default, so you will have to manually create your own user profile, enable auto answer on first ring, save it to one of the user profiles in NVRAM, and tell the modem to use it as the default profile on power up and reset.
Use the 'tip' command to send Hayes commands to permanently configure the modem to answer incoming calls.
Note: The Hayes modem commands are capital letters and the '0' is a zero.
On the command line enter
tip comX # where X is the com port your modem is on.
AT&F0 # load the factory default profile0 into current profile.
ATS0=1 # tell current profile to answer on first ring.
AT # Enter AT command 10 times to train modem to 115200 speed
AT&W0 # write current profile to saved user profile0.
AT&Y0 # tell modem to load user profile0 as default on power up.
Use the keyboard ~ key followed by the . key to exit tip.
The serial terminal device ttyd4 is listening on the com port waiting for the PCI modem to answer an incoming call. After the modem answers an incoming call the ttyd4 device recognizes that fact and launches the script ppplogin that was specified by the gettytab pp= option. The ppplogin script issues the embedded command to execute the ppp program using the ppp.conf incoming section to authenticate the caller's ID and password in the ppp.secret file. After a successful login the remote caller can use their web browser to access the public Internet or use telnet to login to their FBSD system account for access to your FBSD system.
To test you need 3 phone lines. One for the FBSD dial out to your ISP, one for your dial in modem and one for a second PC to dial out on to call the FBSD dial in modem. I used a MS/Windows PC to call into the FBSD box. Just make a new dialer from MS/Windows dial-up networking, giving it the phone number of the FBSD dial in modem and use a user ID and password that you have created an account for and added to ppp.secret. After the MS/Windows dialer logs in, you can use telnet to test the connection. You will have to use 10.0.0.2 as the host name to point to your FBSD system if you used the IP address in the above example.
To do this in WIN 95, 98, or ME, click on 'Start', then 'run', type in C:\WINDOWS\command.com and then hit enter. This will open a native DOS window. WINXP has a menu option in accessories for the native DOS prompt. There you type in telnet 10.0.0.2 and press enter. Respond with the user ID and password to get access. Type in 'exit' to terminate the telnet session. This test verifies you have dial in connectivity into your FBSD dial in system. You should be able the use your MS/Windows Internet browser to access the public Internet through your FBSD gateway system.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/05.07-User_PPP_Callback_Feature.htm 000644 000000 000000 00000030235 10433404271 026316 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
There are two common uses for the callback feature. When your FBSD system is answering inbound calls for remote access to the FBSD box, the callback feature provides an additional layer of security. From a security view point, callback is a way of verifying the remote user is really calling from their pre-authorized phone number, which typically is their home or alternate work location.
The second is when your FBSD box calls your ISP and they call you back. In this case the prime motive is who is going to pay for the phone call. The second motive is an additional level of security that only the official owner of the ISP account is requesting remote access. The originating remote user initiates the call, connects and logs in; the receiving system hangs up and then calls back the originator, thus acquiring the phone line charges for the whole time the originating user is on line.
The most popular use of callback in the USA is for a FBSD system answering inbound calls for remote access. This is used by sales people on the road calling from a different phone number each time or the system administrator or an employee calling work from the same home phone number all the time and their employer picks up the long distance phone charges.
The FBSD system calling the ISP and the ISP calling back is not used in the USA because of the cheap phone rates. Other countries around the world like in the old USSR have phone billing rates that are charged by the minute. The ISP has much better rates because they use a greater amount of phone company services. They pass this on to their Internet subscribers by calling the originating user back and picking up the phone bill for the connection.
The documentation for the callback function is in man ppp and some examples in /usr/share/examples/ppp/.
This is your system answering inbound calls for remote access and then calling back the originating user using the same modem the inbound call came in on. This configuration is specifically targeted at originating users using a MS/Windows operating system and calling in from the same phone number every time, like employees working from home. This provides an additional level of security by calling back using a pre-authorized phone number associated with the originating users location listed in the ppp.secret callback field. Placing an * in the ppp.secret callback field will allow the originating user to enter the callback phone number during the setup of the callback process, this is less secure, but much more flexible in where the originating user can call in from. This will also work for originating users using a FreeBSD operating system.
Its absolutely necessary that you have the user ppp incoming call function working before adding the callback function. The callback function is enabled by adding the following statements to the end of the ppp.conf incoming section. Remember these statements have to start at position 2 on the statement line in ppp.conf.
ee /etc/ppp/ppp.conf
########### start of callback section #############
#
set callback cbcp
set cbcp
set log +cbcp
set redial 3 1
set device /dev/cuaa4 # same device as call came in on
set speed 115200
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATZ OK-ATZ-OK \
ATDT\\T TIMEOUT 60 CONNECT"
#
############ End of callback section #############
User ppp uses the /etc/ppp/ppp.secret file to authenticate dial in access. This is where you control the 3 different access modes. You have to edit the callback field of /etc/ppp/ppp.secret with the value representing the selected mode for each user. The fifth field is the callback field.
Mode 1, User calls in and no callback, callback field blank.
Mode 2, User calls in and FBSD calls back using pre-authorized phone number associated with the originating users location listed in the callback field.
Mode 3, User calls in and FBSD calls back using a phone number entered by the originating caller during the callback handshake. Callback field contains an *
Example: Mode 1 tom, Mode 2 bob, Mode 3 Joe,
# Authname Authkey Peer's IP address
Label Callback
tom xxxxxxx
bob yyyyyyy
*
* 14447295555
Joe zzzzzzz
*
* *
When the Windows box calls the dial in modem phone number on the FBSD box, the modem answers the call. Getty senses the call makes the connection, tells the Windows box it wants PAP and asks for ID/PW. Whatever ID/PW is entered at the windows box is checked against the ppp.secret on the FBSD box. At a match ppp sees the callback phone number and talks to the Windows box about setting up callback services before it hangs up the phone. Now the modem that just answered the inbound call is free to dial out using the callback phone number from ppp.secret.
On the Windows box after the dial windows displays a message authenticating ID and password, the window will close after the login is achieved like normal. A new window will open for callback security with a unchangeable option high-lighted [Administrator specified waiting for callback]. This means the phone number in ppp.secret will be called. The Windows box user clicks on OK and the Windows box hangs up its modem and automatically reconfigures its modem for receiving inbound calls.
FBSD does its callback thing using the ppp.secert callback phone number associated with the ID/PW it just authorized from the inbound call. The modem on the Windows box picks up, some hand shaking goes on and you are connected.
Its absolutely necessary that you have the user ppp incoming call function working before adding the ISP callback function. ISP callback is when your FBSD box calls your ISP and they call you back.
Starting with the ppp.conf statements for calling your ISP covered in the Configuring User PPP for modem dial out to ISP section, add to the end of those statements the callback configuration statements to activate the callback function, then you add the incoming section covered in the Inbound ppp.conf statements section.
There are 3 methods of callback your ISP can chose to honor; you specify which one to use by putting the set callback <option> statement at the end of the dialisp section in your ppp.conf file.
Method 1. set callback auth
This means the host you are calling must have your user ID and password in their ppp.secert file with your callback phone number in the 5th field, or an * in the 5th field which will prompt you for the callback phone number before hanging up the phone.
Method 2. set callback cbcp
set cbcp
your_callback_phone_number
This is the Microsoft callback standard. The your_callback_phone_number field must contain the phone number you want to be called back on or an * which means to prompt you for the callback phone number before hanging up the phone.
Method 3. set callback e.164 your_callback_phone_number
This means use the old original e.164 standard to call you back at your_callback_phone_number.
If the host you are calling does not honor the callback method you coded, the connection will be terminated. If you wish callback to be optional you can add the keyword none to the set callback statement and ppp will continue without callback rather than terminating the connection. This is required (in addition to one or more other callback options) to make callback optional.
PPP also allows all the callback options to be coded together on one statement. This will give the called host the choice to select which of the 3 methods it wants to honor.
set callback auth cbcp e.164 your_callback_phone_number none
set cbcp your_callback_phone_number
When your FBSD system calls your ISP, the ISP answers, makes the connection, asks for your ID/PW, and whatever is entered in the ID and password statements of ppp.conf is checked. At a match the ISP's ppp sees the callback phone number and talks to your FBSD system about setting up callback services before it hangs up the phone. Now the modem that your FBSD system just used to make the out bound call hangs up and automatically reconfigures its modem for accepting inbound calls. The ISP does its callback thing. The modem on your FBSD system picks up, some hand shaking goes on and you are connected.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/05.08-PPPoE_ppp.htm 000644 000000 000000 00000022207 10433404271 023235 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
Edit the ppp.conf file and add the following so this is all that is in the file.
Read the comments and do what they say.
cd /etc/ppp/ # move into directory
cp ppp.conf ppp.conf.org # Save copy of original
ee ppp.conf # Edit file add following
#################### start of DSL ppp.conf ###################
default:
set log Phase tun #use to avoid excessive log sizes
set timeout 0 # no idle time out, will not disconnect
dialisp:
set device PPPoE:XXX # replace xxx with your NIC device name
set authname YOURLOGINNAME # Replace with your ISP account
username
set authkey YOURPASSWORD # Replace with your ISP account password
add default HISADDR # Add a (sticky) default route (Mandatory)
enable dns # Gets the ISP's DNS IP address & places them
# in resolv.conf for reference by FBSD box.
############### End of DSL ppp.conf #################################
Replace the XXX in the [set device PPPoE:XXX] statement with the NIC's FBSD interface name. Sometimes it will be necessary to use a service tag to establish your connection depending on how your ISP and/or the phone company has its DSL network configured. Service tags are used to distinguish between different PPPoE servers attached to a given network. You should have been given any required service tag information in the documentation provided by your ISP. If you cannot locate it there, ask your ISP's tech support personnel. This is the format of the command with the service tag added:
set device PPPoE:xxxx:service_tag
The xxxx is the FBSD interface name used by PPPoE. The interface must be UP (IE: enabled). It is only used as a transport, and does not need to be assigned an IP address. This can be done automatically at boot time by updating the /etc/rc.conf file. The format of the statement to add is ifconfig_xxxx=up where xxxx is the NIC's FBSD interface name used by PPPoE that you specified in the /etc/ppp/ppp.conf file.
ee /etc/rc.conf # add following statements
ifconfig_xxxx=up
ifconfig_tun0="DHCP" # get your ISP assigned IP address
To setup user ppp to dial your ISP automatically at FBSD boot time, you have to add the following statements to the rc.conf file. The ddial option means to redial every time the connection to the ISP gets dropped.
ee /etc/rc.conf
# Activate user ppp auto start at boot time
ppp_enable="YES"
# Start User PPP task
ppp_mode="ddial"
# ddial, auto, background
ppp_profile="dialisp" # section in
ppp.conf to exec
#ppp_nat="YES"
# only if you have LAN behind this PC.
All of User PPP messages go to /var/log/ppp.log. This is specified in /etc/syslog.conf. Newsyslog.conf controls the frequency of rolling the log file off to the archive, as well as how many archive files to maintain. It's already configured for you.
The FBSD 5.22 FAQ entry says
5.24. What does ``stray IRQ'' mean?
Stray IRQs are indications of hardware IRQ glitches, mostly from hardware that removes its interrupt request in the middle of the interrupt request acknowledge cycle.
One has three options for dealing with this:
1. Live with the warnings. All except the first 5 per IRQ are suppressed anyway.
2. Break the warnings by changing 5 to 0 in isa_strayintr() so that all the warnings are suppressed.
3. Break the warnings by installing parallel port hardware that uses IRQ 7 and the PPP driver for it (this happens on most systems), and install an IDE drive or other hardware that uses IRQ 15 and a suitable driver for it.
********** End of FAQ # 5.22 *********************************
The number 3 item above is false, the ATA IDE standard is the primary IDE channel master and slave devices use IRQ 14 and the secondary IDE channel master and slave devices use IRQ 15. IRQ 15 is also used by many NIC cards. A printer attached to the parallel port uses IRQ 7, and the annoying bogus stray IRQ 7 messages still gets issued. So you are left with two options, learn to deal with it, or hack the code to make it go away.
To stop the annoying bogus stray IRQ 7 messages you can hack the source where these messages originate from and change the counter value 5 to 0 so the messages will no longer be issued.
isa_strayintr lives in /usr/src/sys/i386/isa/intr_machdep.c
cd /usr/src/sys/i386/i386/
cp intr_machdep.c intr_machdep.c.org # make backup of original
ee intr_machdep.c
Find isa_strayintr to locate the start of the stray IRQ 7 logic
change this
if (intrcnt[1 + intr] <= 5)
To this
if (intrcnt[1 + intr] <= 0)
Recompile your kernel source and those stray IRQ 7 messages are gone. Document this some place for yourself just in case you reinstall from CDROM. Remember that if you cvsup update your source to upgrade to next stable release, your 'stray IRQ 7 hack' will be stepped on and return back to the official FBSD version. You will have to reapply this hack.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/06.00_Network_Security.htm 000644 000000 000000 00000022106 10433404271 025024 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
If you are following the 'incremental install method' recommended in this Installers Guide, then by this point you have access to your ISP, and through them, access to the public Internet. Your FBSD system is now open to attack from the public Internet. If you have 24/7 always on access, you should turn off your FBSD system when not in use to limit the window of opportunity of being found and attacked, at least until you have time to enable and configure a firewall to protect your system. The following sections will explain in detail how you can protect your FBSD system using one of the three built in firewall software applications.
Note: This section has been donated to the FreeBSD project and has been incorperated into the offical handbook as Chapter 24 Firewalls. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html
All software firewall applications are based on monitoring network packet traffic flow to and from your system. The values of selected packet control fields can be interrogated by user written rules to allow or deny packet traffic based on your security needs.
Selection can be based on source and destination IP address, the source and destination port number, the type of protocol used (TCP, UDP, ICMP), or any combination. Firewall software applications provide a much, much finer level of control than that provided by a hardware router. They can be used to protect a single FBSD system or a complete internal network (LAN) by preventing public Internet traffic from making arbitrary connections to your internal network. They may also be used to prevent public Internet entities from spoofing internal IP addresses and to disable services you do not want accessed from the public Internet or by internal LAN users.
Finally, firewalls may be used to support NAT (network address translation), which allows an internal network using private IP addresses to share a single connection to the public Internet, or letting commercial users share a range of static public IP addresses automatically among the LAN users.
Constructing a software application firewall rule set may seem to be trivial, but most people get it wrong. The most common mistake is to create an exclusive firewall rather than an inclusive firewall.
An exclusive firewall allows all services through except for those matching a set of rules that block certain services.
An inclusive firewall does the reverse. It only allows services matching the rules through and blocks everything else. This way you can control what services can originate behind the firewall destined for the public Internet and also control which services originating from the public Internet may access your network. Inclusive firewalls are much, much safer than exclusive firewalls.
When you use your browser to access a web site there are many internal functions that happen before your screen fills with the data from the target web site. Your browser does not receive one large file containing all the data and display format instructions at one time. Each internal function accesses the public Internet in multiple send/receive cycles of packets of information. When all the packets containing the data finally arrive, the data contained in the packets is combined together to fill your screen. Each service has its own port number. The port number 80 is for web page services. So you can code your firewall to only allow web page session start requests originating from your LAN to pass through the firewall out to the public Internet.
Security can be tightened further by telling the firewall to monitor the send/receive cycles of all the packets making up that session until the session completes. These are called stateful capabilities and provide the maximum level of protection.
A firewall rule set that does not implement stateful capabilities on all the services being authorized is an insecure firewall that is still open to many of the most common methods of attack.
FBSD has three different firewall software products built into the base system. They are IPFILTER also known as IPF, IPFIREWALL also known as IPFW, and the OpenBSD Packet Filter known as PF. IPFW has the built in traffic shaper facilities for controlling bandwidth usage called dummynet. PF has it's built in traffic shaper facilities for controlling bandwidth usage called ALTQ. IPFILTER does not have a built in traffic shaper facility for controlling bandwidth usage, but the ALTQ port application can be used to accomplish the same function. The dummynet feature and ALTQ is generally useful only to large ISPs or commercial users. IPF, IPFW, and IP use rules to control the access of packets to and from your system, although they go about it different ways and have different rule syntaxes.
The IPFW /etc/rc.firewall sample rule set delivered in the basic install is outdated, complicated and does not use stateful rules on the interface facing the public Internet. It exclusively uses legacy stateless rules which only have the ability to open or close the service ports. The IPFW example stateful rule sets presented here supercedes the /etc/rc.firewall file distributed with the system.
Stateful rules have technically advanced interrogation abilities capable of defending against the flood of different attack methods currently employed by attackers.
Both of these firewall software solutions IPF and IPFW still maintain the legacy heritage of their original rule processing order and reliance on non-stateful rules. These outdated concepts are not covered here, only the new, modern stateful rule construct and rule processing order is presented.
You should read about all 3 firewalls, and them make your own decision on which one best fits your needs.
The author prefers IPFILTER because its stateful rules are much less complicated to use in a Nat environment, and it has a built in FTP proxy that simplifies the rules to allow secure outbound FTP usage. It is also more appropriate to the knowledge level of the inexperienced firewall user.
Since all firewalls are based on interrogating the values of selected packet control fields, the creator of the firewall rules must have an understanding of how TCP/IP works, what the different values in the packet control fields are and how these values are used in a normal session conversation. For a good explanation go to http://www.ipprimer.com/overview.cfm.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/06.04-IPMON_Command.htm 000644 000000 000000 00000030101 10433404271 023740 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
In order for ipmon to properly work, the kernel option IPFILTER_LOG must be turned on. This command has two different modes it can be used in. Native mode is the default mode when you type the command on the FBSD console command line without the D flag.
Daemon mode is for when you want to have a continuous system log file available so you can review logging of past events. This is how FBSD and IPFILTER are configured to work together. FBSD has a built in facility to automatically rotate syslogs. That is why outputting the log information to syslogd is better than the default of a regular file. In the rc.conf file you see the ipmon_flags statement uses the "-Ds" flags:
ipmon_flags="-Ds" # D = start as daemon
# s = log to syslog
# v = log tcp window, ack, seq
# n = map IP & port to names
The benefits of logging are obvious. Logging provides the ability to review after the fact information like what packets have been dropped, what addresses they came from, and where they were going, giving you a significant edge in tracking down attackers.
Even with the logging facility enabled, IPF will not generate any rule logging on its own. The firewall administrator decides what rules in the rule set he wants to log and adds the log keyword to those rules. Normally only deny rules are logged.
Its very customary to include a default deny everything rule with the log keyword included as your last rule in the rule set. This way you get to see all the packets that did not match any of the rules in the rule set.
Syslogd uses its own special method for segregation of log data. It uses special groupings called facility and level. IPMON in Ds mode uses security as the facility name. All IPMON logged data goes to security. By default IPFILTER will log to and automatically rotate the /var/log/security file. The following levels can be used to further segregate the logged data if desired.
LOG_INFO - packets logged using the "log" keyword as the action rather than pass or block.
LOG_NOTICE - packets logged which are also passed
LOG_WARNING - packets logged which are also blocked
LOG_ERR - packets which have been logged and which can be considered short
FBSD keeps all of its syslog files in /var/log/
If you want to use a different file name to receive the IPFILTER logging, Then you will have to create a new named log file for the IPFILTER logged data.
touch /var/log/ipfilter.log # will allocate the file
The syslog function is controlled by definition statements in the /etc/syslog.conf file. The syslog.conf file offers considerable flexibility in how syslog will deal with system messages issued by software applications like IPF.
You will have to edit the /etc/syslog.conf file.
For release 6.0 add the following statement to syslog.conf:
local0.* /var/log/ipfilter.log
The local0.* means to write all the logged messages to the coded file location.
For release 5.4 add the following statement to syslog.conf:
security.* /var/log/ipfilter.log
and comment out the existing #security.* /var/log/security statment.
The security.* means to write all the logged messages to the coded file location.
To activate the changes to /etc/syslog.conf you can reboot or bump the syslog task into re-reading /etc/syslog.conf by kill HUP pid. You get the pid (IE: process number) by listing the tasks with the ps ax command. Find syslog in the display and the pid number is the number in the left column.
Dont forget to change /etc/newsyslog.conf to rotate the new named IPFILTER log you just created above.
Fields common to all messages are:
1. The date of packet receipt.
2. The time of packet receipt. This is in the form HH:MM:SS.F, for hours, minutes, seconds, and fractions of a second (which can be several digits long).
3. The name of the interface the packet was processed on, e.g., dc0.
4. The group and rule number of the rule, e.g., @0:17.
These can be viewed with ipfstat -in.
5. The action: p for passed, b for blocked, S for a short packet, n did not match any rules, L for a log rule. The order of precedence in showing flags is:
S, p, b, n, L. A capital P or B means that the packet has been logged due to a global logging setting, not a particular rule.
6. The addresses. This is actually three fields: the source address and port (separated by a comma), the -> symbol, and the destination address and port. 209.53.17.22,80 -> 198.73.220.17,1722.
7. PR followed by the protocol name or number, e.g., PR tcp.
8. len followed by the header length and total length of the packet,
e.g., len 20 40.
If the packet is a TCP packet, there will be an additional field starting with a hyphen followed by letters corresponding to any flags that were set. See the ipf.conf manual page for a list of letters and their flags.
If the packet is an ICMP packet, there will be two fields at the end, the first always being `ICMP' and the next being the ICMP message and sub-message type, separated by a slash, (e.g., ICMP 3/3 for a port unreachable message).
Some experienced IPF users create a file containing the rules and code them in a manner compatible with running them as a script with symbolic substitution. The major benefit of doing this is you only have to change the value associated with the symbolic name, and when the script is run all the rules containing the symbolic name will have the value substituted in the rules. Being a script, you can use symbolic substitution to code frequently used values and substitute them in multiple rules. You will see this in the following example.
The script syntax used here is compatible with the sh, csh, and tcsh shells.
Symbolic substitution fields are prefixed with a dollar sign $.
Symbolic fields do not have the $ prefix
The value to populate the Symbolic field must be enclosed with "double quotes".
Start your rules file with this.
############# Start of IPF rules script ########################
oif="dc0" # name of the outbound interface
odns="192.0.2.11" # ISP's dns server IP address Symbolic>
myip="192.0.2.7" # My Static IP address from ISP
ks="keep state"
fks="flags S keep state"
# You can use this same to build the /etc/ipf.rules file
#cat >> /etc/ipf.rules << EOF
# exec ipf command and read inline data, stop reading
# when word EOF is found. There has to be one line
# after the EOF line to work correctly.
/sbin/ipf -Fa -f - << EOF
# Allow out access to my ISP's Domain name server.
pass out quick on $oif proto tcp from any to $odns port = 53 $fks
pass out quick on $oif proto udp from any to $odns port = 53 $ks
# Allow out non-secure standard www function
pass out quick on $oif proto tcp from $myip to any port = 80 $fks
# Allow out secure www function https over TLS SSL
pass out quick on $oif proto tcp from $myip to any port = 443 $fks
EOF
################## End of IPF rules script ########################
Thats all there is to it. The rules are not important in this example; how the Symbolic substitution field are populated and used are. If the above example was in the /etc/ipf.rules.script file, I could reload these rules by entering on the FBSD command line:
sh /etc/ipf.rules.script
There is one problem with using a rules file with embedded symbolics. IPF has no problem with it, but the rc.conf
ipfilter_rules="/etc/ipf.rules"
statement will not load the rules if the file this statement is pointing at contains symbolics. This is a FBSD rc.conf launch problem.
The solution is to delete the following statement in the rc.conf
ipfilter_rules=
and put the following script in this directory:
/usr/local/etc/rc.d/
FBSD looks in this directory for scripts that have names ending in .sh to automatically launch during the boot process. Apache and DHCP place their launch scripts there.
Your launch script should look like this.
ee /usr/local/etc/rc.d/ipf.loadrules.sh
#!/bin/sh
sh /etc/ipf.rules.script
The permission on this script file must be read, write, exec for owner root.
chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh
Now when you system boots your IPF rules will be loaded using the script.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/06.01-IPFILTER_IPF_Firewall.htm 000644 000000 000000 00000033611 10433404271 025167 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
The author of IPFILTER is Darren Reed. IPFILTER is not FBSD operating system dependant. IPFILTER is an open source application and has been ported to FreeBSD, NetBSD, OpenBSD, Sun, HP, and Solaris operating systems. IPFILTER is actively being supported and maintained, with updated versions being released regularly.
The IPFILTER program runs in the kernel and consists of the firewall and separate NAT facilities. IPFILTER also has user-land front-end interactive interfaces for controlling the firewall rules, NAT, packet accounting, and the logging facility. Program IPF is used to load the firewall rules. Program IPNAT is used to load the firewall NAT rules. Program IPFSTAT reports on packet filter statistics and lists active rules sets. Program IPMON monitors IPFILTER for logged packets.
From this point on IPFILTER will be written as IPF and is intended to mean the same thing as IPFILTER.
IPF was originally written using a rules processing logic of the last matching rule wins and used only stateless types of rules. Over time IPF has been enhanced to include a quick option and a stateful keep state option which drastically modernized the rules processing logic. IPFs official documentation covers the legacy rule coding parameters and the legacy rule file processing logic, the modernized functions are only included as additional options, completely understating their benefits in producing a far superior secure firewall.
The instructions contained in this guide are based on using rules that contain the quick' option and the stateful keep state option. This is the basic framework for coding an inclusive firewall rule set.
An inclusive firewall only allows services matching the rules through. This way you can control what services can originate behind the firewall destined for the public internet and also control the services which can originate from the public internet accessing your private network. Everything else is blocked and logged by default design. Inclusive firewall rule sets are much more secure than exclusive firewall rule sets and are the only rule set type covered herein.
For detailed explanation of the legacy rules processing method, see http://www.obfuscation.org/ipf/ipf-howto.html#TOC_1
http://coombs.anu.edu.au/~avalon/ip-filter.html
To see the FAQ: http://www.phildev.net/ipf/index.html
To search the open source IPFilter questions archives: http://marc.theaimsgroup.com/?l=ipfilter
Since all firewalls are based on interrogating the values of selected packet control fields, the creator of the firewall rules must have an understanding of how TCP/IP works, what the different values in the packet control fields are and how these values are used in a normal session conversation. For a good explanation go to http://www.ipprimer.com/overview.cfm
Installers Note:
If you are following the 'incremental install method' recommended in this Installers guide, them you only need to concern your self with the building of a rules file at this time. After you have the Lan hardware configured and tested then you need to return to this section to enable IPNAT and configure its rules file.
IPF is included in the basic FBSD install as a separate run time loadable module. IPF will dynamically load its kernel loadable module when the rc.conf statement ipfilter_enable="YES" is used. The loadable module was created with logging enabled and the default pass all options. You do not need to compile IPF into the FBSD kernel just to change the default to block all; you can do that by just coding a block all rule at the end of your rule set.
Using the IPF run time loadable module is recommended.
It is not a mandatory requirement that you enable IPF by compiling the following options into the FBSD kernel. Its only presented here as background information. Compiling IPF into the kernel causes the loadable module to never be used.
Sample kernel source IPF options statements are in the /usr/src/sys/i386/conf/LINT kernel source and are reproduced here.
options IPFILTER
options IPFILTER_LOG
options IPFILTER_DEFAULT_BLOCK
IPFILTER This tells the compile to include IPFILTER as part of its core kernel.
IPFILTER_LOG enables the option to have IPF log traffic by writing to the ipl packet logging pseudo-device for every rule that has the "log" keyword.
IPFILTER_DEFAULT_BLOCK This option changes the default behavior so any packet not matching a firewall pass rule gets blocked.
To build a custom kernel see the Kernel Customizing section.
You need the follow statements in /etc/rc.conf to activate IPF at boot time.
ipfilter_enable="YES"
# Start ipf firewall
ipfilter_rules="/etc/ipf.rules" # loads rules definition text file
# IE: not script file with rules in it
ipmon_enable="YES"
# Start IP monitor log
ipmon_flags="-Ds"
# D = start as daemon
# s = log to syslog
# v = log tcp window, ack, seq
# n = map IP & port to names
If you have a LAN behind this firewall that uses the reserved private IP address ranges, then you need to add the following to enable NAT functionality.
gateway_enable="YES"
# Enable as LAN gateway
ipnat_enable="YES"
# Start ipnat function
ipnat_rules="/etc/ipnat.rules" # rules definition file for
ipnat
The ipf command is used to load your rules file. Normally you create a file containing your custom rules and use this command to replace in mass the currently running firewall internal rules.
ipf Fa f /etc/ipf.rules
-Fa means flush all internal rules tables
-f means this is the file to read for the rules to load
This gives the user the ability to make changes to their custom rules file and run the above IPF command, thus updating the running firewall with a fresh copy of all the rules without having to reboot the system. This method is very convenient for testing new rules as the procedure can be executed as many times as needed.
See man IPF(8) for details on the other flag options available with this command.
The ipf command expects the rules file to be a standard text file. It will not accept a rules file written as a script with symbolic substitution.
There is a way to build IPF rules that utilities the power of script symbolic substitution. See the Building Rule Script section.
The default behavior of ipfstat is to retrieve and display the totals of the accumulated statistics gathered as a result of applying the user coded rules against packets going in and out of the firewall since it was last started or since the last time the accumulators were reset to zero by the ipf Z command.
See man ipfstat for details.
This is what the ipfstat command displays without any flags:
input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0
output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0
input packets logged: blocked 99286 passed 0
output packets logged: blocked 0 passed 0
packets logged: input 0 output 0
log failures: input 3898 output 0
fragment state(in): kept 0 lost 0
fragment state(out): kept 0 lost 0
packet state(in): kept 169364 lost 0
packet state(out): kept 431395 lost 0
ICMP replies: 0 TCP RSTs sent: 0
Result cache hits(in): 1215208 (out): 1098963
IN Pullups succeeded: 2 failed: 0
OUT Pullups succeeded: 0 failed: 0
Fastroute successes: 0 failures: 0
TCP cksum fails(in): 0 (out): 0
Packet log flags set: (0)
When supplied with either -i for inbound or o for outbound, it will retrieve and display the appropriate list of filter rules currently installed and in use by the kernel.
Ipfstat in displays the inbound internal rules table with rule numbers
Ipfstat on displays the outbound internal rules table with rule numbers
Rules will be displayed like this:
@1 pass out on xl0 from any to any
@2 block out on dc0 from any to any
@3 pass out quick on dc0 proto tcp/udp from any to any keep state
Ipfstat ih displays the inbound internal rules table, each rule prefixed with count of times the rule was matched
Ipfstat oh displays the outbound internal rules table, each rule prefixed with count of times the rule was matched
Rules will be displayed like this:
2451423 pass out on xl0 from any to any
354727 block out on dc0 from any to any
430918 pass out quick on dc0 proto tcp/udp from any to any keep state
Ipfstat t [ -C | -D | -P | -S | -T ]
The most important function of the ipfstat command is the t flag which activates the display state table in a way similar to the way the top command shows the FBSD running process table. When your firewall is under attack this function gives you the ability to identify, drill down to, and see the attacking packets. The optional sub-flags give the ability to select destination IP and port, or source IP and port, or protocol that you want to monitor in real time. See man ipfstat for details.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/06.06-IPF_Rule_Set.htm 000644 000000 000000 00000035113 10433404271 023652 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
A rule set is a group of IPF rules coded to pass or block packets based on the values contained in the packet. The bi-directional exchange of packets between hosts comprises a session conversation. The firewall rule set processes the packet two times, once on its arrival from the public Internet host and again as it leaves for its return trip back to the public Internet host. Each TCP/IP service (IE: telnet, www, mail, etc;) is predefined by its protocol, source and destination IP address, or the source and destination port number. This is the basic selection criteria used to create rules which will pass or block services.
IPF was originally written using a rules processing logic of the last matching rule wins and used only stateless types of rules. Over time IPF has been enhanced to include a quick option and a stateful keep state option which drastically modernized the rules processing logic.
The instructions contained in this section are based on using rules that contain the quick' option and the stateful keep state option. This is the basic framework for coding an inclusive firewall rule set.
An inclusive firewall only allows services matching the rules through. This way you can control what services can originate behind the firewall destined for the public Internet and also control the services which can originate from the public Internet accessing your private network. Everything else is blocked and logged by default design. Inclusive firewall rule sets are much more secure than exclusive firewall rule sets and are the only rule set type covered herein.
Installers Note:
Warning, when working with the firewall rules, always, always do it from the root console of the system running the firewall or you can end up locking yourself out.The rule syntax presented here has been simplified to only address the modern stateful rule context and first matching rule wins logic. For the complete legacy rule syntax description see the online man ipf page at http://www.freebsd.org/cgi/man.cgi?query=ipf&apropos=0&sektion=0&manpath=FreeBSD+6.0-RELEASE+and+Ports&format=html
# is used to mark the start of a comment and may appear at the end of a rule line or on its own line. Blank lines are ignored.
Rules contain keywords. These keywords have to be coded in a specific order from left to right on the line. Keywords are identified in bold type. Some keywords have sub-options which may be keywords themselves and also include more sub-options. Each of the headings in the below syntax has a bold section header which expands on the content.
Syntax = ACTION IN-OUT OPTIONS SELECTION STATEFUL
ACTION = block | pass
IN-OUT = in | out
OPTIONS = log | quick | on interface-name
SELECTION = proto value | source/destination IP | port = number | flags flag-value
Where value = tcp/udp | udp | tcp | icmp
Where source/destination IP = all | from object to object
Where object = IP address | any
Where number = port number
Where flag-value = S
STATEFUL = keep state
The | symbol used in the above syntax means or.
ACTION
The action indicates what to do with the packet if it matches the rest of the filter rule. Each rule MUST have an action. The following actions are recognized:
block indicates that the packet should be dropped if the selection parameters match the packet.
pass indicates that the packet should exit the firewall if the selection parameters match the packet.
IN-OUT It is a mandatory requirement that each filter rule explicitly states which side of the I/O it is to be used on. The next keyword must be either in or out and one or the other has to be coded or the rule will not pass syntax check.
in means this rule is being applied against an inbound packet which has just been received on the interface facing the public Internet.
out means this rule is being applied against an outbound packet destined for the interface facing the public Internet.
OPTIONS Must be used in the order shown here.
log indicates that the packet header will be written to the ipl log (as described in the LOGGING section below) if the selection parameters match the packet.
quick indicates that if the selection parameters match the packet, this rule will be the last rule checked, allowing a "short-circuit" path to avoid processing any following rules for this packet. This option is a mandatory requirement for the modernized rules processing logic.
on indicates the interface name to be incorporated into the selection parameters. Interface names are as displayed by ifconfig. Using this option, the rule will only match if the packet is going through that interface in the specified direction (in/out). This option is a mandatory requirement for the modernized rules processing logic.
When a packet is logged, the headers of the packet are written to the IPL packet logging pseudo-device. Immediately following the log keyword, the following qualifiers may be used (in this order):
body indicates that the first 128 bytes of the packet contents will be logged after the headers.
first If the log keyword is being used in conjunction with a "keep state" option, it is recommended that this option is also applied so that only the triggering packet is logged and not every packet thereafter which matches the keep state information.
SELECTION
The keywords described in this section are used to describe attributes of the packet to be interrogated when determining whether rules match or don't match. There is a keyword subject, and it has sub-option keywords, one of which has to be selected. The following general-purpose attributes are provided for matching and must be used in this order:
proto value Proto is the subject keyword; it must be coded along with one of its corresponding keyword sub-option values. The value allows a specific protocol to be matched against it. This option is a mandatory requirement for the modernized rules processing logic.
Valid sub-option value keywords are:
tcp/udp | udp | tcp | icmp or any protocol names found in /etc/protocols are recognized and may be used. The special protocol keyword tcp/udp may be used to match either a TCP or a UDP packet, and has been added as a convenience to save duplication of otherwise identical rules.
source/destination IP =
all keyword is essentially a synonym for "from any to any" with no other match parameters.
from src to dst The from and to keywords are used to match against IP addresses. Rules must specify BOTH source and destination parameters. any is a special keyword that matches any IP address. As in "from any to any" or
"from 0.0.0.0/0 to any" or "from any to 0.0.0.0/0 " or
"from 0.0.0.0 to any" or "from any to 0.0.0.0 "
IP addresses may be specified as a dotted IP address numeric form/mask-length, or as a single dotted IP address numeric form.
There isn't a way to match ranges of IP addresses which do not express themselves easily as mask-length. See this link for help on writing mask-length.
http://jodies.de/ipcalcport If a port match is included, for either or both of the source and destination, then it is only applied to TCP and UDP packets. When composing port comparisons, either the service name from /etc/services or an integer port number may be used. When the port appears as part of the from object, it matches the source port number; when it appears as part of the to object, it matches the destination port number. The use of the port option with the to object is a mandatory requirement for the modernized rules processing logic.
As in from any to any port = 80
Port comparisons may be done in a number of forms, with a number of comparison operators, or port ranges may be specified.
port "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne" | "lt" | "gt" | "le" | "ge".
To specify port ranges, port "<>" | "><" .
Following the source and destination matching parameters, the following two parameters are mandatory requirements for the modernized rules processing logic.
flags is only effective for TCP filtering. The letters represents one of the possible flags that can be interrogated in the TCP packet header.
The modernized rules processing logic uses the flags S parameter to identify the tcp session start request.
STATEFUL
keep state indicates that on a pass rule, any packets that match the rules selection parameters are to activate the stateful filtering facility.
This option is a mandatory requirement for the modernized rules processing logic.
Stateful filtering treats traffic as a bi-directional exchange of packets comprising a session conversation. When activated keep-state dynamically generates internal rules for each anticipated packet being exchanged during the bi-directional session conversation. It has the interrogation abilities to determine if the session conversation between the originating sender and the destination are following the valid procedure of bi-directional packet exchange. Any packets that do not properly fit the session conversation template are automatically rejected as impostors.
Keep state will also allow ICMP packets related to a TCP or UDP session through. So if you get ICMP type 3 code 4 in response to some web surfing allowed out by a keep state rule, they will be automatically allowed in. Any packet that IPF can be certain is part of an active session, even if it's a different protocol, will be let in.
What happens is:
Packets destined to go out through the NIC connected to the public Internet are first checked against the dynamic state table. If the packet matches the next expected packet of that active session conversation, then it exits the firewall and the state of the session conversation flow is updated in the dynamic state table. The remaining packets get checked against the outbound rule set.
Packets coming in through the NIC connected to the public Internet are first checked against the dynamic state table. If the packet matches the next expected packet of that active session conversation, then it exits the firewall and the state of the session conversation flow is updated in the dynamic state table. The remaining packets get checked against the inbound rule set.
When the conversation completes, it's removed from the dynamic state table.
Stateful filtering allows you to focus on blocking/passing new sessions. If the new session is passed, all its subsequent packets will be allowed through automatically and any impostors automatically rejected. If a new session is blocked, none of its subsequent packets will be allowed through. Stateful filtering has technically advanced interrogation abilities capable of defending against the flood of different attack methods currently employed by attackers.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/06.07-Inclusive_Rule_set.htm 000644 000000 000000 00000035116 10433404271 025241 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
The following rule set is an example of how to code a very secure inclusive type of firewall. An inclusive firewall only allows services matching pass rules through and blocks all others by default. All firewalls have at the minimum two interfaces which have to have rules to allow the firewall to function.
All Unix flavored systems including FBSD are designed to use interface lo0 and IP address 127.0.0.1 for internal communication within the FBSD operating system. The firewall rules must contain rules to allow free, unmolested movement of these special internally used packets.
The interface which faces the public Internet is the one which you code your rules to authorize and control access out to the public Internet and access requests arriving from the public Internet. This can be your user ppp tun0 interface or your NIC that is cabled to your DSL or cable modem.
In cases where one or more NIC's are cabled to private LANs (local area networks) behind the firewall, those interfaces must have a rule coded to allow free, unmolested movement of packets originating from those LAN interfaces.
The rules should be first organized into three major sections; all the free and unmolested interfaces, public interface outbound, and the public interface inbound.
The order of the rules in each of the public interface sections should be in order of the most used rules being placed before less often used rules with the last rule in the section being a block log all packets on that interface and direction.
The outbound section in the following rule set only contains pass rules which contain selection values that uniquely identify the service that is authorized for public Internet access. All the rules have the quick, on, proto, port, and keep state option coded. The proto tcp rules have the flag option included to identify the session start request as the triggering packet to activate the stateful facility.
The inbound section has all the blocking of undesirable packets first for two different reasons. First, these things being blocked may be part of an otherwise valid packet which may be allowed in by the later authorized service rules. Second, by having a rule that explicitly blocks selected packets that I receive on an infrequent bases and dont want to see in the log, this keeps them from being caught by the last rule in the section which blocks and logs all packets which have fallen through the rules. The last rule in the section which blocks and logs all packets is how you create the legal evidence needed to prosecute the people who are attacking your system.
Another thing you should take note of is there is no response returned for any of the undesirable stuff; their packets just get dropped and vanish. This way the attackers have no knowledge if their packets have reached your system. The less the attackers can learn about your system the more secure it is. For the inbound 'nmap OS fingerprint' attempts rule I log the first occurrence, because this is something an attacker would do.
Any time you see log messages on a rule with log first you should do an ipfstat h command to see the number of times the rule has been matched so you know if you are being flooded, (IE: under attack).
When you log packets with port numbers you do not recognize, go to http://www.securitystats.com/tools/portsearch.php and do a port number lookup to find what the purpose of that port number is.
Check out this link for port numbers used by Trojans http://www.simovits.com/trojans/trojans.html
The following rule set is a complete, very secure inclusive type of firewall rule set that I have used on my system. You cannot go wrong using this rule set for your own. Just comment out any pass rules for services to dont want to authorize.
If you see messages in your log that you want to stop seeing just add a block rule in the inbound section.
You have to change the dc0 interface name in every rule to the interface name of the NIC that connects your system to the public Internet. For user ppp it would be tun0.
Add the following statements to /etc/ipf.rules
#################################################################
# No restrictions on Inside LAN Interface for private network
# Not needed unless you have LAN
#################################################################
#pass out quick on xl0 all
#pass in quick on xl0 all
#################################################################
# No restrictions on Loopback Interface
#################################################################
pass in quick on lo0 all
pass out quick on lo0 all
#################################################################
# Interface facing Public Internet (Outbound Section)
# Interrogate session start requests originating from behind the
# firewall on the private network
# or from this gateway server destined for the public Internet.
#################################################################
# Allow out access to my ISP's Domain name server.
# xxx must be the IP address of your ISPs DNS.
# Dup these lines if your ISP has more than one DNS server
# Get the IP addresses from /etc/resolv.conf file
pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state
pass out quick on dc0 proto udp from any to xxx port = 53 keep state
# Allow out access to my ISP's DHCP server for cable or DSL networks.
# This rule is not needed for user ppp type connection to the
# public Internet, so you can delete this whole group.
# Use the following rule and check log for IP address.
# Then put IP address in commented out rule & delete first rule
pass out log quick on dc0 proto udp from any to any port = 67 keep state
#pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state
# Allow out non-secure standard www function
pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state
# Allow out secure www function https over TLS SSL
pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state
# Allow out send & get email function
pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state
pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state
# Allow out Time
pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state
# Allow out nntp news
pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state
# Allow out gateway & LAN users non-secure FTP ( both passive & active modes)
# This function uses the IPNAT built in FTP proxy function coded in
# the NAT rules file to make this single rule function correctly.
# If you want to use the pkg_add command to install application packages
# on your gateway system you need this rule.
pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state
# Allow out secure FTP, Telnet, and SCP
# This function is using SSH (secure shell)
pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state
# Allow out non-secure Telnet
pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state
# Allow out FBSD CVSUP function
pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state
# Allow out ping to public Internet
pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state
# Allow out whois for LAN PC to public Internet
pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state
# Block and log only the first occurrence of everything
# else thats trying to get out.
# This rule enforces the block all by default logic.
block out log first quick on dc0 all
#################################################################
# Interface facing Public Internet (Inbound Section)
# Interrogate packets originating from the public Internet
# destined for this gateway server or the private network.
#################################################################
# Block all inbound traffic from non-routable or reserved address spaces
block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918
private IP
block in quick on dc0 from 172.16.0.0/12 to any #RFC
1918 private IP
block in quick on dc0 from 10.0.0.0/8 to any
#RFC 1918 private IP
block in quick on dc0 from 127.0.0.0/8 to any
#loopback
block in quick on dc0 from 0.0.0.0/8 to any
#loopback
block in quick on dc0 from 169.254.0.0/16 to any #DHCP
auto-config
block in quick on dc0 from 192.0.2.0/24 to any
#reserved for doc's
block in quick on dc0 from 204.152.64.0/23 to any #Sun cluster
interconnect
block in quick on dc0 from 224.0.0.0/3 to any
#Class D & E multicast
##### Block a bunch of different nasty things. ############
# That I dont want to see in the log
# Block frags
block in quick on dc0 all with frags
# Block short tcp packets
block in quick on dc0 proto tcp all with short
# block source routed packets
block in quick on dc0 all with opt lsrr
block in quick on dc0 all with opt ssrr
# Block nmap OS fingerprint attempts
# Log first occurrence of these so I can get their IP address
block in log first quick on dc0 proto tcp from any to any flags FUP
# Block anything with special options
block in quick on dc0 all with ipopts
# Block public pings
block in quick on dc0 proto icmp all icmp-type 8
# Block ident
block in quick on dc0 proto tcp from any to any port = 113
# Block all Netbios service. 137=name, 138=datagram, 139=session
# Netbios is MS/Windows sharing services.
# Block MS/Windows hosts2 name server requests 81
block in log first quick on dc0 proto tcp/udp from any to any port = 137
block in log first quick on dc0 proto tcp/udp from any to any port = 138
block in log first quick on dc0 proto tcp/udp from any to any port = 139
block in log first quick on dc0 proto tcp/udp from any to any port = 81
# Allow traffic in from ISP's DHCP server. This rule must contain
# the IP address of your ISPs DHCP server as its the only
# authorized source to send this packet type. Only necessary for
# cable or DSL configurations. This rule is not needed for
# user ppp type connection to the public Internet.
# This is the same IP address you captured and
# used in the outbound section.
pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state
# Allow in standard www function because I have apache server
pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state
# Allow in non-secure Telnet session from public Internet
# labeled non-secure because ID/PW passed over public Internet as clear text.
# Delete this sample group if you do not have telnet server enabled.
#pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state
# Allow in secure FTP, Telnet, and SCP from public Internet
# This function is using SSH (secure shell)
pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state
# Block and log only first occurrence of all remaining traffic
# coming into the firewall. The logging of only the first
# occurrence stops a denial of service attack targeted
# at filling up your log file space.
# This rule enforces the block all by default logic.
block in log first quick on dc0 all
################### End of rules file #####################################
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/06.08-NAT_Explanation.htm 000644 000000 000000 00000046633 10433404271 024431 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
NAT stands for Network Address Translation. To those familiar with Linux, this concept is called IP Masquerading; NAT and IP Masquerading are the same thing. One of the many things the IPF NAT function enables is the ability to have a private local area network (LAN) behind the firewall sharing a single ISP assigned IP address to the public Internet.
You ask why would someone want to do this. ISPs normally assign a dynamic IP address to their non-commercial users. Dynamic means the IP address can be different each time you dial in and logon to your ISP, or for cable and DSL modem users when you power off and then power on your modems you can get assigned a different IP address. This IP address is how you are known to the public Internet.
Now lets say you have 5 PCs at home and each one needs Internet access. You would have to pay your ISP for an individual Internet account for each PC and have 5 phone lines.
With NAT you only need a single account with your ISP, then cable your other 4 PCs to a switch and the switch to the NIC in your FBSD system which is going to service your LAN as a gateway. NAT will automatically translate the private LAN IP address for each separate PC on the LAN to the single public IP address as it exits the firewall bound for the public Internet. It also does the reverse translation for returning packets.
NAT is most often accomplished without the approval, or knowledge, of your ISP, and in most cases is grounds for your ISP terminating your account if found out. Commercial users pay a lot more for their Internet connection and usually get assigned a block of static IP addresses which never change. The ISP also expects and consents to their commercial customers using NAT for their internal private LANs.
There is a special range of IP addresses reserved for NATed private LAN IP addresses.
According to RFC 1918, you can use the following IP ranges for private nets which will never be routed directly to the public Internet.
Start IP 10.0.0.0 - Ending IP 10.255.255.255
Start IP 172.16.0.0 - Ending IP 172.31.255.255
Start IP 192.168.0.0 - Ending IP 192.168.255.255
NAT rules are loaded by using the ipnat command. Typically the NAT rules are stored in /etc/ipnat.rules. See man ipnat(1) for details.
When changing the NAT rules after NAT has been started, make your changes to the file containing the NAT rules, then run the ipnat command with the CF flags to delete the internal in use NAT rules and flush the contents of the translation table of all active entries.
ipnat CF f /etc/ipnat.rules # reload the NAT rules
ipnat -s # Retrieve and display NAT statistics
ipnat -l # List the internal NAT table entry mappings.
ipnat -v # Turn verbose mode on to display information relating to rule processing and active rules/table entries.
NAT rules are very flexible and can accomplish many different things to fit the needs of non-commercial users with a single dynamic IP address or commercial users who have blocks of static IP address ranges assigned to them.
The rule syntax presented here has been simplified to what is most commonly used in a non-commercial environment. For a complete rule syntax description see the man ipnat page at ipnat(5) or ipnat(8).
# is used to mark the start of a comment and may appear at the end of a rule line or on its own line. Blank lines are ignored.
Rules contain keywords. These keywords have to be coded in a specific order from left to right on the line.
These special aliases |0.32|, |0/0| and |0/32|, only work in IPNAT's
map and bimap rules. They do NOT work in IPF rules, or in IPNAT rdr
rules. Beware how and where you use these special aliases as incorrect usage
generates no errors.
For standard NAT functionality, you only need a single NAT rule.
Create a file called /etc/ipnat.rules with the following line:
A packet leaves a LAN PC for the public internet carring it's private LAN source IP address and public destination IP address. It passes through the outbound firewall rules and NAT gets it's turn at the packet and applies its rules top down; the first matching rule wins. NAT tests each of its rules against the packet's interface name and source IP address. When a packet's interface name matches a NAT rule then the source IP address (IE: private LAN IP address) of the packet is checked to see if it falls within the IP address range specified to the left of the arrow symbol on the NAT rule. On a match the packet has its source IP address rewritten with the public IP address obtained by the 0.32 keyword. NAT posts an entry in its internal NAT table so when the packet returns from the public Internet it can be mapped back to its original private IP address and then passed to the filter rules for processing.
The main thing to remember is the firewall rules only sees the non-public routable private LAN IP address. The NAT function happens after the outbound packet has been processed by the firewall and before the inbound packet gets to the firewall.
To enable the IPNAT function add these statements to /etc/rc.conf
gateway_enable="YES" # Enable as LAN gateway
ipnat_enable="YES" # Start ipnat function
ipnat_rules="/etc/ipnat.rules" # ipnat rules definition file
For networks that have large numbers of PC's on the LAN or networks with more that a single LAN, the process of funneling all those private IP addresses into a single public IP address becomes a resource problem that may cause problems with same port numbers being used many times across many NATd LAN PC's causing collisions. There are 2 ways to relieve this resource problem.
1. Mapping many LAN addresses into a single public address.
map dc0 10.0.10.1/29 -> 0.32
In the above rule the packet's source port is unchanged from the original source port. IPNAT has the special keyword "portmap" that changes the above rule into
map dc0 10.0.10.1/29 -> 0.32 portmap tcp/udp 20000:6000
This rule now shoehorns all the translated connections (which can be
tcp, udp, or tcp/udp) into the port range of 20000 to 60000.
Additionally, we can make things even easier by using the "auto"
keyword to tell ipnat to determine for itself which ports are available for use
and allocate a proportional amount of them per address in your pool versus
addresses being NATed:
map dc0 10.0.10.1/29 -> 0.32 portmap tcp/udp auto
2. Mapping many LAN addresses into a pool of static public addresses.
In large LANs there comes a point where there are just too many LAN addresses to fit into a single public IP address. Change the map rule to specify a range of public IP addresses as follows:
map dc0 10.0.10.1/29 -> 20.20.20.0/24 portmap tcp/udp 20000:60000
map dc0 10.0.10.1/29 -> 20.20.20.0/24 portmap tcp/udp auto
Here 20.20.20.0/24 is the pool of static public IP addresses assigned to you by your ISP.
An very common practice is to have a web server, email server, database server or domain name server each segregated to a different PC on the LAN. Any traffic originating from those servers destine for the public internet would pass out the firewall on keep state rules automatically controlling the bidirectional exchange of packets for the duration of the session conversation. Due to the nature of these servers they also need to receive unsolicited inbound traffic from the public internet. The problem is how to direct this unsolicited inbound traffic to the correct target PC on the LAN?
For this purpose we use the NAT 'rdr' directive in the /etc/ipnat.rules file to instruct where to redirect (or route) a particular packet to on the NAT'ed LAN.
For example, lets say your web server resides on the LAN and you want it to
be accessible from the public internet. The NAT rules file would need a
additional rule added after the MAP rules to handle this. You would code the rule like this:
rdr xl0 0.0.0.0/0 port 80 -> 10.0.10.5
port 80
"rdr" = the command which
provides the selection information and target redirect information.
"xl0" = is the network interface
that is connected to the public internet.
"0.0.0.0/0" = is a special
aliases which means any source IP address contained in the inbound packet
traveling the interface is to be selected for testing. The other special aliases |0.32|, |0/0|
and |0/32|, only work in IPNAT's map and bimap rules. They do NOT work in
IPF rules, or in IPNAT rdr rules and 0.0.0.0/0 only works in rdr rules. Beware
how and where you use these special aliases as incorrect usage generates no
errors.
"port 80" = is the destination
port number that has to be matched in the inbound packet to select the candidate
packet to be redirected. The number
"80" don't have to be used. You can use "port www" to specify a redirection of
port 80. If you would like to use a name instead of a number, the service name
and corresponding port, must exist in the file /etc/services.
"->" = Mandatory arrow symbol used to distinguish between the rule selection information side and the redirect information side of the rule.
"10.0.10.5" = the IP address of
the LAN PC which the matched packets are to be targeted to. The netmask defaults
to "/32" and therefore should not be coded.
"port 80" - this is the port number value to substitute in the destination port number of the redirected packet. You could make it 8088 and tell the web server on 10.0.10.5 to listen on that port number. If omitted the destination port number goes unchanged.
The above IPNAT redirect rule says that any inbound packet that has not already had it's destination IP address translated by earlier MAP rules will then have it's destination port tested for match to the port number on the left of the mandatory arrow symbol, if matched, the packet's destination IP address and port number are over written with the values on the right of the mandatory arrow symbol and then released for processing against the firewall rules. NAT then posts an entry in its internal NAT table so when the packet returns after first being processed by the firewall rules on it's outbound journey it can have it's private LAN IP address mapped back to your gateway's public routable IP address. After reloading the NAT rules, the redirection will start immediately.
Depending on how tightly or loosely you control the services by firewall rules the redirected packet may require a firewall rule to let it pass.The main thing to remember is the firewall rules only sees the non-public
routable private LAN IP address. The NAT function happens after the outbound
packet has been processed by the firewall and before the inbound packet gets to
the firewall.
FTP is a dinosaur left over from the time before the Internet, when research universities were connected with leased lines and FTP was used to share files among research scientists. This was a time when data security was not even an idea yet. Over the years the FTP protocol became buried into the backbone of the emerging Internet and its login ID & PW being sent in clear text was never changed to address new security concerns. FTP has two flavors: it can run in active mode or passive mode. The difference is in how the data channel is acquired. Passive mode is more secure as the data channel is acquired be the ordinal FTP session requester. For a real good explanation of FTP and its different modes read http://www.slacksite.com/other/ftp.html
NAT has a special built in FTP proxy option which can be specified on the NAT map rule. It can monitor all outbound packet traffic for active or passive FTP start session requests and dynamically create temporary filter rules containing only the port number really in use for the data channel. This eliminates the security risk FTP normally exposes the firewall to from having large ranges of high order port numbers open. You specify the map rule like this:
map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp
map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp
map dc0 10.0.10.0/29 -> 0/32
The first rule handles all FTP traffic for the private LAN.
The second rule handles all FTP traffic from the gateway.
The third rule handles all non-FTP traffic for the private LAN.
All the non-FTP gateway traffic is using the public IP address by default so
there is no ipnat rule needed.
The FTP map rule goes before our regular map rule. All packets are tested against the first rule from the top. First, it matches on interface name, then private LAN source IP address, and then if it's an FTP packet. If all that matches then the special FTP proxy creates temporary filter rules to let the FTP session packets pass in and out in addition to also NATing the FTP packets. ALL LAN packets that are not FTP do not match the first rule and fall through to the third rule and are tested, matching on interface and source IP, then get NATed.
Only one filter rule is needed for FTP if NAT FTP proxy is used
# Allow out LAN PC client FTP to public Internet
# Active and passive modes.
pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state
Three Filter rules are needed for FTP if no NAT FTP proxy is used
# Allow out LAN PC client FTP to public Internet
# Active and passive modes.
pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state
# Allow out passive mode data channel high order port numbers
pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep state
# Active mode let data channel in from FTP server
pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/06.09.0-IPFIREWALL_IPFW_Firewall.htm 000644 000000 000000 00000025503 10433404272 025706 0 ustar 00root wheel 000000 000000Home______________________________________________________________________
The IPFIREWALL (IPFW) is a FBSD sponsored firewall software application authored and maintained by FBSD volunteer staff members. It uses the legacy stateless rules and a legacy rule coding technique to achieve what is referred to as simple stateful logic.
The IPFW stateless rule syntax is empowered with technically sophisticated selection capabilities which far surpasses the knowledge level of the customary firewall installer. IPFW is targeted at the professional user or the advanced technical computer hobbyist who has advanced packet selection requirements. A high degree of detailed knowledge into how different protocols use and create their unique packet header information is necessary before the power of the IPFW rules can be unleashed. Providing that level of explanation is out of the scope of this section of the handbook.
IPFW is composed of seven components; the kernel firewall filter rule processor and its integrated packet accounting facility (the primary component), the logging facility, the divert rule which triggers the NAT facility, and the advanced special purpose facilities (the dummynet traffic shaper facilities the fwd rule forward facility, the bridge facility, and the ipstealth facility).
See the FBSD man pages, 'man ipfw' or 'man ipfirewall' or 'man dummynet' for details.
From this point on I will use IPFW to mean IPFIREWALL.
IPFW is included in the basic FBSD install as a separate run time loadable module. IPFW will dynamically load its kernel loadable module when the rc.conf statement firewall_enable="YES" is used. You do not need to compile IPFW into the FBSD kernel.
Using the IPFW run time loadable module is recommended.
After rebooting your system with firewall_enable="YES" in rc.conf the following white highlighted message is displayed on the screen as part of the boot process.
IP packet filtering initialized, divert disabled, rule-based forwarding
enabled, default to deny, logging disabled
You can disregard this message as its outdated and no longer is the true status of the IPFW loadable module. The loadable module really does have logging ability.
To set the verbose limit, there is a knob you can set in sysctl.conf by adding this statement to the file:
ee /etc/sysctl.conf
net.inet.ip.fw.verbose_limit=5
It is not a mandatory requirement that you enable IPFW by compiling the following options into the FBSD kernel. Its only presented here as a background information option. Compiling IPFW into the kernel causes the loadable module to never be used.
Sample kernel source IPFW options statements are in the /usr/src/sys/i386/conf/LINT kernel source and are reproduced here.
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=5
option IPDIVERT # needed to use divert/natd rule
IPFIREWALL This tells the compile to include IPFW as part of the kernel.
IPFIREWALL_VERBOSE enables the option to have IPFW log traffic by printing packet activity to syslogd for every rule that has the "log" keyword.
IPFIREWALL_VERBOSE_LIMIT=5 specifies the default number of packets from a particular rule is to be logged. Without this option each repeated occurrences of the same packet will be logged and eventually consume all the free disk space, resulting in services being denied due to lack of resources. The 5 is the number of consecutive times to log evidence of this unique occurrence.
IPDIVERT adds the userland natd function which is utilized by the divert natd IPFW rule statement.
A complete list of the IPFW options statements are in /usr/src/sys/i386/conf/LINT
If you do not know how to build a custom kernel go to the Kernel Customizing section.
Installer note:
After compiling IPFW into your kernel you lose the ability to access all private LAN and public Internet networks, until you enable IPFW in rc.conf and reboot.
Besides compiling IPFW into your kernel, you also have to tell FBSD to active it at boot time. You do that by adding the following statements to /etc/rc.conf:
firewall_enable="YES" # Start IPFW daemon
firewall_script="/etc/ipfw.rules" # Use my custom rules.
filewall_logging="YES" # Enable packet logging
For a completely open firewall, you have to create the /etc/ipfw.rules file with the following rules
ipfw f flush
ipfw add allow all from any to any
The ipfw command is the normal vehicle for making manual single rule additions or deletions to the firewall active internal rules while it's running. The problem with using this method is once your system is shutdown or halted, all the rules you added or changed or deleted are lost. Writing all your rules in a file and using that file to load the rules at boot time or to replace in mass the currently running firewall rules with changes you made to the files content is the recommended method used here.
See Building Rule Script for details.
The ipfw command is still a very useful for displaying the running firewall rules to the console screen. The IPFW accounting facility dynamically creates a counter for each rule that counts each packet that matches the rule. During the process of testing a rule, listing the rule with its counter is the only way of determining if the rule is functioning.
You would enter on the FBSD command line one of the following forms of the list command.
ipfw list List all rules in rule number sequence.
ipfw -t list List rules in rule # sequence with timestamp
of last time that rule was matched.
ipfw -a list List the accounting information, packet count for
matched rules along with the rules themselves.
The first column is the rule number, followed
by the number of outgoing matched packets,
followed by the number of incoming matched packets,
and finally followed by the rule itself.
ipfw -d list List dynamic rules in addition to static ones.
ipfw -d -e list Also show expired dynamic rules.
ipfw zero Clear all the accounting counters.
ipfw zero # Clear accounting counter just for this rule number.
ipfw show | more
If you have a big rule set with dynamic rules it will scroll off the screen. Suffix the command with | more which will only display the first screen full, and then you have to use the arrow keys or enter key to scroll down through the info.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/06.09.4-IPFW_Rule_Sets.htm 000644 000000 000000 00000047066 10433404272 024344 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
A rule set is a group of ipfw rules coded to allow or deny packets based on the values contained in the packet. The bi-directional exchange of packets between hosts comprises a session conversation. The firewall rule set processes the packet two times, once on its arrival from the public Internet host and again as it leaves for its return trip back to the public Internet host. Each TCP/IP service (IE: telnet, www, mail, etc.) is predefined by its protocol and port number. This is the basic selection criteria used to create rules which will allow or deny services.
When a packet enters the firewall it is compared against the first rule in the rule set and progresses one rule at a time, moving from top to bottom of the set in ascending rule number sequence order. When the packet matches a rule selection parameter, the rule's action field value is executed and the search of the rule set terminates for that packet. This is referred to as the 'first match wins' search method. If the packet does not match any of the rules, it gets caught by the mandatory ipfw default rule, number 65535 which denies all packets and discards them without any reply back to the originating destination.
The instructions contained in this section of the Installers Guide is based on using rules that contain the stateful keep state and limit options. This is the basic framework for coding an inclusive type firewall rule set.
An inclusive firewall only allows services matching the rules through. This way you can control what services can originate behind the firewall destine for the public Internet and also control the services which can originate from the public Internet accessing your private network. Everything else is denied by default design. Inclusive firewalls are much more secure than exclusive firewall rule sets and are the only rule set type covered here in.
Installers Note:
Warning, when working with the firewall rules, always, always do it from the root console of the system running the firewall or you can end up locking yourself out.
The rule syntax presented here has been simplified to what is necessary to create a standard inclusive type firewall rule set. For a complete rule syntax description see the online man ipfw page at
Rules contain keywords. These keywords have to be coded in a specific order from left to right on the line. Keywords are identified in bold type. Some keywords have sub-options which may be keywords themselves and also include more sub-options.
# is used to mark the start of a comment and may appear at the end of a rule line or on its own line. Blank lines are ignored.
Syntax = CMD RULE# ACTION LOGGING SELECTION STATEFUL
CMD Each rule has to be prefixed with the following to add the rule to the internal table,
ipfw add
RULE# Coding rule numbers is not a mandatory requirement. Rule numbers will automatically be assigned when the rules are loaded into the internal IPFW tables. Coding your own rule numbers means the numbers will not change during loading and gives you a fixed rule number which is listed in the log along with other information about the packet being logged. The rule number is how you relate the logged packet back to the rule that caused the packet to be logged. If a rule is entered without a number, ipfw will assign one.
ACTIONS
A rule can be associated with one of the following actions which will be
executed when the packet matches the selection criterion of the rule.
allow | accept | pass | permit
These all mean the same thing which is to allow
packets that match the rule to exit the firewall
rule processing. The search terminates.
check-state
Checks the packet against the dynamic rules table.
If a match is found, execute the action associated with
the rule which generated this dynamic rule, otherwise move
to the next rule. The check-state rule does not have
selection criteria. If no check-state rule is present in
the rule set, the dynamic rules table is checked at the
first keep-state or limit rule.
deny | drop
Both words mean the same thing which is to discard packets
that match this rule. The search terminates.
LOGGING
log or logamount number
When a packet matches a rule with the log keyword, a message will be
logged to syslogd with a facility name of SECURITY. The logging only occurs
if the number of packets logged so far for that particular
rule does not exceed the logamount parameter. If no logamount is
specified, the limit is taken from the sysctl variable
net.inet.ip.fw.verbose_limit. In both cases, a value of zero removes
the logging limit. Once the limit is reached, logging can be
re-enabled by clearing the logging counter or the packet counter for
that rule. See the ipfw reset log command.
Note: logging is done after all other packet matching conditions have
been successfully verified and before performing the final action
(accept, deny) on the packet. Its up to you to decide which rules
you want to enable logging on.
SELECTION
The keywords described in this section are used to describe attributes of the packet to be interrogated when determining whether rules match or don't match the packet. The following general-purpose attributes are provided for matching and must be used in this order:
udp | tcp | icmp
or any protocol names found in /etc/protocols are recognized
and may be used. The value specified is
the protocol to be matched
against. This is a mandatory requirement.
from src to dst
The from and to keywords are used to match against IP addresses.
Rules must specify BOTH source and destination parameters.
any is a special keyword that matches any IP address.
me is a special keyword that matches any IP address configured
on an interface in your FBSD system to represent the PC
the firewall is running on. (IE: this box)
As in from me to any or from any to me or from 0.0.0.0/0 to any
or from any to 0.0.0.0/0 or from 0.0.0.0 to any or
from any to 0.0.0.0 or from me to 0.0.0.0 IP addresses are
specified as a dotted IP address numeric form/mask-length or
as single dotted IP address numeric form.
This is a mandatory requirement. See this link for
help on writing mask-lengths.
http://jodies.de/ipcalc
port number
For protocols which support port numbers (such as TCP and UDP).
Its mandatory that you code the port number of the service
you want to match on. Service names (from /etc/services) may be
used instead of numeric port values.
in | out
Matches incoming or outgoing packets, respectively. in and out
are keywords and its mandatory that you code one or the other
as part of your rule matching criterion.
via IFN
Matches packets going through the interface specified by exact
name. IFN = interface-name. The via keyword causes the interface
to always be checked as part of the match process.
via is mandatory.
setup
This is a mandatory keyword that identifies the session start
request for TCP packets.
keep-state
This is a mandatory keyword. Upon a match, the firewall will
create a dynamic rule whose default behavior is to match
bidirectional traffic between source and destination IP/port using
the same protocol.
limit {src-addr | src-port | dst-addr | dst-port}
The firewall will only allow N connections with the same set of
parameters as specified in the rule. One or more of source
and destination addresses and ports can be specified.
The limit and 'keep-state cannot be used on same rule.
Limit provides the same stateful function as keep-state
plus its own functions.
Stateful filtering treats traffic as a bi-directional exchange of packets comprising a session conversation. It has the interrogation abilities to determine if the session conversation between the originating sender and the destination are following the valid procedure of bi-directional packet exchange. Any packets that do not properly fit the session conversation template are automatically rejected as impostors. This interrogation ability works for all the protocols.
The 'check-state' <action> is used to identify where in the IPFW rules set the packet is to be tested against the dynamic rules facility. On a match the packet exits the firewall to continue on its way and a new rule is dynamic created for the next anticipated packet being exchanged during this bi-directional session conversation. On a no match the packet advances to the next rule in the rule set for testing.
The dynamic rules facility is vulnerable to resource depletion from a SYN-flood attack which would open a huge number of dynamic rules. To counter this attack, FBSD version 4.5 added another new option named limit. This option is used to limit the number of simultaneous session conversations by interrogating the rule's source or destinations fields as directed by the limit option and using the packet's IP address found there. In a search of the open dynamic rules counting the number of times this rule and IP address combination occurred, if this count is greater that the value specified on the limit option, the packet is discarded.
The benefits of logging are obvious, provides information like, what packets have been dropped, what addresses they came from, and where they were going. This gives you a significant edge in tracking down attackers.
Even with the logging facility enabled, IPFW will not generate any rule logging on its own. The firewall administrator decides what rules in the rule set he wants to log and adds the log verb to those rules. Normally only deny rules are logged, like the deny rule for incoming icmp pings. It's very customary to duplicate the ipfw default deny everything rule with the log verb included as your last rule in the rule set. This way you get to see all the packets that did not match any of the rules in the rule set.
Logging is a two edged sword. If you're not careful, you can lose yourself in the over abundance of log data and fill all your free disk space with growing log files. DoS attacks that fill up disk drives is one of the oldest attacks around. These log messages are not only written to syslogd, but also are displayed on the root console screen and soon become very annoying.
The IPFIREWALL_VERBOSE_LIMIT=5 kernel option limits the number of consecutive messages sent to the system logger syslogd concerning the packet matching of a given rule. When this option is enabled in the kernel, the number of consecutive messages concerning a particular rule is capped at the number specified. There is nothing to be gained from 200 log messages saying the same identical thing. For instance, 5 consecutive messages concerning a particular rule would be logged to syslogd, the remainder identical consecutive messages would be counted and posted to the syslogd with a phrase like this:
last message repeated 45 times
All logged packet messages are written by default to /var/log/security file, which is defined in the /etc/syslog.conf file.
Most experienced IPFW users create a file containing the rules and code them in a manner compatible with running them as a script. The major benefit of doing this is the firewall rules can be refreshed in mass with out the need of rebooting the system to activate the new rules. This method is very convenient in testing new rules as the procedure can be executed as many times as needed. Being a script, you can use symbolic substitution to code frequent used values and substituting them in multiple rules. You will see this in the following example.
The script syntax used here is compatible with the 'sh', 'csh', 'tcsh' shells.
Symbolic substitution fields are prefixed with a dollar sign $.
Symbolic fields do not have the $ prefix
The value to populate the symbolic field must be enclosed in "double quotes".
Start your rules file with this.
############### start of example ipfw rules script #############
#
ipfw q -f flush # Delete all rules
# Set defaults
oif="tun0" # out interface
odns="192.0.2.11" # ISP's dns server IP address
cmd="ipfw -q add " # build rule prefix
ks="keep-state" # just too lazy to key this each time
$cmd 00500 check-state
$cmd 00502 deny all from any to any frag
$cmd 00501 deny tcp from any to any established
$cmd 00600 allow tcp from any to any 80 out via $oif setup $ks
$cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks
$cmd 00611 allow udp from any to $odns 53 out via $oif $ks
################### End of example ipfw rules script ############
That's all there is to it. The rules are not important in this example; how the symbolic substitution field are populated and used are.
If the above example was in /etc/ipfw.rules file, I could reload these rules by entering on the FBSD command
sh /etc/ipfw.rules
The /etc/ipfw.rules file could be located anywhere you want and the file could be named anything you wanted.
The same thing could also to accomplished doing it this way as a text file
ipfw -q -f flush
ipfw -q add check-state
ipfw -q add deny all from any to any frag
ipfw -q add deny tcp from any to any established
ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state
ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state
ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/06.09.9-Statefull_Rule_Set.htm 000644 000000 000000 00000035025 10433404272 025354 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
The following non-NATed rule set is an example of how to code a very secure inclusive type of firewall. An inclusive firewall only allows services matching pass rules through and blocks all others by default. All firewalls have at the minimum two interfaces which have to have rules to allow the firewall to function.
All Unix flavored systems including FBSD are designed to use interface lo0 and IP address 127.0.0.1 for internal communication with in the FBSD operating system. The firewall rules must contain rules to allow free, unmolested movement of these special internally used packets.
The interface which faces the public Internet is the one which you code your rules to authorize and control access out to the public Internet and access requests arriving from the public Internet. This can be your user ppp tun0 interface or your NIC that is cabled to your DSL or cable modem.
In cases where one or more NICs are cabled to private LANs (local area networks) behind the firewall, those interfaces must have rules coded to allow free unmolested movement of packets originating from those LAN interfaces.
The rules should be first organized into three major sections: all the free unmolested interfaces, public interface outbound, and the public interface inbound.
The order of the rules in each of the public interface sections should be in order of the most used rules being placed before less often used rules with the last rule in the section being a block log all packets on that interface and direction.
The outbound section in the following rule set only contains allow rules which contain selection values that uniquely identify the service that is authorized for public Internet access. All the rules have the proto, port, in/out, via and keep state options coded. The proto tcp rules have the setup option included to identify the start session request as the trigger packet to be posted to the keep state stateful table.
The inbound section has all the blocking of undesirable packets first for two different reasons. First is these things being blocked may be part of an otherwise valid packet which may be allowed in by the later authorized service rules. The second reason is that by having a rule that explicitly blocks selected packets that I receive on an infrequent bases and dont want to see in the log, this keeps them from being caught by the last rule in the section which blocks and logs all packets which have fallen through the rules. The last rule in the section which blocks and logs all packets is how you create the legal evidence needed to prosecute the people who are attacking your system.
Another thing you should take note of is there is no response returned for any of the undesirable stuff; the packets just get dropped and vanish. This way the attackers have no knowledge if their packets have reached your system. The less the attackers can learn about your system the more secure it is. When you log packets with port numbers you do not recognize, go to
http://www.securitystats.com/tools/portsearch.php and do a port number lookup to find what the purpose of that port number is. Check out this link for port numbers used for Trojans: http://www.simovits.com/trojans/trojans.html
The following non-NATed rule set is a complete, very secure inclusive type of firewall rule set that I have used on my system. You cannot go wrong using this rule set for you own. Just comment out any pass rules for services you dont want.
If you see messages in your log that you want to stop seeing, just add a deny rule in the inbound section.
You have to change the dc0 interface name in every rule to the interface name of the NIC that connects your system to the public Internet. For user ppp it would be tun0.
You will see the pattern in the usage of these rules.
All statements that are a request to start a session to the public Internet use keep-state.
All the authorized services that originate from the public Internet have the limit option to stop flooding.
All rules use in or out to clarify direction.
All rules use via interface name to specify the interface the packet is traveling over.
Add the following statements to /etc/ipfw.rules
################ Start of IPFW rules file ###############################
# Flush out the list before we begin.
ipfw -q -f flush
# Set rules command prefix
cmd="ipfw -q add"
pif="dc0" # public interface name of Nic card
# facing the public Internet
#################################################################
# No restrictions on Inside Lan Interface for private network
# Not needed unless you have Lan.
# Change xl0 to your Lan Nic card interface name
#################################################################
#$cmd 00005 allow all from any to any via xl0
#################################################################
# No restrictions on Loopback Interface
#################################################################
$cmd 00010 allow all from any to any via lo0
#################################################################
# Allow the packet through if it has previous been added to the
# the "dynamic" rules table by an allow keep-state statement.
#################################################################
$cmd 00015 check-state
#################################################################
# Interface facing Public Internet (Outbound Section)
# Interrogate session start requests originating from behind the
# firewall on the private network or from this gateway server
# destine for the public Internet.
#################################################################
# Allow out access to my ISP's Domain name server.
# x.x.x.x must be the IP address of your ISPs DNS
# Dup these lines if your ISP has more than one DNS server
# Get the IP addresses from /etc/resolv.conf file
$cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state
$cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state
# Allow out access to my ISP's DHCP server for cable/DSL configurations.
# This rule is not needed for user ppp connection to the public Internet.
# so you can delete this whole group.
# Use the following rule and check log for IP address.
# Then put IP address in commented out rule & delete first rule
$cmd 00120 allow log udp from any to any 67 out via $pif keep-state
#$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state
# Allow out non-secure standard www function
$cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state
# Allow out secure www function https over TLS SSL
$cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state
# Allow out send & get email function
$cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state
$cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state
# Allow out FBSD (make install & CVSUP) functions
# Basically give user root "GOD" privileges.
$cmd 00240 allow tcp from me to any out via $pif setup keep-state uid root
# Allow out ping
$cmd 00250 allow icmp from any to any out via $pif keep-state
# Allow out Time
$cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state
# Allow out nntp news (IE: news groups)
$cmd 00270 allow tcp from any to any 119 out via $pif setup keep-state
# Allow out secure FTP, Telnet, and SCP
# This function is using SSH (secure shell)
$cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state
# Allow out whois
$cmd 00290 allow tcp from any to any 43 out via $pif setup keep-state
# deny and log everything else thats trying to get out.
# This rule enforces the block all by default logic.
$cmd 00299 deny log all from any to any out via $pif
#################################################################
# Interface facing Public Internet (Inbound Section)
# Interrogate packets originating from the public Internet
# destine for this gateway server or the private network.
#################################################################
# Deny all inbound traffic from non-routable reserved address spaces
$cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP
$cmd 00301 deny all from 172.16.0.0/12 to anyin via $pif #RFC 1918 private IP
$cmd 00302 deny all from 10.0.0.0/8 to anyin via $pif #RFC 1918 private IP
$cmd 00303 deny all from 127.0.0.0/8 to anyin via $pif #loopback
$cmd 00304 deny all from 0.0.0.0/8 to anyin via $pif #loopback
$cmd 00305 deny all from 169.254.0.0/16 to anyin via $pif #DHCP auto-config
$cmd 00306 deny all from 192.0.2.0/24 to anyin via $pif #reserved for doc's
$cmd 00307 deny all from 204.152.64.0/23 to anyin via $pif #Sun cluster interconnect
$cmd 00308 deny all from 224.0.0.0/3 to anyin via $pif #Class D & E multicast
# Deny public pings
$cmd 00310 deny icmp from any to anyin via $pif
# Deny ident
$cmd 00315 deny tcp from any to any 113in via $pif
# Deny all Netbios service. 137=name, 138=datagram, 139=session
# Netbios is MS/Windows sharing services.
# Block MS/Windows hosts2 name server requests 81
$cmd 00320 deny tcp from any to any 137in via $pif
$cmd 00321 deny tcp from any to any 138in via $pif
$cmd 00322 deny tcp from any to any 139in via $pif
$cmd 00323 deny tcp from any to any 81 in via $pif
# Deny any late arriving packets
$cmd 00330 deny all from any to any frag in via $pif
# Deny ACK packets that did not match the dynamic rule table
$cmd 00332 deny tcp from any to any established in via $pif
# Allow traffic in from ISP's DHCP server. This rule must contain
# the IP address of your ISPs DHCP server as its the only
# authorized source to send this packet type.
# Only necessary for cable or DSL configurations.
# This rule is not needed for user ppp type connection to
# the public Internet. This is the same IP address you captured
# and used in the outbound section.
#$cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state
# Allow in standard www function because I have apache server
$cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2
# Allow in secure FTP, Telnet, and SCP from public Internet
$cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2
# Allow in non-secure Telnet session from public Internet
# labeled non-secure because ID & PW are passed over public
# Internet as clear text.
# Delete this sample group if you do not have telnet server enabled.
$cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2
# Reject & Log all incoming connections from the outside
$cmd 00499 deny log all from any to any in via $pif
# Everything else is denied by default
# deny and log all packets that fell through to see what they are
$cmd 00999 deny log all from any to any
################ End of IPFW rules file ###############################
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/06.10-Natd_Statefull_Rule_Set.htm 000644 000000 000000 00000045151 10433404272 026144 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
There are some additional configuration statements that need to be enabled to
activate the NAT function of IPFW. The kernel source needs an 'option divert'
statement added to the other IPFIREWALL statements compiled into a custom
kernel.
option IPFIREWALL
# Adds filtering code into kernel
option IPFIREWALL_VERBOSE
# enable logging thru syslogd(8)
option IPFIREWALL_VERBOSE_LIMIT=5 # stop attack via syslog flooding
option IPDIVERT
# needed to use natd from IPFW
The rc.conf needs the following statements added to the already mentioned statements which are reproduced here:
firewall_enable="YES" # Start
IPFW daemon
firewall_script="/etc/ipfw.rules" # use my custom rules.
filewall_logging="YES" # Enable
packet logging
natd_enable="YES" #
Enable NATD function
natd_interface="rl0" #
interface name of public internet Nic
natd_flags="-dynamic -m" # -m
= preserve port numbers if possible
Utilizing stateful rules with divert natd rules (network address translation) greatly complicates the rule set coding logic. The positioning of the check-state, and 'divert natd' rules in the rule set becomes very, very critical. This is no longer a simple fall-through logic flow. A new action type is used, called 'skipto'. To use the skipto command it is mandatory that you number each rule so you know exactly where the skipto rule number is you are really jumping to.
The following is an uncommented example of one coding method, selected here to explain the sequence of the packet flow through the rule sets.
The processing flow starts with the first rule from the top of the rule file and progress one rule at a time deeper into the file until the end is reach or the packet being tested to the selection criteria matches and the packet is released out of the firewall. It's important to take notice of the location of rule numbers 100 101, 450, 500, and 510. These rules control the translation of the outbound and inbound packets so their entries in the keep-state dynamic table always register the private Lan IP address. Next, notice that all the allow and deny rules specify the direction the packet is going (IE outbound or inbound) and the interface. Also notice that all the start outbound session requests all skipto rule 500 for the network address translation.
Lets say a LAN user uses their web browser to get a web page. Web pages use port 80 to communicate over. So when the packet enters the firewall, it does not match rule 100 because it's headed out not in. It passes rule 101 because this is the first packet so it has not been posted to the keep-state dynamic table yet. The packet finally comes to rule 125 and matches. It's outbound through the NIC facing the public Internet. The packet still has its source IP address as a private LAN IP address. On the match to this rule, two actions take place. The keep-state option will post this rule into the keep-state dynamic rules table and the specified action is executed. The action is part of the info posted to the dynamic table. In this case it's "skipto rule 500". Rule 500 NATs the packet IP address and out it goes. Remember this, this is very important. This packet makes its way to the destination and returns and enters the top of the rule set. This time it does match rule 100 and has its destination IP address mapped back to its corresponding LAN IP address. It then is processed by the check-state rule, it's found in the table as an existing session conversation and is released to the LAN. It goes to the LAN PC that sent it and a new packet is sent requesting another segment of the data from the remote server. This time it gets checked by the check-state rule and its outbound entry is found. The associated action skipto 500 is executed. The packet jumps to rule 500, gets NATed and is released to exit out the external NIC.
On the inbound side, everything coming in that is part of an existing session conversation is being automatically handled by the check-state rule and the properly placed divert natd rules. All we have to address is denying all the bad packets and only allowing in the authorized services. Lets say there is an apache server running on the firewall box and we want people on the public Internet to be able to access the local web site. The new inbound start request packet matches rule 100 and its IP address is mapped to the LAN IP address for the firewall box. The packet is then matched against all the nasty things we want to check for and finally matches against rule 420. On a match two things occur, the limit option is an extension to keep-state. The packet rule is posted to the keep-state dynamic table, but this time any new session requests originating from that same source IP address is limited to two. This defends against DoS attacks of services running on the specified port number. The action is allow so the packet is released to the LAN. On return the check-state rule recognizes the packet as belonging to an existing session conversation, sends it to rule 500 for NATing, and is released to the outbound interface.
#!/bin/sh
cmd="ipfw -q add"
skip="skipto 500"
pif=rl0
ks="keep-state"
good_tcpo="22,25,37,43,53,80,443,110,119"
ipfw -q -f flush
$cmd 002 allow all from any to any via xl0 # exclude Lan traffic
$cmd 003 allow all from any to any via lo0 # exclude loopback traffic
$cmd 100 divert natd ip from any to any in via $pif
$cmd 101 check-state
# Authorized outbound packets
$cmd 120 $skip udp from any to xx.168.240.2 53 out via $pif $ks
$cmd 121 $skip udp from any to xx.168.240.5 53 out via $pif $ks
$cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks
$cmd 130 $skip icmp from any to any out via $pif $ks
$cmd 135 $skip udp from any to any 123 out via $pif $ks
# Deny all inbound traffic from non-routable reserved address spaces
$cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP
$cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP
$cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP
$cmd 303 deny all from 127.0.0.0/8 to any in via $pif #loopback
$cmd 304 deny all from 0.0.0.0/8 to any in via $pif #loopback
$cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto-config
$cmd 306 deny all from 192.0.2.0/24 to any in via $pif #reserved for doc's
$cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster
$cmd 308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast
# Authorized inbound packets
$cmd 400 allow udp from xx.70.207.54 to any 68 in $ks
$cmd 420 allow tcp from any to me 80 in via $pif setup limit src-addr 1
$cmd 450 deny log ip from any to any
# This is skipto location for outbound stateful rules
$cmd 500 divert natd ip from any to any out via $pif
$cmd 510 allow ip from any to any
######################## end of rules ##################
The following is pretty much the same as above, but uses a self documenting coding style full of description comments to help the inexperienced IPFW rule writer to better understand what the rules are doing.
#!/bin/sh
################ Start of IPFW rules file ###############################
# Flush out the list before we begin.
ipfw -q -f flush
# Set rules command prefix
cmd="ipfw -q add"
skip="skipto 800"
pif="rl0" # public interface name of Nic card
# facing the public internet
#################################################################
# No restrictions on Inside Lan Interface for private network
# Change xl0 to your Lan Nic card interface name
#################################################################
$cmd 005 allow all from any to any via xl0
#################################################################
# No restrictions on Loopback Interface
#################################################################
$cmd 010 allow all from any to any via lo0
#################################################################
# check if packet is inbound and nat address if it is
#################################################################
$cmd 014 divert natd ip from any to any in via $pif
#################################################################
# Allow the packet through if it has previous been added to the
# the "dynamic" rules table by a allow keep-state statement.
#################################################################
$cmd 015 check-state
#################################################################
# Interface facing Public internet (Outbound Section)
# Interrogate session start requests originating from behind the
# firewall on the private network or from this gateway server
# destine for the public internet.
#################################################################
# Allow out access to my ISP's Domain name server.
# x.x.x.x must be the IP address of your ISP's DNS
# Dup these lines if your ISP has more than one DNS server
# Get the IP addresses from /etc/resolv.conf file
$cmd 020 $skip tcp from any to x.x.x.x 53 out via $pif setup keep-state
# Allow out access to my ISP's DHCP server for cable/DSL configurations.
$cmd 030 $skip udp from any to x.x.x.x 67 out via $pif keep-state
# Allow out non-secure standard www function
$cmd 040 $skip tcp from any to any 80 out via $pif setup keep-state
# Allow out secure www function https over TLS SSL
$cmd 050 $skip tcp from any to any 443 out via $pif setup keep-state
# Allow out send & get email function
$cmd 060 $skip tcp from any to any 25 out via $pif setup keep-state
$cmd 061 $skip tcp from any to any 110 out via $pif setup keep-state
# Allow out FBSD (make install & CVSUP) functions
# Basically give user root "GOD" privileges.
$cmd 070 $skip tcp from me to any out via $pif setup keep-state uid root
# Allow out ping
$cmd 080 $skip icmp from any to any out via $pif keep-state
# Allow out Time
$cmd 090 $skip tcp from any to any 37 out via $pif setup keep-state
# Allow out nntp news (IE: news groups)
$cmd 100 $skip tcp from any to any 119 out via $pif setup keep-state
# Allow out secure FTP, Telnet, and SCP
# This function is using SSH (secure shell)
$cmd 110 $skip tcp from any to any 22 out via $pif setup keep-state
# Allow out whois
$cmd 120 $skip tcp from any to any 43 out via $pif setup keep-state
# Allow ntp time server
$cmd 130 $skip udp from any to any 123 out via $pif keep-state
#################################################################
# Interface facing Public internet (Inbound Section)
# Interrogate packets originating from the public internet
# destine for this gateway server or the private network.
#################################################################
# Deny all inbound traffic from non-routable reserved address spaces
$cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP
$cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP
$cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP
$cmd 303 deny all from 127.0.0.0/8 to any in via $pif #loopback
$cmd 304 deny all from 0.0.0.0/8 to any in via $pif #loopback
$cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto-config
$cmd 306 deny all from 192.0.2.0/24 to any in via $pif #reserved for doc's
$cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster
$cmd 308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast
# Deny ident
$cmd 315 deny tcp from any to any 113 in via $pif
# Deny all Netbios service. 137=name, 138=datagram, 139=session
# Netbios is MS/Windows sharing services.
# Block MS/Windows hosts2 name server requests 81
$cmd 320 deny tcp from any to any 137 in via $pif
$cmd 321 deny tcp from any to any 138 in via $pif
$cmd 322 deny tcp from any to any 139 in via $pif
$cmd 323 deny tcp from any to any 81 in via $pif
# Deny any late arriving packets
$cmd 330 deny all from any to any frag in via $pif
# Deny ACK packets that did not match the dynamic rule table
$cmd 332 deny tcp from any to any established in via $pif
# Allow traffic in from ISP's DHCP server. This rule must contain
# the IP address of your ISP's DHCP server as it's the only
# authorized source to send this packet type.
# Only necessary for cable or DSL configurations.
# This rule is not needed for 'user ppp' type connection to
# the public internet. This is the same IP address you captured
# and used in the outbound section.
$cmd 360 allow udp from x.x.x.x to any 68 in via $pif keep-state
# Allow in standard www function because I have apache server
$cmd 370 allow tcp from any to me 80 in via $pif setup limit src-addr 2
# Allow in secure FTP, Telnet, and SCP from public Internet
$cmd 380 allow tcp from any to me 22 in via $pif setup limit src-addr 2
# Allow in non-secure Telnet session from public Internet
# labeled non-secure because ID & PW are passed over public
# internet as clear text.
# Delete this sample group if you do not have telnet server enabled.
$cmd 390 allow tcp from any to me 23 in via $pif setup limit src-addr 2
# Reject & Log all unauthorized incoming connections from the public internet
$cmd 400 deny log all from any to any in via $pif
# Reject & Log all unauthorized out going connections to the public internet
$cmd 450 deny log all from any to any out via $pif
# This is skipto location for outbound stateful rules
$cmd 800 divert natd ip from any to any out via $pif
$cmd 801 allow ip from any to any
# Everything else is denied by default
# deny and log all packets that fell through to see what they are
$cmd 999 deny log all from any to any
################ End of IPFW rules file ###############################
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/06.11-OpenBSD_PF_Firewall.htm 000644 000000 000000 00000043531 10433404272 025076 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
As of July 2003 the OpenBSD firewall software application named PF was ported to FBSD. It has become the third firewall software application delivered as an integrated part of the base system install. PF is a complete, fully featured firewall that has optional support for ALTQ (Alternate Queuing). ALTQ provides Quality of Service (QoS) bandwidth shaping that allows guaranteeing bandwidth to different services based on filtering rules. The OpenBSD project does such an outstanding job of maintaining the PF user's guide that it will not be made part of this Installer Guide as that would just be duplicated effort.
More Info can be found at http://pf4freebsd.love2party.net/index.htmlThe OpenBSD PF user's guide is found at http://www.openbsd.org/faq/pf/index.html
Firewalling tutorial http://www.bgnett.no/~peter/pf/en/index.html
The PF program runs in the kernel and consists of the firewall and integrated NAT facilities. PF also has user-land front-end interfaces for controlling the firewall filter and NAT rules, and the logging facility. Program pfctl is used to load the firewall rules. The syntax of the filter rules are very similar to those of IPfilter (IPF).
PF's 3 weakness's are it's logging is primitive in that the logged data is written in binary, logging does not utilize the syslogd facility, and the rule number in the logged data listed by the tcpdump command does not correspond to the /etc/pf.conf text file. Debugging the filter rules is harder due this this.
PF was originally written using a rules processing logic of the last matching rule wins and used only stateless types of rules. Over time PF has been enhanced to include a quick option and a stateful keep state option which drastically modernized the rules processing logic. PFs official documentation covers the legacy rule coding parameters and the legacy rule file processing logic, the modernized functions are completely explained in detail highlighting their benefits in producing a far superior secure firewall.
The instructions contained in this guide are based on using rules that contain the quick' option and the stateful keep state option. This is the basic framework for coding an inclusive firewall rule set.
An inclusive firewall only allows services matching the rules through. This way you can control what services can originate behind the firewall destined for the public internet and also control the services which can originate from the public internet accessing your private network. Everything else is blocked and logged by default design. Inclusive firewall rule sets are much more secure than exclusive firewall rule sets and are the only rule set type covered herein.
Since all firewalls are based on interrogating the values of selected packet control fields, the creator of the firewall rules must have an understanding of how TCP/IP works, what the different values in the packet control fields are and how these values are used in a normal session conversation. For a good explanation go to http://www.ipprimer.com/overview.cfm
Installers Note:
If you are following the 'incremental install method' recommended in this Installers guide, them you only need to concern your self with the building of a rules file at this time. After you have the Lan hardware configured and tested then you need to return to this section to enable NAT and configure its rules.
PF is included in the basic FreeBSD install as a separate run time loadable module. The system will dynamically load the PF kernel loadable module when the rc.conf statement pf_enable="YES" is used. The loadable module was created with pflog logging enabled, no ALTQ support, and defaults to pass all packets.
Using the PF run time loadable module is recommended.
It is not a mandatory requirement that you enable PF by compiling the following options into the FreeBSD kernel. It is only presented here as background information. Compiling PF into the kernel causes the runtime loadable module to never be used.
Sample kernel config PF option statements are in the /usr/src/sys/conf/NOTES kernel source and are reproduced here:
device pf
device pflog
device pfsync
device pf enables support for the Packet Filter firewall.
device pflog enables the optional pflog pseudo network device which can be used to log traffic to a bpf descriptor. The pflogd daemon can be used to store the logging information to disk.
device pfsync enables the optional pfsync pseudo network device that is used to monitor state changes. As this is not part of the loadable module one has to build a custom kernel to use it.
ALTQ is only available by compiling the options into the FreeBSD Kernel. ALTQ is not supported by all of the available network card drivers. Please see the altq manual page for a list of drivers that are supported in your release of FreeBSD.
The following options will enable ALTQ and add additional functionality.
options ALTQ
options ALTQ_CBQ # Class Bases
Queuing (CBQ)
options ALTQ_RED # Random Early
Detection (RED)
options ALTQ_RIO # RED In/Out
options ALTQ_HFSC # Hierarchical
Packet Scheduler (HFSC)
options ALTQ_PRIQ # Priority Queuing
(PRIQ)
options ALTQ_NOPCC # Required for SMP build
options ALTQ enables the ALTQ framework.
options ALTQ_CBQ enables Class Based Queuing (CBQ). CBQ allows you to divide a connection's bandwidth into different classes or queues to prioritize traffic based on filter rules.
options ALTQ_RED enables Random Early Detection (RED). RED is used to avoid network congestion. RED does this by measuring the length of the queue and comparing it to the minimum and maximum thresholds for the queue. If the queue is over the maximum all new packets will be dropped. True to its name, RED drops packets from different connections randomly.
options ALTQ_RIO enables Random Early Detection In and Out.
options ALTQ_HFSC enables the Hierarchical Fair Service Curve Packet Scheduler.
options ALTQ_PRIQ enables Priority Queuing (PRIQ). PRIQ will always pass traffic that is in a higher queue first.
options ALTQ_NOPCC enables SMP support for ALTQ. This option is required on SMP systems.
These settings will take effect only after you have built and installed a kernel with them set.
To build a custom kernel see the Kernel Customizing section.
You need the following statements in /etc/rc.conf to activate PF at boot time:
pf_enable="YES"
# Enable PF (load module if required)
pf_rules="/etc/pf.conf # rules definition file for pf
pflog_enable="YES"
# start Logging function
pflog_logfile="/var/log/pflog" # where pflogd should store the
log file
If you have a LAN behind this firewall and have to forward packets for the
computers in the LAN or want to do NAT, you have to enable the following option
as well:
gateway_enable="YES"
# Enable as LAN gateway
After boot, PF operation can be managed using the pfctl command.
Some example commands are:
pfctl -f /etc/pf.conf # loads the pf.conf file
pfctl -nf /etc/pf.conf # parse the file, but don't load
it
pfctl -Nf /etc/pf.conf # Load only the NAT rules from
the file
pfctl -Rf /etc/pf.conf # Load only the filter rules from
the file
pfctl -sn
# Show the current NAT rules
pfctl -sr
# Show the current filter rules
pfctl -ss
# Show the current state table
pfctl -si
# Show filter stats and counters
pfctl -sa
# Show EVERYTHING it can show
pfctl -e
# Enable PF
pfctl -d
# Disable PF
Note that this just enables or disables PF, it doesn't actually load a rule set. The rule set must be loaded separately, either before or after PF is enabled. For a complete list of commands, please see the pfctl man page.
The pfctl command is used to load your rules file. The pfctl command expects the rules file to be a standard text file. Normally you create a text file containing your custom rules and use this command to replace in mass the currently running firewall internal rules. It's advisable to first flush the current internal rules and state table entry's before loading the rule set to a running environment.
pfctl -F all
pfctl -f /etc/pf.conf
This gives the user the ability to make changes to their custom rules file and run the above pfctl command, thus updating the running firewall with a fresh copy of all the rules without having to reboot the system. This method is very convenient for testing new rules as the procedure can be executed as many times as needed.
A rule set is a group of PF rules coded to pass or block packets based on the values contained in the packet. The bi-directional exchange of packets between hosts comprises a session conversation. The firewall rule set processes the packet two times, once on its arrival from the public Internet host and again as it leaves for its return trip back to the public Internet host. Each TCP/IP service (IE: telnet, www, mail, etc;) is predefined by its protocol, source and destination IP address, or the source and destination port number. This is the basic selection criteria used to create rules which will pass or block services.
PF was originally written using a rules processing logic of the last matching rule wins and used only stateless types of rules. Over time IPF has been enhanced to include a quick option and a stateful keep state option which drastically modernized the rules processing logic.
The instructions contained in this section are based on using rules that contain the quick' option and the stateful keep state option. This is the basic framework for coding an inclusive firewall rule set.
An inclusive firewall only allows services matching the rules through. This way you can control what services can originate behind the firewall destined for the public Internet and also control the services which can originate from the public Internet accessing your private network. Everything else is blocked and logged by default design. Inclusive firewall rule sets are much more secure than exclusive firewall rule sets and are the only rule set type covered herein.
Installers Note:
Warning, when working with the firewall rules, always, always do it from the root console of the system running the firewall or you can end up locking yourself out.See: http://www.openbsd.org/faq/pf/filter.html
See: http://www.openbsd.org/faq/pf/filter.html#state
See: http://www.openbsd.org/faq/pf/nat.html
The logging function is compiled into the PF run time loadable module.
To activate, you need this line added to /etc/rc.conf
pflog_enable="YES"
The logged data defaults to writing in /var/log/pflog
This default can be changed by adding this statement to /etc/rc.conf
pflog_logfile="/var/log/pflog"
If you change the default log file name you also have to change it in newsyslog.conf so it will get rotated. PF does not use the syslogd facility.
The logged data is written in binary and can not be displayed directly. You need to use tcpdump command to convert the binary records to ASCII text.
tcpdump -n -e -ttt -r /var/log/pflog > /var/log/pflog.txt
Because pflogd logs in tcpdump binary format, the full range of tcpdump
features can be used when reviewing the logs. For example, to only see packets
that match a certain port:
tcpdump -n -e -ttt -r /var/log/pflog port 80
This can be further refined by limiting the display of packets to a certain host
and port combination:
tcpdump -n -e -ttt -r /var/log/pflog port 80 and host 192.168.1.3
A real-time display of logged packets is achieved by using the pflog0
interface:
tcpdump -n -e -ttt -i pflog0
As packets are logged they will show up on your monitor screen. This is most
helpful when testing a new rules file or to monitor your firewall when your
system is under attack.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/06.12-PF_Inclusive_Rule_set.htm 000644 000000 000000 00000037207 10433404272 025626 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
The following rule set is an example of how to code a very secure inclusive type of firewall. An inclusive firewall only allows services matching pass rules through and blocks all others by default. All firewalls have at the minimum two interfaces which have to have rules to allow the firewall to function.
All Unix flavored systems including FBSD are designed to use interface lo0 and IP address 127.0.0.1 for internal communication within the FBSD operating system. The firewall rules must contain rules to allow free, unmolested movement of these special internally used packets.
The interface which faces the public Internet is the one which you code your rules to authorize and control access out to the public Internet and access requests arriving from the public Internet. This can be your user ppp tun0 interface or your NIC that is cabled to your DSL or cable modem.
In cases where one or more NIC's are cabled to private LANs (local area networks) behind the firewall, those interfaces must have a rule coded to allow free, unmolested movement of packets originating from those LAN interfaces.
The rules should be first organized into three major sections; all the free and unmolested interfaces, public interface outbound, and the public interface inbound.
The order of the rules in each of the public interface sections should be in order of the most used rules being placed before less often used rules with the last rule in the section being a block log all packets on that interface and direction.
The outbound section in the following rule set only contains pass rules which contain selection values that uniquely identify the service that is authorized for public Internet access. All the rules have the quick, on, proto, port, and keep state option coded. The proto tcp rules have the flag option included to identify the session start request as the triggering packet to activate the stateful facility.
The inbound section has all the blocking of undesirable packets first for two different reasons. First, these things being blocked may be part of an otherwise valid packet which may be allowed in by the later authorized service rules. Second, by having a rule that explicitly blocks selected packets that I receive on an infrequent bases and dont want to see in the log, this keeps them from being caught by the last rule in the section which blocks and logs all packets which have fallen through the rules. The last rule in the section which blocks and logs all packets is how you create the legal evidence needed to prosecute the people who are attacking your system.
Another thing you should take note of is there is no response returned for any of the undesirable stuff; their packets just get dropped and vanish. This way the attackers have no knowledge if their packets have reached your system. The less the attackers can learn about your system the more secure it is.
When you log packets with port numbers you do not recognize, go to http://www.securitystats.com/tools/portsearch.php and do a port number lookup to find what the purpose of that port number is.
Check out this link for port numbers used by Trojans http://www.simovits.com/trojans/trojans.html
The following rule set is a complete, very secure inclusive type of firewall rule set that I have used on my system. You cannot go wrong using this rule set for your own. Just comment out any pass rules for services to dont want to authorize.
If you see messages in your log that you want to stop seeing just add a block rule in the inbound section.
You have to change the dc0 interface name in the symbolic name to the interface name of the NIC that connects your system to the public Internet. For user ppp it would be tun0.
Add the following statements to /etc/pf.conf
################################################################
# define defaults and macros
#################################################################
oif = "dc0"
# oif is the macro name for the
#
NIC facing the public internet
#lif = "xl0"
# lif is the macro name for the NIC facing
#
the Local area network if you have one
dns1 = "{69.22.11.5, 69.22.11.6}" # my ISP's Domain name server IP address
dhcp = "69.22.11.7" # my ISP's DHCP server IP address
ob_state = "flags S/SA modulate state" # outbound
ib_state = "flags S/SA synproxy state" # inbound
#################################################################
# define run time global defaults
#################################################################
set block-policy drop # Sets the default
block behavior to
# packet is silently dropped
set state-policy if-bound # states are bound to the interface
# they're created on
set loginterface $oif
# gather statistics on this interface
scrub out on $oif all random-id
scrub reassemble tcp
#################################################################
# define Nat if you have LAN
#################################################################
#nat on $oif from $lif to any -> ($oif)
#nat on $oif from 10.0.10.0/29 to any -> ($oif)
#pass quick on $lif all # No restrictions on LAN Interface
pass quick on lo0 all # No restrictions on Loopback Interface
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/06.13-Defending_Against_Attacks.htm 000644 000000 000000 00000025024 10433404272 026434 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
A firewall is your first line of defense, But if you allow public access to ports 22, SSH (secure shell), 23, Telnet, or 21, FTP these ports can be bombarded with login attempts using common ID/PW combinations probing for access. In the case of port 80, Web server it can be bombarded with access requests designed to consume server resources resulting in a denial of service to legitimate user requests. To the firewall these all look like legitimate packets.
98 percent of the attackes come from script kiddies or robots. These attacks are all most totally based on indiscriminate rolling through a range of sequential IP address. (IE: They never use DNS to lookup your domain name.) You were found by plain bad luck. These attacks most offten only address the know port numbers listened on by those services. You use this knowledge to defend against this type of attack.
The most common program used to probe is nmap. It's even in the ports system as, security/nmap. Nmap is a utility for network exploration or security auditing. It supports ping scanning (determine which hosts are up), many port scanning techniques, version detection (determine service protocols and application versions listening behind ports), and TCP/IP fingerprinting (remote host OS or device identification). Nmap also offers flexible target and port specification, decoy/stealth scanning, sunRPC scanning, and more.
Check out http://www.insecure.org/nmap/ for more details.
Read Phrack Magazine article September 01, 1997, for overview of the different probing techniques http://www.insecure.org/nmap/p51-11.txt
The simplest defense is to change the port numbers these services use. The /etc/services is where SSH, Telnet, and FTP port numbers are defined and where you would change them at. (Note: Your firewall should only allow passive FTP by not opening high value port number for active FTP data transmission.) For Apache web server you specify the access port number in httpd.conf definitions.
Remote clients who want to access your public services on the alternate port number will have to enter the alternate port number as part of the login command. After setting up alternate port numbers you can have your firewall log all access to ports 21,22,23,or 80 and report the abuse to the ISP owner of the sending IP address using the FreeBSD port ppars-1.0 See Abuse reporting system
Or if you don't want to use the automated Abuse reporting system you can take the sending IP address from your firewall log and do manual whois command to find the ISP owner of the offending IP address along with the ISP's abuse reporting email address and send your own email to them about their client sending you attack packets.
Installers Note: The technique of assigning non-standard ports for SSH, Telnet, and FTP is security through obscurity and is one of the first and easiest security measures an administrator may consider. By no means does this provide protection from the dedicated attacker who has targeted your IP address for some reason. This is just the first security level of hiding through obscurity from the majority of the high school / college freshmen script kiddies who really don't know what they are doing yet. You will be surprised at how effective this really is at discouraging repeat port scan attacks and fraudulent login attempts.
Using the customary port numbers or alternate port numbers for SSH, FTP, or Telnet all failed logins are logged to /var/log/auth.log file. In most cases the sending IP address is the real IP address of the attacker. In the long term the solution is to do whois on the attackers IP address and report him to the ISP who owns the IP address.
In the short term to stop the login attack in progress many people will add a "deny this IP address" rule to their firewall rule set file. Yes this will stop the attack immediately, but when a firewall keeps all these special "deny this IP address" rules the firewall becomes very hard to maintain as that list of denied IP address rules grows longer. A far better solution is to separate the denied IP address list from the firewall rule set. This can be done using the "routed blackhole" command.
Example:
To Add use route add -host attacker_ip 127.0.0.1 -blackhole
To Delete use route delete -host attacker_ip 127.0.0.1 -blackhole
To List use netstat -nr|grep 127
This is executed in the IP stack and is faster than in the firewall when you have over 20 of those special "deny this IP address" rules in the firewall. The "attacker_ip" in found in the log records in /var/log/auth.log file.
You can create a script (route_blackholed_ip.sh) containing route commands for all the IP address that have attacked you in the past and save it to /usr/local/etc/rc.d/ so it will be run at boot time.
The same process used by the abuse reporting system to process the /var/log/security log file can be modified by you to automate the processing of the /var/log/auth.log file to create the route blackhole commands on the fly while the attack is occurring.
Installers Note: The ports system currently contains /security/bruteforceblocker and /security/sshit for automating the capturing of the fraudulent login attempts IP address and inserting firewall rules to block that offending IP address.
BruteForceBlocker is a perl script, that works along with pf - OpenBSD's firewall. It's main purpose is to block SSH bruteforce login attacks via firewall. When this script is running, it checks for sshd log records in the syslog and looks for failed Login attempts and counts number of such attempts. When given IP reaches configured limit of fails, script puts this IP into pf's table and blocks any further traffic to the that box from that given IP.
sshit is a perl script, which works along with ipfw, ipf, and pf. It parses the output of syslogd, finds SSH/FTP bruteforce fraudulent login attempts. If the number of failed login attempts is greater than a threshold set by the administrator, sshit will block the source IP via firewall for a while (administrators can set the period of blocking).
Web server attacks are denial of service (Dos) attacks. There is no trigger that will notify you when this occurs. Most likely your first warning something is wrong is when people start asking you why is your web server down. When you have reason to suspect your web server is under attack you can check /var/log/hpptd-access.log file. This log file gets a log record for every file accessed by your web server. Part of the log record is the requesting IP address or it's DNS name. When you see a lot of log records (in the hundreds) from the same IP address, that is your attacker. In most all cases the requesting IP address is spoofed. Spoofed means the IP address is a real public internet routable IP address belonging to a legitimate user that unknown to him, the attacker has used to hide his real identity.
Like with Login attacks you can add a special "deny this IP address" rule to your firewall rule set file or use the "routed blackhole" command.
The same process used by the abuse reporting system to process the /var/log/security log file can be modified by you to automate the processing of the /var/log/hpptd-access.log file to create the route blackhole commands on the fly while the attack is occurring.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/06.14-Example_ssh_setup.htm 000644 000000 000000 00000065273 10433404272 025134 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
Normally, when using native telnet, rlogin, or ftp your login ID, password and tramsmitted data is sent over the network in an clear, un-encrypted form. Network sniffers anywhere in between the client and server can steal your Login information and/or data transferred in your session.
OpenSSH encrypts all traffic (including login ID and passwords) to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. Additionally, OpenSSH provides a myriad of secure tunneling capabilities, as well as a variety of authentication methods.
In this example we have a FreeBSD system which we will call the host. This is the system that remote users want to have login access to.
We have an Remote FreeBSD system which is located some where on the public internet, we will call this the FBSD-client.
We also have an Remote MS/windows system which is located some where on the public internet, we will call this the Win-client.
This example details the encrypted Host/Client key with passphrase authentication method. This method gives the maximum protection possible utilizing ssh.
====================================================
Type a full screen full of random junk to unblock
it and remember to finish with <enter>. This will
timeout in 300 seconds, but waiting for
the timeout without typing junk may make the
entropy source deliver predictable output.
Just hit <enter> for fast+insecure startup.
====================================================
kern.random.sys.seeded: 1 -> 0
qkcir83,2jsn40pl722jjbqok ---- this is the example junk entered
Generating public/private rsa1 key pair.
Your identification has been saved in /etc/ssh/ssh_host_key.
Your public key has been saved in /etc/ssh/ssh_host_key.pub.
The key fingerprint is:
ed:5d:97:dc:49:98:36:66:fc root@domainname
Generating public/private dsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_dsa_key.
Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub.
The key fingerprint is:
67:e7:90:04:0e:27:2e:d2:97:6a root@a1poweruser.com
Generating public/private rsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
96:db:50:5c:9e:69:88:26:28:54 root@domainname
2. If you do a "ps ax" command you will see sshd as one
of the running tasks.
3. Using adduser or
pw command create a normal user account.
For this example we will use bob as the host user account name.
4. Hit alt/F2 at same time to open second session and login using bob.
Run this command ssh-keygen -t rsa
Just hit enter to take default location and file name
No need to enter a pass phrase for the host user here,
just hit enter 2 times.
This is what you will see
Generating public/private rsa key pair.
Enter file in which to save the key (/bob/.ssh/id_rsa):
Created directory '/bob/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /bob/.ssh/id_rsa.
Your public key has been saved in /bob/.ssh/id_rsa.pub.
The key fingerprint is:
e7:e6:8f:d3:b1:b4:08:27:09:d2 bob@domainname
5. If you want to ssh login as Host root, you have to run
step 5 above while logged in as root on the host.
Also edit /etc/ssh/sshd_config and change this statement
#PermitRootLogin no to PermitRootLogin yes
Then killall HUP sshd
to make sshd task reread its sshd_config file.
1. Using adduser or
pw command create a normal user account.
For this example we will use remotetom as the user account name.
2. Login using remotetom.
Run this command ssh-keygen -t rsa
3. Just hit enter to take default location and file name.
At the "Enter a passphrase prompt" [enter one and write it down,
because it will be needed for ssh login to the host].
This is what you will see
Generating public/private rsa key pair.
Enter file in which to save the key (/remotetom/.ssh/id_rsa):
Created directory '/remotetom/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /remotetom/.ssh/id_rsa.
Your public key has been saved in /remotetom/.ssh/id_rsa.pub.
The key fingerprint is:
e7:e6:8f:d3:b1:b4:08:27:09:56:de:d2 tom@domainname
4. The Public key file you just created /remotetom/.ssh/id_rsa.pub
has to be sent to the Host system. On the host system rename it
to authorized_keys2 and put it into the home directory of the
user setup earlier. In this case ~/bob/.ssh/authorized_keys2.
5. To ssh to the host, enter this ssh hostname or
ssh host-ip-address
The first time you ssh to the Host you will get these messages.
Answer yes if you are sure this first connection is with your
targeted host. Enter exit to terminate session.
# /home/remotetom/.ssh >ssh 10.0.10.2
The authenticity of host '10.0.10.2 (10.0.10.2)' can't be established.
DSA key fingerprint is 04:0e:27:2e:d2:97:9d:7b:62:7e:c9:32:6a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.10.2' (DSA) to list of known hosts.
Enter passphrase for key /remotetom/.ssh/id_rsa
This is where you enter the pass phrase you entered while running
ssh-keygen on this remote client. (remotetom)
6. You are now logged into the Host account bob.
Every time you ssh login again you will just get this prompt
Enter passphrase for key /remotetom/.ssh/id_rsa
7. At this point the Host user bob can login from Host console, or using telnet from a local LAN machine, or from the public internet if your host firewall has port 23 open. If this user is to be only allowed remote ssh client access you can use vipw command to edit the systems master password file and star out his encrypted password. This will deny login from anywhere except remotebob
bob:$1$FXF.CEpf:1001:31::0:0:remote ssh only #:/home/bob:/bin/csh
change it to look like this
bob:*:1001:31::0:0:remote ssh only #:/home/bob:/bin/csh
8. At this point, if remotebob is a notebook pc he can ssh login from any place in the world. If remotebob is always working from home using ip address 192.168.1.32 you can add another level of security by restricting his login to come from that ip address. Do that by adding this statement to the Host /etc/ssh/sshd_config file
AllowUsers bob@192.168.1.32
So far the FBSD-client setup steps above have described how to use native SSH for creating the SSH keys and logging in to the FreeBSD SSHD host. Using ssh's sftp is a command line environment. Meaning you have to know all the FTP commands to navigate around the local and remote directories plus the get and put commands to really move the files between PC's. This can really be a problem for the infrequent ftp user. An command line (I.E. not X) GUI program would make this sftp directory navigation much easier.
We are in luck. The ports system contains 'Midnight commander' an command line GUI program designed after the MS/Windows Norton Commander. It's panel has a 2 up display containing the source and target directory trees. It's normal usage is for navigating around your File system layout. But it has built in functions which allow it to do native ftp and ssh sftp between it self and the remote ftpd or sshd host.
The current version of MC 'IE. Midnight commander' on FreeBSD 6.0 is MC 4.6.0. There is an newer version MC 4.6.1.3 in the ports which may fix the ssh login problem described later.
You still have to run steps 1 through 5 above to create the SSH keys and moved it to the host system and then test ssh sftp login.
After installing MC from the ports system or package system.
You start it be entering mc on the command line.
This brings up the GUI panel. There are 2 ways to use MC for ftp or sftp.
One way uses the different menu panels and allows you to save the login
information as a bookmark. Use F9 to active the
"Left file command options right" menus at the top of the MC panel.
The left & right pull down menu option have the FTP link & SH link option.
The second way is the short cut method. You just enter an "cd" change directory command on the MC command line.
cd /#sh:user@remote Host
user = the name of the user account on the host. In this example (bob)
remote host = the FQDN or IP address of the host
The MC command line at the bottom of the panel asks for the SSH pass phrase.
After entering the pass phrase, the remote hosts directory tree is displayed with a
heading of the /#sh: command used to launched it.
After entering the pass phrase the MC command line does not clear and ends up containing some left over parts of the SSH message. This is a bug.
Holding down the CTL key while pressing the keyboard letter C and O keys at the same time, 2 times in a role will clear the MC command line.
When your finished doing SSH sftp through MC, terminate the MC SSH session with the remote host by hitting F10 key.
There are two MS/Windows SSH client programs. The "Putty" program which provides basic SSH access for Telnet style logins and native FTP access. The "WinSCP3" program which is built on "putty" underling code that provides a Norton commander GUI style SFTP access.
1. You have to get windows putty program from
http://www.chiark.greenend.org.uk/~sgtatham/putty/
Download the current windows installer program.
Currently thats putty-0.58-installer.exe
2. Run the putty-0.58-installer.exe and take all the defaults.
3. Start/programs/Putty/Puttygen
This will create your private and public ssh keys
At the bottom of the window select
ssh2-rsa
Click on generate button.
After keys are created then enter your pass phrase.
Then click on save public key button.
Save it to c:/programs/putty/putty_public_rsa_key
Then click on save private key button.
Save it to c:/programs/putty/putty_private_rsa_key.ppk
In the window area labeled
"Public key for pasting into Open SSH authorized_key file"
Highlight that content and past it into a notepad text
file named win_authorized_keys2.txt
4. The win_authorized_keys2.txt file has to be sent to the
Host system and put in the ~/home/bob/.ssh/ directory.
In this example both the FBSD-client & the WIN-client will
both use the same Host user account to ssh login to.
Since the ~/home/bob/.ssh/authorized_keys2 already contains the
private key for the FBSD-client you have to append the
win_authorized_keys2.txt content to it.
cat win_authorized_keys2.txt >> authorized_keys2
If bob is only to be used by WIN-client then just
cp win_authorized_keys2.txt authorized_keys2
5. start/programs/putty/putty to run it
On the bottom of the window click on "never exit"
Under protocol be sure ssh is clicked.
On the left side click on SSH, then in the
preferred ssh protocol version click on 2 only.
On the left side click on AUTH, remove check mark from
Attempt keyboard-interactive auth (SSH-2).
On the left side click on Sessions to return to main login window.
Enter you host name (IE; your official registered domain name of
the Host box) or its IP address. Then type a name in the saved
session window and click on save button. Now click on the open button
at bottom of window to login to the host.
A ms/dos window will open up and you will receive login as prompt
Enter bob
Then you get
Authenticating with public key "rsa-key-20060209"
Passphrase for key "rsa-key-20060209":
At this point enter the pass phrase you entered when you ran
Start/programs/Putty/Puttygen to create the rsa keys on
the client remotetom.
6. You are now logged into you host box using SSH. You have all
the privileges that host user bob has when you created him.
Every time you start/programs/putty/putty highlight the name
of your saved session and click on the load button. This will
restore your saved session configuration, then click open to launch.
1. You have to get windows WinSCP3 program from
http://winscp.net/eng/index.php
Download the windows installer program.
Currently that's winscp380setup.exe
2. Run winscp380setup.exe and take all the defaults.
3. Start/programs/WinSCP3/keytools/puttygen
This will create your private and public ssh keys
At the bottom of the window select ssh2-rsa
Click on generate button.
After keys are created then enter your pass phrase.
Then click on 'save public key' button.
Save it to c:/Program Files/WinSCP3/putty_public_rsa_key
Then click on 'save private key' button.
Save it to c:/Program Files/WinSCP3/putty_private_rsa_key.ppk
In the window area labeled
"Public key for pasting into Open SSH authorized_key file"
Highlight that content and past it into a notepad text file
named win_authorized_keys2.txt
4. The win_authorized_keys2.txt file has to be sent to the Host system
and put in the ~/home/bob/.ssh/ directory. In this example both
the FBSD-client & the WIN-client will both use the same Host user
account to ssh login to.
Since the ~/home/bob/.ssh/authorized_keys2 already contains the
private key for the FBSD-client you have to append the
win_authorized_keys2.txt content to it.
cat win_authorized_keys2.txt >> authorized_keys2
If bob is to only be used by WIN-client then just
cp win_authorized_keys2.txt authorized_keys2
5. Start/programs/WinSCP3/WinSCP3
In the window on the left, click on SSH
Then for preferred ssh protocol version, click on "2 only"
In the window on the left, click on session
Then fill in your host name FQDN or IP address.
Then the user name of the host account you want to login to.
Then fill in the location of for the rsa putty key created
in step 3 above
c:/Program Files/WinSCP3/putty_private_rsa_key.ppk
For protocol click on sftp
At the bottom of the panel click on the save button
Accept the name in the pop up window or enter your own
value and click OK.
The stored session panel opens, highlight the session name you want
to run and click on the load button. This fills in the session panel
with your saved configuration.
Click on login button to initiate your sftp session with the host.
A pop up window will show asking you to enter the pass phrase you
entered in "Step 3" above. Click on OK after entering you pass phrase.
The first time you SSH to the Host you will get these messages.
Answer yes if you are sure this first connection is with your
targeted host.
The authenticity of host '10.0.10.2 (10.0.10.2)' can't be established.
DSA key fingerprint is 67:e7:90:04:0e:27:2e:d2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 10.0.10.2 (DSA) to the list of known hosts.
The GUI Norton commander style panel will display.
Left side shows the client's directory and the
right side shows the Host user accounts directory
Every time you start/programs/WinSCP3/WinSCP3 highlight the name
of your saved session and click on the load button. This will
restore your saved session configuration, then click login to launch.
Once you open sshs port 22 in your firewall it won't be long before your auth.log starts filling up with failed login attempts. About 99 percent of these failed login attempts are script kiddies or robots. Their attacks are all most totally based on indiscriminate rolling through a range of sequential IP address. (IE: They never use DNS to lookup your domain name.) You were found by plain bad luck. They run scripts that address the known ports listened on by those services which accept logins. You use this knowledge to defend against this type of attack.
The simplest defense is to change the port number ssh uses. The /etc/services is where the port number used by SSH is defined and where you would change it at. Remote clients who want to access your host system will have to enter the alternate port number as part of the login command.
ssh p 77777 hostname or host-ip-address
[-p 77777 is the example alternate ssh port number you specified in /etc/services file]
or edit /etc/ssh/ssh_config on the remote client and change this statement from this
# Port 22
to
Port 77777 [to make the alternate port number permanent]
Windows gutty also has way to change the default ssh port number right on the login window.
The technique of assigning a non-standard port for SSH is security through obscurity and is one of the first and easiest security measures an administrator may consider. By no means does this provide protection from the dedicated attacker who has targeted your IP address for some reason. This is just the first security level of hiding through obscurity from the majority of script kiddies and their robots. You will be surprised at how effective this really is at discouraging repeat port scan attacks and fraudulent login attempts. You will have to open your firewall for the alternate port number you assign to ssh for this to work.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/10.00-FBSD_Basics.htm 000644 000000 000000 00000033260 10433404272 023423 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
Nearly every command on the system comes with a short reference document explaining the basic operation and its various flag arguments. FBSD calls the documentation on each command a manual. Each manual file is contained on the system as a compressed file. All the commands live in /usr/bin; you can list their names with the ls command.
The manuals are grouped by category. Some commands may be in two or more categories and have different documentation in its manual depending on what category it's in. The categories are:
1. General commands
2. System Calls
3. Sub-routines
4. Special files
5. File Formats
6. Games
7. Macros and conventions
8. Maintenance Commands
9. Kernel Interface
To explicitly access a manual by category for the pwd command you would enter man 1 pwd. Whoever thought this concept up must have been asleep at the wheel. How is any body to know in advance what category the command they are interested in belongs to? Just use this format of the command man xxx, where xxx is the command you are interested in. If you are not satisfied with the results you can use the online version of the man pages at
http://www.freebsd.org/cgi/man.cgi. There you can select what FBSD version of the commands to want to see as well as the categories. When I am researching a problem I always use the online man pages because, I can see what category it belongs to. If it also has related commands or the same command in a different category, it will show as a highlighted keyword that I can click on, and the online man system will jump right to it and display its info.For example, to get info on the pwd command from your FBSD system, type in 'man pwd' on the command line and them hit enter on the keyboard. The manual page containing information on the pwd command is displayed. Use the arrow keys to scroll through the information. To exit the displayed man page info you can scroll to the end or press the ctrl key and the C key at the same time. PWD is a simple one, they do get much worse than this one. Over time you will begin to understand the shorthand the FBSD authors use to write these and it gets a little easier to understand. On the other hand some of the manuals are so poorly written they are just so much gibberish.
I will leave it up to you to decide how helpful the manual command documentation is.
The FBSD handbook does not include a list of the FBSD basic commands. There are a lot of books you can buy that have chapters that will explain Unix or Linux commands, and in most cases they are the same in FBSD. But I have found through experience that the number of FBSD commands you really need to know is very small and they are listed below. FBSD always considers upper case and lower case letters to be different. All commands are in lower case.
pwd Displays the directory path you are in
ls List the names of the files in the directory you are in
ls -l Same as ls except it also includes the file details
rm remove file (delete file) rm filename or rm /path/filename
cp copy file (cp source-file target-location)
rehash Search for new scripts and add them to the lookup order.
You have to issue this command every time you create a new
script and after installing most ports or packages.
lpr Print a file to the printer
halt Tell FBSD to close file systems and stop FBSD now
reboot Tell FBSD to close file systems and reboot now
shutdown Issue a message to logged on users that the system is coming down
and then closes file systems and stops FBSD
mkdir Make a new directory mkdir directory name
rmdir Remove directory rmdir directory name (delete directory)
cd Change into directory cd /etc/ppp/
cd / Change directory location back to root directory.
cd .. Change directory location back one sub-directory
ee Edit file ee /etc/rc.conf FBSD has a couple of editors,
but this editor is the easiest to use.
mount Mount a device like the floppy drive or the CDROM drive
umount Unmount a device, used to release a device after
the mount command
ctrl + c Exit the shell right now.
ps ax Display a list of active tasks
chmod Change file permissions
chown Change the owner of the file
chgrp Change the group the file belongs to
pw Add users or delete user accounts
The /etc/syslog.conf file controls what system messages go to what log file. FBSD and most of the 3rd party applications that issue messages do so using facility.level.
Facility - This is who is issuing the messages. The common FBSD facilities are:
Kern. = messages issued from the kernel
Security. = messages issued from IPFW and IPF
Mail = messages issued from sendmail
lpr = messages issued from the printer system
local1 = messages issued from DHCP
Level - The level describes the severity of the message and is a keyword from
the following ordered list (higher to lower severity, from left to right):
emerg, alert, crit, err, warning, notice, info and debug.
There is a wildcard * meaning all or everything.
*.notice means messages from all facilities of level notice and below.
So that would include notice, info, and debug severity messages.
kern.=info means only kernel messages of severity level info are selected.
You have explicit control over the messages you can select to go to different logs. When you add a new log file for an application you just installed be sure to also configure it for rotation and archiving in /etc/newsyslog.conf.
As part of defining a new log file in /etc/syslog.conf you also have to create the file. Using the touch command will do this just fine. Example:
touch /var/log/dhcpd.log will create the dhcpd.log file.
To activate the changes to /etc/syslog.conf you can reboot or bump the syslog task into re-reading /etc/syslog.conf by kill HUP pid. You get the pid (IE: process number) by listing the tasks with the ps ax command. Find syslog in the display, and the pid number is the number in the left column.
The /etc/newsyslog.conf file controls when a log is to be rotated and how it's to be archived. All of the standard logs defined in /etc/syslog.conf as part of the basic FBSD install are preconfigured in the /etc/newsyslog.conf.
The date command displays the current date and time read from the kernel clock. When used to set the date and time, both the kernel clock and the hardware clock are updated. Time changes for daylight saving time, standard time, leap seconds, and leap years are handled automatically.
Entering date on the command line followed by hitting enter will display the current date and time on your screen.
Use this format to set the date/time: date CCYYMMDDHHMM
CC Century (either 19 or 20)
YY Year in abbreviated form (e.g. 89 for 1989, 06 for 2006)
MM Numeric month, a number from 1 to 12
DD Day, a number from 1 to 31
HH Hour, a number from 0 to 23
MM Minutes, a number from 0 to 59
SS Seconds, a number from 0 to 59
date 200306131627
sets the date and time to ``June 13, 2003, 4:27 PM''
Date 1157 will leave the date alone and just change the time to 11:57 AM.
After you get public Internet access you can use the operating system's ntpd daemon which sets and maintains the system time of day by synchronizing with Internet standard atomic clock time servers.
Sometimes you may want to capture everything that displays on the console screen to a file. This is really useful in making a record of what you are doing that you can review later if there is a problem. Use the script command like this:
script /root/console.log
When finished 'enter exit' to stop recording all console messages to the file.
Your FBSD system has a built in scheduling application called cron. This application has preconfigured system management reports scheduled daily, weekly, and monthly which are automatically generated by the cron application and emailed to the root account. As part of the boot process, cron is automatically started as a daemon. The schedules for these system management reports are in /etc/crontab. The scripts that actually generate the system management reports are in /etc/periodic/. Users can create their own reoccurring scheduled tasks using the crontab(1) command which places the users crontab schedule in /var/cron/tabs. Cron wakes up every minute, examining all stored crontabs, checking each command to see if it should be run in the current minute. When executing scheduled crontab commands, any output is mailed to the owner of the crontab (or to the user named in the MAILTO environment variable in the crontab, if such exists).
You will not see these system management reports if you power off your FBSD system before midnight every day. These reports are intended for productions systems that are up 24/7. The hostname= statement in rc.conf is used to determine the domain name the system management reports are emailed to,
root@fbsdjones.com.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/07.00-Setting_up_Local_Area_Network.htm 000644 000000 000000 00000051361 10433404272 027325 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
A local area network (LAN) is a group of computers and associated devices that share a common communications line or wireless link and typically share the resources of a single processor or server within a small geographic area (for example, within an office building). Usually, the server has applications and data storage that are shared in common by multiple LAN computer users. A local area network may serve as few as two or three users (for example, in a home network) or as many as thousands of users (for example, in an FDDI network). Typically, a suite of application programs can be kept on the LAN server. Users who need an application frequently can download it once and then run it from their local hard disk. A user can share files with others at the LAN server.
There are many technical limitations and options to how a LAN is configured depending on if you are a non-commercial user or commercial user and how many of the MS/Windows and/or Unix network server sharing facilities you want to enable.
Basically what determines if you are commercial user or not is how you are known to the public Internet. A commercial user has a permanent, dedicated, high-speed leased Internet line connecting them to their ISP and one or more static IP addresses assigned by their ISP. A static IP address is always the same number; it never changes between logins to the ISP. They have an official registered domain name that points to one of the static IP address which points to their PC that is acting as their gateway. If the commercial user pays for a large block of static IP addresses then they can use these IP address for the computers on the LAN and not need to use NAT (network address translation). Their email will arrive at the gateway PC and is processed by their mail server directly. They do not use their ISP to receive and hold their email for them.
An non-commercial user, like the home user, uses a phone line dial in login to their ISP on a limited speed connection or has a 24/7 cable or DSL high speed connection and gets assigned a single dynamic IP address which changes every time they login. Their ISP receives and holds all their email for them. The only way a public Internet user can find them is if that know the dynamic IP address currently in use by them. From the ISP viewpoint a non-commercial user uses a very small amount of its overall resources and so charges much less for a single user account.
The FBSD system that is acting as the gateway can also be configured to provide different levels of network sharing depending on what kind of operating systems are running on the PCs connected to the LAN. For Unix-like operating systems NFS provides network file and device sharing, while the FBSD port application Samba does the same thing for MS/Windows PCs on the LAN. These facilities, NFS and Samba are not covered in this guide as they are more applicable to commercial users who have large LANs.
See this link for Samba details
http://us1.samba.org/samba/samba.htmlSee the following links for details on FBSD NFS:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-nfs.html
http://www.onlamp.com/pub/a/bsd/2000/07/26/FreeBSD_Basics.html
Normally each family member would have to have their own phone line and unique ISP account to connect all of the family PCs to the Internet simultaneously. This is a costly way of doing this. The alternative is to have a single FBSD system gateway connect to an ISP and then network the other family members PC's behind the gateway using private IP addresses and NAT (Network Addressing Translation) so everything leaving the gateway system looks like it came from the single dynamic IP address assigned by the ISP. Your ISP can not tell if the packet passing through them has been NATed or not.
Installer Note:
When you sign up for service with your ISP you have to sign a user agreement that basically says you are not allowed to do NAT on your PC or run email services or web servers. If you are caught, it's grounds for them to terminate your account. Never tell your ISP tech support people what you are doing. Most ISP's leave open all the ports except the port used by an email server, which they block. More recently some ISPs have started to also block the web server port number.Another simple to configure facility is an anonymous FTP server on the FBSD gateway so LAN users can post files there that they want to pass to other LAN users. This allows them to pass large files between LAN users.
The LAN can be populated with both MS/Windows boxes and FBSD boxes and not cause any problems. ISP's usually allow 5 email address per dial in account. Each family member can have their own email address and using the email client on their PC get their email directly from the ISP email server. Or you can run a task on the FBSD gateway box to download the email from the ISP account on a recurring schedule and store it in the FBSD built in email server called sendmail, and then have all the LAN users get their email from the sendmail server without having the FBSD gateway connected to the Internet.
__________ ________ _____
| | | | | |
| FBSD/GW | | switch |<--------->| LAN |
| | | or | | PC1 | _____
| NIC |<----->| hub |<--| |_____| | |
|__________| |________| | | LAN |
|<--------------->| PC2 |
|_____|
The above diagram shows a simple single LAN circuit. Your FBSD gateway box needs a NIC for each separate LAN circuit. Each circuit must use a unique IP address subnet. You cable the LAN NIC from the back of the FBSD gateway PC to a network switch or hub. A small cheap switch normally has 5 plugs. One plug for each PC on the LAN including the FBSD gateway. You run a cable from the switch to the NIC of each PC you want on the LAN. A LAN circuit can handle many PC's and many downstream switches as long as the max distance of the cable is not exceeded. To add more LAN users you create another circuit by adding another NIC in the FBSD box connected to another switch which has more LAN PC's connected to it. Please note, this is a very simplified LAN description and layout, but is adequate for basic understanding of how the physical parts of the LAN are cabled together.
For the home user with just two PCs, you can cable your FBSD LAN NIC directly to the other PC's NIC with a special crossover cable.
If you are following the 'incremental install method' recommended in this Installers Guide, then it's now time to install the LAN PCI NIC in your PC and cable it to the switch.
Remember that at this point, your PC should only have a single NIC already installed if you have cable access to your ISP, or maybe a PCI internal modem. There should not be any other PCI expansion cards installed as that is what this installers guide expects.
Halt and power off your FBSD system now and install your NIC that will be used for the LAN.
On first boot of FBSD after installing your PCI NIC review the /var/run/dmesg.boot log to verify that it was found.
This is what you are looking for. This means that FBSD GENERIC kernel found your NIC. The dc0 name will be different depending on the manufacture of your NIC.
dc0: <Macronix 98715/98715A 10/100BaseTX> port 0xdc00-0xdcff mem
0xe3000000-0xe30000ff irq 3 at device 19.0 on pci0
dc0: Ethernet address: 00:80:c6:f2:2e:3b
miibus0: <MII bus> on dc0>
dcphy0: <Intel 21143 NWAY media interface> on miibus0
dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc0 is the NIC FBSD internal interface name.
The generic kernel contains device statements for most of the NIC currently on the market. If the /var/run/dmesg.boot log shows your NIC as
pci0: <unknown card> (vendor=0x1274, dev=0x5000) at 19.0
or no message to indicate the probe of the BOIS found any new PCI devices, then you may have an older BOIS on your PC which does not handle PCI cards very well. On older (IE: pre Y2K) PC BOIS, it's very common for the system probe process of the bio's to be unable to find one or more PCI cards. If this happens to you, you have to do some research to determine the problem.
Try the pciconf -lv command to see if it gives you any useful info. Then review the GENERIC source at /usr/src/sys/i386/conf/GENERIC to see if it contains any device statement comments about your NIC based on the manufacturer or chips used. If you do find a device statement in the GENERIC source for your NIC, then add this statement to your kernel source and recompile your kernel.
device pun
This device has additional code to probe your system's BIOS using different methods which in most cases results in your PCI NIC being found.
If the review of the GENERIC kernel source produces no results, them review the kernel source file named LINT at /usr/src/sys/i386/conf/ for comments that describe your NIC by manufacturer name or chips used. Copy the appropriate device statements to the GENERIC kernel source file and then follow the instructions at Kernel Customizing. You will have to create a custom kernel from the GENERIC source including the device statement from the LINT source.
If you find no kernel device statements for your NIC, then it's not supported and you have to get one that is.
There are ranges of special IP addresses reserved for use on private LANs. These special IP address ranges are non-routable on the public Internet. They are listed in the /etc/hosts file.
According to RFC 1918, you can use the following IP address ranges for
private networks which will never be connected to the Internet:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
These can also be written as
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
To communicate with the LAN PC's the FBSD system needs to know what the IP address range of the PC's on the LAN is and the LAN PC's needs to be configured with LAN network information so they know how to perform their part in the communication process.
There are two ways to accomplish this:
The manually way by hand, or
The automatic way using the FBSD port application DHCP.
Before you can manually configure each PC on the LAN by hand, you first have to collect some information from your FBSD gateway box. It's assumed you already have your gateway PC connection to the public Internet already working.
The configuration file /etc/resolv.conf is automatically populated with the IP address of your ISP's primary and secondary domain name servers every time you log in to your ISP. Write down these IP addresses you will need them to configure your LAN PCs.
Now you decide on the private IP address range to use for your LAN. This guide uses a very small portion of the 10.0.0.0/8 range for the private Lan, which is 10.0.10.0/29. This gives 10.0.10.0 through 10.0.10.7. The usable portion of the range is 10.0.10.1 through 10.0.10.6, the 10.0.10.0 and 10.0.10.7 is the reserved pair for broadcasting.
The IP address of the NIC in the FBSD gateway will be 10.0.10.2. The IP address of the first LAN PC to be manually configured will be 10.0.10.3.
On the FBSD gateway system add these two statements to /etc/rc.conf to manually assign the FBSD LAN NIC an IP address and tell FBSD to act as a gateway for the LAN.
ifconfig_dc0="inet 10.0.10.2 netmask 255.255.255.248"
gateway_enable="YES"
The dc0 is the gateway interface name of the NIC the LAN is cabled to.
For a FBSD workstation PC on the LAN, add these statements to /etc/rc.conf to manually assign the FBSD LAN NIC an IP address. Be sure to change dc0 to the interface name of the Nic card in the FBSD LAN PC.
ifconfig_dc0="inet 10.0.10.3 netmask 255.255.255.248"
defaultrouter="10.0.10.2"
Copy the FBSD gateway /etc/resolv.conf file to the FBSD LAN PC, replacing the one that's there. Or edit the FBSD LAN PC's /etc/resolv.conf so it's the same as the one from the FBSD gateway. Reboot system to enable your changes.
To test, ping the gateway server:
ping -c 4 10.0.10.2
Then test DNS by pinging:
ping -c 4 freebsd.org
This procedure has been tested on MS/Windows 98, and ME.
Click on start, settings, control panel, networking. In the window the installed network components are displayed. Scroll through them and click to highlight the TCP/IP line for the NIC you are going to use to connect this box to your LAN. When it's highlighted, the properties button below the window becomes enabled. Click on the properties button and a window pops up which is where you manually configure the NIC TCP/IP network settings.
Under the IP address tab, click on specify IP address. For IP address enter 10.0.10.4
Under the gateway tab, new gateway window enter the IP address of the FBSD gateway
10.0.10.2 and click the add button.
Under the DNS configuration tab, click on enable DNS. In the DNS server search order window enter the first of the two IP addresses you got from the FBSD gateway /etc/resolv.conf file. Click on the add button, then do same thing over again for the second IP address. When you're finished click on the OK button at the bottom of the pop up window, and click OK again. The system will reboot to activate your changes.
To test, click on start, run.
Enter C:\windows\command.com
When a native DOS window opens, ping the gateway server:
Ping 10.0.10.2
Then test DNS:
ping freebsd.org
The DNS servers will convert this domain name to an IP address and then send four pings to it. When this has completed, enter exit to leave native DOS mode.
For each additional FBSD or MS/Windows LAN PCs you want to add, just increment the last digit of the last assigned IP address by 1. You may have to keep a log book so you know what LAN IP addresses you have assigned. All LAN PCs connected to the FBSD gateway 10.0.10.2 NIC have to use the same IP address sub-net, (IE: 10.0.10.x) where in this example x can be 1 through 6.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/08.00-Dynamic_Host_Configuration_Protocol.htm 000644 000000 000000 00000050141 10433404272 030556 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
If you are following the 'incremental install method' recommended in this Installers Guide, you have now completed the basic install of the FBSD Gateway/Firewall server with attached LAN. Everything up to this point has been accomplished using the built in facilities available in the standard FBSD stable release.
In the previous section you manually configured your LAN PC's by hand with the information they needed to communicate with the FBSD gateway. DHCP is used to automate and control the automatic assignment of private IP addresses to your LAN environment.
The Dynamic Host Configuration Protocol (DHCP) is most commonly used in the situation where a LAN (local area network) has too many PC workstations for the LAN administrator to manually configuration each workstation with the information it needs to use for access on the LAN. To automate this process, DHCP was developed. DHCP usually runs on the gateway/firewall machine in server mode. It broadcasts its presence through the LAN to all the workstations who have a DHCP client version of DHCP installed. At workstation boot up it asks the DHCP server for the information necessary to configure itself for access to LAN services.
All Microsoft Windows machines have a DHCP client built in that defaults to using DHCP services without any user configuration. FBSD also has a built in DHCP client, but it needs manual user input to activate it. Many ISP's use DHCP on dial up, DSL, and cable access to achieve the same results a LAN administrator wants for his private LAN.
One of DHCP's major strengths is its ability to manage the dynamic assignment of IP addresses from a pool and to reuse any IP address released when a workstation is removed from the LAN or moved to a different location on the LAN, such as what normally happens in a company work place environment.
To add a DHCP server to FBSD you have to install the port. The best and most commonly used port for this purpose is the isc-dhcpd3 port. For basic background information and locations of additional configuration information review the following.
http://www.isc.org/index.pl?/sw/dhcp/
The ISC-DHCP3 server supports three mechanisms for IP address allocation. In "automatic allocation", DHCP assigns a permanent IP address to a client. In "dynamic allocation", DHCP assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address). In "manual allocation", a client's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client. Dynamic allocation is the only one of the three mechanisms that allows automatic reuse of am address that is no longer needed by the client to which it was assigned. A particular network will use one or more of these mechanisms, depending on the policies of the network administrator.
For our purpose of a simple DHCP server that would fill the needs of the common FBSD user we are going to configure the DHCP server for "dynamic allocation" mode.
When the dhcpd daemon starts up at FBSD boot time, it broadcasts its presence through the LAN, then it sleeps and listens for broadcast requests for network configuration information from the LAN workstations. By default, it will listen on UDP port 67. When such a request is received, then the server will reply to the client machine on UDP port 68, providing the details required to connect to the network such as the IP address assigned to the workstation, subnet mask, default gateway and DNS servers names or IP addresses. Also included with this reply is a length of time for which this information can be used by that particular client. This is known as a DHCP "lease" and a new lease must be acquired by the client when it expires. The length of time for which a lease is valid is decided by the administrator of the DHCP server. The DHCP server keeps a database of leases it has issued in /var/db/dhcpd.leases File. This file is written as a log and can be edited. See man dhcpd.leases which gives a slightly longer description. DHCP clients can obtain a great deal of information from the server. An exhaustive list may be found in man dhcp-options & man dhcpd after DHCP is installed.
To install the DHCP software, use the FBSD dhcp package using the following command
pkg_add -rv isc-dhcp3-server
To start the DHCPD server at boot time add the following statements in the /etc/rc.conf file.
ee /etc/rc.conf
dhcpd_enable="YES"
dhcpd_conf="/usr/local/etc/dhcpd.conf"
dhcpd_ifaces="xl0"
dhcpd_flags="-q"
The -q option will turn off the copyright banner that displays during the FBSD boot up and in the DHCP log every time a broadcast is issued by the DHCP daemon or when a request is received from a workstation DHCP client.
The dc0 is to be replaced with the interface name of the LAN NIC you want DHCP service on from your gateway/firewall FBSD system.
The dhcpd.conf file is delivered as a sample file so you have to make a copy of it without its sample suffix. It contains a lot of comments and commented out statement examples which you can comment out or delete. Edit the main DHCP configuration file and make it look like this.
cp dhcpd.conf.sample dhcpd.conf
ee dhcpd.conf
option domain-name "fbsdjones.com";
option domain-name-servers 208.206.15.11, 208.206.15.12;
# 600=10min, 7200=2 hours, 86400=1 day, 604800=1 week, 2592000=30 days
default-lease-time 86400;
max-lease-time 604800;
authoritative;
ddns-update-style none;
log-facility local1;
# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.
subnet 10.152.187.0 netmask 255.255.255.0 { }
# This is the fbsdjones.com subnet declaration.
# Max of 6 pc on LAN 10.0.10.1 - 10.0.10.6
# 10.0.10.2 is the IP address of the Nic card in FBSD
# 10.0.10.7 is the broadcast IP address
subnet 10.0.10.0 netmask 255.255.255.248 {
range 10.0.10.1 10.0.10.6;
option routers 10.0.10.2;}
The option domain-name "fbsdjones.com"; is the user selected domain name from the hostname="gateway.fbsdjones.com" statement of /etc/rc.conf.
The option domain-name-servers contains the DSN server's IP addresses of your ISP from /etc/resolv.conf nameserver statements which get populated automatically when you connect to your ISP. If you have your own private LAN domain DSN server, make it the first one in the list, and in that case you can use full domain names instead of IP address (such as dnslocal.fbsdjones.com, dsn1.isp-domain.com).
The default-lease-time and max-lease-time have values in seconds to set the elapse period for these function. The values I show are good to go with.
The authoritative; options tells the DHCP daemon server that it is the boss and is in control of issuing all the information to the LAN DHCP clients.
The ddns-update-style none; tells DHCP that there is no local LAN DSN server. If you have one, change this from none to interim. In the dhcpd.conf.sample you will see comments saying none and ad-hoc are the two options. This is no longer true for DHCP version 3.0. Ad-hoc has been deactivated and replaced with interim. See man dhcpd.conf for details.
The log-facility allows you to segregate the DHCP messages to a separate log for recording. You are going to use local1 for logging of DHCP server error messages;
subnet 10.0.10.0 netmask 255.255.255.248 {
range 10.0.10.1 10.0.10.6;
option routers 10.0.10.2; }
The subnet 10.0.10.0 netmask 255.255.255.248 statement declares the maximum subnet IP address range. In this case the last three digits in the netmask, 248 determines the range. This means a total of 8 IP addresses, 10.0.10.0 through 10.0.10.7 are allocated as the subnet range. 10.0.10.0 and 10.0.10.7 are reserved for the broadcast process.
The range 10.0.10.1 10.0.10.6; is saying this range of IP addresses makes up the pool of addresses that are to be used for dynamic IP allocation to DHCP clients. It's a small home LAN with only two MS/Windows boxes and a single FBSD box on it now. That can grow to six machines without making any changes to this statement group.
The option routers 10.0.10.2 statement is a bit miss-leading. What this is referring to is the NIC in the FBSD box the DHCP server runs on and the LAN being configured is cabled to. In our case the NIC has an IP address of 10.0.10.2 which is specified in /etc/rc.conf by the ifconfig_dc0="inet 10.0.10.2 netmask 255.255.255.248" statement.
The principle behind bitmasks and netmasks is simple, but often confusing to new users as it requires knowledge of binary numbers. For a quick reference, the following table illustrates what network ranges are indicated by the corresponding bitmasks/netmasks up to a default class C netmask.
Bitmask Netmask Total IP's / Usable IP's
32 255.255.255.255 1 1
31 255.255.255.254 2 1
30 255.255.255.252 4 2
29 255.255.255.248 8 6
28 255.255.255.240 16 14
27 255.255.255.224 32 30
26 255.255.255.192 64 62
25 255.255.255.128 128 126
24 255.255.255.0 256 254
22 255.255.192.0 16320 16318
20 255.255.128.0 32768 32766
16 255.255.0.0 65536 65534
12 255.128.0.0 8.388608+e6 8.388606+e6
8 255.0.0.0 256^3 (256^3)-2
0 0.0.0.0 (all IP's) 256^4 (256^4)-2
As you can see, there is a definite pattern. The number of total IP's always doubles, and the number of usable IP's is always total - 2. This is because for every IP network/subnet there are two IP's reserved for the network and broadcast addresses. The netmask's last octet starts at 255 and constantly decreases by multiples of 2, while the bitmask decreases by multiples of 1, because in binary, each shift over to the left halves the number, not divides by ten like in the decimal number system. This same pattern goes for all possible netmasks and bitmasks.
Go to http://jodies.de/ipcalc to calculate the information about subnets. You can also download the script that does the calculations.
Since you told DHCPD to use local1 for logging in the dhcpd.conf configuration file above, you now have to complete the logging environment configuration by adding the following statement to /etc/syslog.conf.
ee /etc/syslog.conf
local1.notice /var/log/dhcpd.log
This log file does not exist, so you must create it.
touch /var/log/dhcpd.log
To activate the changes to /etc/syslog.conf you can reboot or bump the syslog task into re-reading /etc/syslog.conf by using the kill HUP pid command. You get the pid (IE: process number) by listing the tasks with ps ax command. Find syslog in the display and the pid number is the number in the left column.
Now you must set up log rotation. Add this statement.
ee /etc/newsyslog.conf
/var/log/dhcp.log 600 3 100 * B
You can change the log rotation triggers to whatever you want.
See man newsyslog for info on what the trigger values mean.
The DHCPD daemon has a start up script located at /usr/local/etc/rc.d/
This directory location is where FBSD looks for files that end in .sh and executes them at the end of the boot process to start the applications.
You can administer the DHCPD server from the command line using
/usr/local/etc/rc.d/isc-dhcp.sh start
stop
restart
Restart is used to reread dhcp.conf file after making changes.
Now manually start DHCP by entering this on the command.
/usr/local/etc/rc.d/isc-dhcp.sh start
Issue 'ps ax' command to see the DHCP daemon running in the active task list.
To test the DHCPD server you need a PC on the LAN.
First let's check the LAN MS/Windows box network configuration. Click on the following buttons in this order. Start/settings/control panel/network/. Highlight TCP/IP and click on properties button. In the IP address tab the 'obtain IP address automatically' should be to only thing check marked. All the fields in the other tabs must be blank. If this is what you have use the cancel buttons to back yourself out. If you answer ok, you may have to have the windows install CDROM to update the network section.
Windows 98, 2000, and ME have a program c:/windows/winipcfg.exe which will show you the DHCP info it's using. Start the winipcfg program by clicking on start, run, and type c:/windows/winipcfg.exe into the run window and then hit the OK button. Click on the more info button to see everything. You should be able to comprehend what you see back to the dhcpd.conf options as explained above. Click on the 'renew all' button to acquire a new DHCP lease.
The isc-dhcp3 port comes with a client. I am not going to cover the isc-dhcp3 port client configuration process, because FBSD comes with a DHCP client built into the basic FBSD system.
To activate the built in dhcp client on a FBSD LAN PC, edit /etc/rc.conf and add the following statement to tell FBSD what interface the client DHCP should use:
ee /etc/rc.conf
ifconfig_dc0="DHCP" # Where dc0 is the FBSD Nic card interface name.
That's it, configuration complete. Reboot to activate your changes.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/09.00-FBSD_System_Security.htm 000644 000000 000000 00000071145 10433404272 025406 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
The FBSD operating system itself has security options which control the processing of network packets and access to authorizing changes to the running kernel. These options are enabled from different places from within FBSD, like from the kernel source, the rc.conf boot start up file, and the internal sysctl MIB control file, sysctl.conf.
The first line of defense in protecting your system is your firewall software application. Its general purpose is to only allow the starting of outbound or inbound session conversations for services that you have explicitly authorized using stateful rules. Stateful rules will monitor the bi-directional exchange of the packets of the session conversation so no fraudulent packets can be inserted into the conversation by attackers or attacks based on mass amounts of invalid packets. Whatever firewall software application you use, you must code stateful firewall filter rules or you defeat the purpose of the firewall. The importance of stateful rules cannot be over-emphasized.
The second line of defense is to take due diligence. This means to spend some time to enable the network security options scattered around FBSD to make it even harder for an attacker to penetrate your system and then be able to move around and or change things. This is detailed in the network packet options section.
FBSD provides a third line of defense to restrict system file changes and a way to compartmenalize processes in jails. User data can use GEOM Based Disk Encryption (gbde) to transparently encrypt entire file systems. No cleartext ever touches the hard drive's platter. The options in this category can be considered paranoia overkill for the normal home user. Their covered in detail in the security paranoia section.
For additional info see FREEBSD SECURITY & HARDENDING GUIDE
FBSD has some options that can be used to control how some kinds of attacking packets are handled by the basic FBSD operating system. For some unknown reason this version of FBSD has more than one way of implementing the network packet options. Some are only changeable in sysctl.conf, others only in rc.conf and still others in the kernel source options.
There is no FBSD documentation that says that these network packet options are still active if an application software firewall is being used. Now on the other hand, using the network packet options have shown to cause no problems when used with an application software firewall, so I recommend enabling them wherever they are enabled from as a fail safe precaution. You should not rely on these network packet options as your sole means of protecting your network environment.
I chose to enable and document the network packet options which are enabled in sysctl even if they can also be enabled in rc.conf. The network packet options I enable in rc.conf has to happen there, because that is the only place these particular options can be enabled.
Add the following statements to the /etc/sysctl.conf file. You can drop the comments, but I always find them helpful later when I am looking for a problem.
####################################################################
#
# The sysctl.conf file contains MIB's to change the default setting
# of internal options of the kernel at boot up time. These MIB's
# control how network packets are handled after the IPFW or IPFILTER
# software application firewalls return the packet to the kernel.
# Some of these MIB's may seem like they are doing the same thing,
# but because there is no FBSD provided documentation on the order
# these MIB's get control, they all get enabled here and we let the
# kernel do its thing.
#
# NOTE: Some of these MIB's can also be set in rc.conf and/or the
# kernel source. This will not hurt anything.
#
####################################################################
####################################################################
# Redirect attacks are the purposeful mass issuing of ICMP type 5 packets.
# In a normal network, redirects to the end stations should not be required.
# To defend against this type of attack both the sending and accepting of
# redirect should be disabled. The first statement below enables the MIB
# to drop all inbound icmp redirect packets without returning any response.
# The second statement turns off the logging of redirect packets because
# there in no limit and this could fill up your logs consuming your whole
# hard drive. But there is no information about where the redirect packets
# get logged. The last statement changes the FBSD default about allowing
# redirects to be sent from this system to the Internet from yes to no.
# This option is ignored unless the host is routing IP packets, and
# should normally be enabled (=1) on all systems
# man icmp(4) and inet(4) and man ip(4) do not contain info about these MIBs.
# man sysctl(3) does have info on ip.redirect
net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=0
net.inet.ip.redirect=0
####################################################################
# Source routing is another way for an attacker to try to reach non-routable
# addresses behind your box. It can also be used to probe for information
# about your internal networks. These functions come enabled as part of the
# standard FBSD core system. The following will disable them.
# man inet(4) and man ip(4) do not contain any information on these MIBs.
net.inet.ip.sourceroute=0
net.inet.ip.accept_sourceroute=0
####################################################################
# This MIB only drops ICMP echo requests which have a destination of your
# broadcast address. For example, if your network is 10.10.0.1/24,
# (making your subnet mask 255.255.255.0) then your network broadcast address
# is 10.10.0.255. When a host on your network needs to send a message to all
# other hosts on the subnet (which happens more often than you may think) it
# uses this address. Everyone listens on it. Hosts outside your network have
# no reason to be sending packets to your broadcast address. This MIB rejects
# all of the broadcast echo traffic from the outside world to your network
# broadcast address. If this host is a firewall or gateway, it should not
# propagate directed broadcasts originating from outside your private network.
# The following statement sets the default to no, rejecting all external
# broadcasts requests.
# man sysctl(3) has some info.
# man inet(4) and man icmp(4) do not contain any information on these MIBs.
net.inet.icmp.bmcastecho=0
####################################################################
# This changes the system behavior when connection requests are received
# on TCP or UDP ports where there is no socket listening. The normal
# behavior, when a TCP SYN segment is received on a port where there
# is no socket accepting connections is for the system to return a
# RST segment and drop the connection. The requesting system will
# see this as a "Connection reset by peer".
#
# By turning the TCP black hole MIB on with a numeric value of one, the
# incoming SYN segment is merely dropped, and no RST is sent, making
# the system appear as a blackhole.
#
# By setting the MIB value to two, any segment arriving on a closed
# port is dropped without returning a RST.
# This provides some degree of protection against stealth port scans.
# The following enables this MIB. man tcp(4) and man udp(4) blackhole(4)
# contain a little information on these MIBs.
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
####################################################################
# The log_in_vain MIB will provide you with logging of attempted
# connections to your box on any port which does not have a service
# running on it. For example, if you do not have DNS server on your
# computer and someone would try to access your computer through DNS
# port 53, you would see a message such as: Connection attempt to
# UDP yourIP:53 from otherIP:X (where X is some high port #) displayed
# on the root console screen. This message also gets posted to
# /var/log/messages & /var/log/security.log.
# The following statements enable this function.
# man tcp(4) and man udp(4) contain a little information on these MIBs.
net.inet.tcp.log_in_vain=1
net.inet.udp.log_in_vain=1
####################################################################
# To defend against SYN attacks more commonly known as SYNFLOOD attacks,
# the two queues which are targeted by this type of attack should
# have their size increased so that the queues can withstand an attack
# of low to moderate intensity with little to no effect on the stability
# or availability of the system. FBSD maintains separate queues for
# inbound socket connection requests. One queue is for half-open sockets
# (SYN received, SYN|ACK sent), and the other queue for fully-open sockets
# awaiting an accept() call from the application.
# The following statement increases the queue size from 128.
kern.ipc.somaxconn=1024
####################################################################
# By allowing aged ARP entries to remain cached or lying around
# allows for the possibility of a hacker to create a resource
# exhaustion or performance degradation by filling the IP route cache
# with bogus ARP entries. This in turn can be used as a Denial of
# Service attack. To prevent this sort of problem, the following
# statement shortens the amount of time an ARP will be cached
# from 1200 to 600 seconds.
net.link.ether.inet.max_age=600
###################### end of sysctl ####################################
Delivered as part of the FBSD core system is a non-secure FTP server and Telnet server. They are labeled non-secure because, when logging into these servers the account ID and password are transmitted as clear text. Now for LAN users behind your firewall this is not a security problem, but if you allow access to these servers from the public Internet, an attacker can capture packets on the public Internet looking for the plain text ID and password. This is considered a security risk. Program SSH provides secure encrypted communications between two untrusted hosts over an insecure network. SSH has a built in FTP and telnet servers and should be the only way used to gain access to FTP and or Telnet from the public Internet. Secure and non-secure FTP and Telnet are covered in the FBSD Administration Section.
The automatic starting of the non-secure FTP and Telnet services is controlled by the "Internet super-server" inetd. Do a ps ax command and review the active task list to see if inetd is running. If its running and you are not using it, add this statement to /etc/rc.conf to disable it.
inetd_enable="NO"
The following rc.conf statements activate knobs which can also be activated in sysctl.conf, which we already did. I list them here just so you can recognize them.
#log_in_vain="YES"
#icmp_drop_redirect="YES"
#icmp_log_redirect="YES"
#icmp_bmcastecho="NO"
The system logs default to being able to bind to an internal socket which allows them to be sent to some other system for recording. If you are not doing that on purpose then this option should be disabled using this statement.
syslogd_flags="-ss"
SSHD which provides secure logins defaults to no. If you want to use this function, then you have to enable it with the following statement.
sshd_enable=YES
All new users of FBSD start with the GENERIC kernel source to copy and name as their own customized kernel source. See COMPILING KERNEL for instructions. The following are things you can do in the kernel source to tighten up security even more. You can prefix statements with # to make it a comment to disable it or delete the statement all together.
Make these changes.
At the top the file is the following statement.
#options INET6 # IPv6 communications protocols
Ipv6 is a developmental protocol, if you are not testing this protocol on purpose, it should be disabled.
A few lines down are the network filesystem options
#options NFS # Network filesystem
#options NFS_ROOT # NFS usable as root device
Comment these out to disable them
Disable the following options because Kernel PPP has been replaced and you disabled Ipv6 earlier.You will never have use for these. Thay're located at the end of the kernel source statements.
#pseudo-device sl 1 # Kernel slip no longer used
#pseudo-device ppp 2 # Kernel PPP replaced by user ppp
#pseudo-device faith 4 #IPv6-to-IPv4 relaying (translation
You should have your IPFILTER or IPFIREWALL (IPFW) enabling statements already in your kernel source. Just to keep all the security options grouped together, place these by them.
options TCP_DROP_SYNFIN # Adds support for ignoring TCP packets
# with SYN+FIN. This prevents nmap from
# identifying the TCP/IP stack, but
# breaks support for RFC1644 extensions
# & is not recommended for web servers
# behind the firewall.
The comments with this option are from the LINT kernel source word for word. I have an Apache web server running on my gateway/firewall box, and I use this option and can not see anything wrong happening.
options ICMP_BANDLIM # Enables icmp error response bandwidth
# limiting. This will help protect from
# D.O.S. packet attacks.
options RANDOM_IP_ID # Causes the ID field in IP packets to be
# randomized instead of incremented by 1 with
# each packet generated. This closes a minor
# information leak which allows remote
# observers to determine the rate of packet
# generation on the machine by watching the
# counter.
options NO_LKM # disable FBSD ability to dynamically load
# kernel modules. If you are using the IPFILTER
# load module dont do this
If you do not have a printer cabled off the parallel port of this PC then disable these options.
# Parallel port
#device ppc0 at isa? irq 7
#device ppbus # Parallel port bus (required)
#device lpt # Printer
#device plip # TCP/IP over parallel
#device ppi # Parallel port interface device
If you are not copying this system to other PCs with expansion cards from different manufacturers, then besides the security benefit you can also reduce the time it takes to compile the kernel by removing all unused device drivers. Review your /var/run/dmesg.boot log messages to see which devices you are really using and only keep those. Comment out all the others. Do not delete the following device; it is used by most NICs but does not show up in dmesg as used.
device miibus # NICs that use MII bus support
It's very important that you completely understand the impact of activating the following options will have on your ability to make changes to your system.
The simplest thing you can do is set the immutable flag on all system binaries and /etc config files with:
chflags schg /bin/*(*) /sbin/*(*) /usr/bin/*(*) /usr/sbin/*(*) /etc/*(*)
Setting the immutable flag on means the files are marked as being protected from being written over. Once you execute the above command, no process can overwrite those files, thus increasing the level of difficulty for the attacker and increasing the odds in your favor of the attacker leaving error messages in the system log. On the other hand, you as the root user can not make any changes to those files so marked either. Every time you want to make changes you have to issue the command to turn off the immutable flag on all the same files. Use this command to do that:
chflags noschg /bin/*(*) /sbin/*(*) /usr/bin/*(*) /usr/sbin/*(*) /etc/*(*)
You can use "ls -lo" command to see the immutable flags of existing files.
The Jail Facility and the rc.conf securelevel options provide the maximum in security paranoia overkill available utilizing the built in facilities of FBSD.
Installer Note: There are two free public software applications for the seriously paranoid users. The CERB Reality project at http://cerber.sourceforge.net/ provides a additional level of overkill based on securing FBSDs heritage dependences on the Unix permissions structure, and the very sophisticated port mapper for security auditing your system (see http://www.insecure.org/nmap/ )
Check out http://www.nagios.org/about.php for a free host and service monitor which will inform you of network problems before your clients, end-users or managers do. The monitoring daemon runs intermittent checks on hosts and services you specify using external "plugins" which return status information to Nagios. When problems are encountered, the daemon can send notifications out to administrative contacts in a variety of different ways (email, instant message, SMS, etc.). Current status information, historical logs, and reports can all be accessed via a web browser.
The jail facility is the creation of a special purpose jail directory tree containing an entire FreeBSD distribution. Any processes run are confined to the jail directory tree, because the parent directory of the jail is chrooted.
For details, see man jail or online at:
http://www.freebsd.org/cgi/man.cgi?query=jail&apropos=0&sektion=0&manpath=FreeBSD+6.0-RELEASE+and+Ports&format=htmlhttp://subwiki.honeypot.net/cgi-bin/view/Freebsd/JailAdmin
http://docs.freebsd.org/44doc/papers/jail/jail.html
The kernel runs with five different levels of security. Any super-user process can raise the security level, but no process can lower it. The security levels are:
-1 Permanently insecure mode - always run the system in level 0 mode.
This is the default initial value.
0 Insecure mode - immutable and append-only flags may be turned off; all devices may be read or written subject to their permissions.
1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted file systems, /dev/mem, and /dev/kmem may not be opened for writing; kernel modules (see kld(4) may not be loaded or unloaded.
2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with file systems by unmounting them, but also inhibits running newfs(8) while the system is multi-user.
3 Network secure mode - same as highly secure mode, plus IP packet filter rules (see ipfw(8) and ipfirewall(4)) cannot be changed and dummynet(4) configuration cannot be adjusted.
If the security level is initially nonzero, then init leaves it unchanged. Otherwise, init raises the level to 1 before going multi-user for the first time. Since the level cannot be reduced, it will be at least 1 for subsequent operation, even on return to single-user. If a level higher than 1 is desired while running multi-user, it can be set before going multi-user, (IE: by the startup script rc(8), or using sysctl(8)) to set the 'kern.securelevel' variable to the required security level.
Setting the security level above 1 too early in the boot sequence can prevent fsck(8) from repairing inconsistent file systems. The preferred location to set the security level is at the end of /etc/rc.conf after all multi-user startup actions are complete.
The securelevel option is intended for a production machine whose configuration is fixed and does not evolve anymore. This one option not only makes it very difficult for the attacker, but if you forget you have it turned on, or someone new takes over administrating the system and doesn't know about this, they will find thenselves locked out of the system just like an attacker. You are forewarned.
In /etc/rc.conf as the last statements in the file add these statements:
# enable kernel security levels
kern_securelevel_enable=YES # turn on kernel security levels
kern_securelevel=3 # turn on max kernel security level
Sensitive user data segerated into private partitions can have all the files transparently encrypted so no cleartext data ever touches the hard drive's platter by using GEOM Based Disk Encryption (gbde). See the offical handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/10.07-Using_the_Floppy_drive.htm 000644 000000 000000 00000032243 10433404272 026077 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
FBSD has its own file system. This file system is different that the MS/Windows file system. A MS/Windows PC can not read FBSD file systems, but FBSD can read and write the MS/Windows file system. Both FBSD and MS/Windows must format the floppy disk to their file system.
Load a floppy disk into the floppy drive.
disklabel w -r /dev/fd0 fd1440 # FBSD ufs file system.
newfs /dev/fd0 # create ufs file system on floppy
To use the floppy, the floppy drive must first be mounted to the system. The basic FBSD system comes with a generic mount point called /mnt I find it much more convenient to create a floppy mount point call /a like MS/Windows drive A which is the floppy drive. Since we have a new, clean, fresh install of FBSD the /a mount point has to be created. This only has to be done once.
cd / # change to top of directory tree
mkdir /a # make directory
Load a FBSD formatted floppy disk into the floppy drive.
mount /dev/fd0 /a # mount device to mount point /a
cd /a # change to /a
You have already formatted the floppy, created the mount point, and mounted the drive.
cp /etc/motd /a/ # copy motd file to floppy
ls # list contents of directory,
# You should see the motd
# file listed as being on /a
It's real easy to just press the floppy drive eject button and remove the floppy disk. This will create problems for you as the floppy drive is still mounted and cannot be un-mounted without a floppy disk loaded in the drive. There is a sequence of commands you have to execute to free up the floppy drive before removing the floppy disk.
cd / # change directory to top of directory tree
umount /a # un-mount the floppy drive
If you get error message 'device busy', that means you forgot to change the directory pointer to a different location instead of /a. Do the cd / command again.
Load MS/Windows floppy into floppy drive
mount t msdos /dev/fd0 /a # mount device to mount point /a
cd /a # change to /a
Like most users I have an environment of both MS/Windows PC's and FBSD PC's. It's just too hard to keep separate floppy disks formatted just for FBSD and others formatted for MS/Windows. There are a lot of times when I need to copy files from FBSD to MS/Windows or the reverse. I have experienced the best way is to only use MS/Windows formatted floppy disks and configure FBSD to use them automatically. This can be configured in the /etc/fstab file
ee /etc/fstab
This is what the fstab file will look like.
# See the fstab(5) manual page for important information on automatic mounts
# of network filesystems before modifying this file.
#
# Device Mountpoint FStype Options Dump Pass#
/dev/ad0s1b none swap sw 0 0
/dev/ad0s1a / ufs rw 1 1
/dev/ad0s1f /tmp ufs rw 2 2
/dev/ad0s1g /usr ufs rw 2 2
/dev/ad0s1e /var ufs rw 2 2
/dev/acd0c /cdrom cd9660 ro,noauto 0 0
proc /proc procfs rw 0 0
You need to add the following line.
/dev/fd0 /a msdos rw,noauto,longnames 0 0
so the file looks like this
# Device Mountpoint FStype Options Dump Pass#
/dev/ad0s1b none swap sw 0 0
/dev/ad0s1a / ufs rw 1 1
/dev/ad0s1f /tmp ufs rw 2 2
/dev/ad0s1g /usr ufs rw 2 2
/dev/ad0s1e /var ufs rw 2 2
/dev/acd0c /cdrom cd9660 ro,noauto 0 0
/dev/fd0 /a msdos rw,noauto,longnames 0 0
proc /proc procfs rw 0 0
Save the file and reboot to enable.
After enabling your change by rebooting your FBSD system, you can now mount your floppy drive with this command: mount /a
Load a MS/windows floppy into thefloppy drive.
mount /a # mount device to mount point /a
cd /a # change to directory
ls # list content of floppy disk
cd / # leave directory
umount /a # to dismount the disk in the floppy drive.
IDE controlled CDROM drives work the same way as the floppy drive does. FBSD comes with one CDROM drive preconfigured in /etc/fstab. You only mount data CDROMs, music CDs are mounted by the music playing software you use, as does the software you use to write CDs.
Load a standard cd9660 (Rock Ridge Extensions) CD in the drive.
mount /cdrom # mount device to mount point /cdrom
cd /cdrom # change to directory
ls # list content of CDROM disk
cd / # leave directory
umount /cdrom # to dismount a CDROM disk from the drive
If you have two CDROM drives you can add the shortcut mount command for it, just like its explained in the Easier way to mount MS/Windows floppies section above. Edit /etc/fstab and add the following statement:
/dev/acd1c /cdrom2 cd9660 ro,noauto 0 0
Then create its mount point:
cd /
mkdir /cdrom2
Reboot the system to enable your change.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/10.09-User_Account_Admin.htm 000644 000000 000000 00000044347 10433404272 025144 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
FBSD has built in commands for the administration of user accounts. FBSD only allows users that have a predefined account on the system to have access to its facilities. The account name/ID and password is what you are prompted for during the login process, whether locally from the FBSD console screen or remotely using some client application software. Email, Telnet, and FTP are some of the most popular facilities who's access is controlled by the user account. The FBSD Handbook at
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/users-modifying.html gives a very good explanation of FBSD custom account admin scripts. These scripts are implemented around the pw(8) command. The man pw is also good.
When FBSD is first installed the pw command does not have its pw.conf option file. The pw command stills works but you have no idea what the defaults are and the command line gets full using the pw command option flags.
The first thing you should do if you want to use the pw command to add users is to create the pw.conf file, do this by entering:
pw adduser -D # this will create the /etc/pw.conf file.
The comments in the file are self explanatory. You have to edit /etc/pw.conf to change the defaults. I changed the default group "guest" and the additional groups to "mail". Everybody has to belong to the "mail" group to use the sendmail server.
My /etc/pw.conf looks like this
#
# /etc/pw.conf - user/group configuration defaults
# Password for new users? no=nologin yes=loginid none=blank random=random
defaultpasswd = "yes"
# Reuse gaps in uid sequence? (yes or no)
reuseuids = "yes"
# Reuse gaps in gid sequence? (yes or no)
reusegids = "yes"
# Path to the NIS passwd file (blank or 'no' for none)
nispasswd =
# Obtain default dotfiles from this directory
skeleton = "/usr/share/skel/"
# Mail this file to new user (/etc/newuser.msg or no)
newmail = "no"
# Log add/change/remove information in this file
logfile = "/var/log/userlog"
# Root directory in which $HOME directory is created
home = "/home"
# Colon separated list of directories containing valid shells
shellpath = "/bin"
# Comma separated list of available shells (without paths)
shells = "sh","csh","tcsh"
# Default shell (without path)
defaultshell = "csh"
# Default group (leave blank for new group per user)
defaultgroup = "guest"
# Extra groups for new users
extragroups = "mail"
# Default login class for new users
defaultclass = ""
# Range of valid default user ids
minuid = 1000
maxuid = 32000
# Range of valid default group ids
mingid = 1000
maxgid = 32000
# Days after which account expires (0=disabled)
expire_days = 0
# Days after which password expires (0=disabled)
password_days = 0
pw adduser -D = create /etc/pw.conf file>
pw adduser tom -m -c tom brown # tom = userid,
# -m = create home directory
# -c = full name field
# use quotes to enclose large name
The password will be the same as the userid.
The user needs to use the passwd command to set their secret password.
pw deluser tom -r # -r = remove his home directory
pw showuser tom # display users entry in password file
pw showuser tom -P # display password info in human readable form.
pw showuser -a # display all entries in password file
pw addgroup networking # Add this new group
pw showgroup wheel # List all users in this group
pw modgroup wheel -M tom # Add user tom to group wheel
The pw subcommands can be written in reverse order:
adduser & useradd mean same thing.
#! /bin/sh
pw adduser tom -m -c testing -h 0 <<EOD
water
EOD
# water is the password to be assigned to tom
The passwd command is the usual way to change your own password as a user or another user's password as the superuser root. Follow the prompts issued by the command.
passwd tom
This is the what is presented to the screen.
Changing local password for tom
New password:
Retype new password:
passwd: updating the database
passwd: done
The chpass command is used to change user database info such as password, shells, and personal info (such as full name, phone number, etc.) as a user or another user's info as the superuser root.
chpass tom
There is a single user that stands above all others. The kernel gives user root special privileges over everything in the FBSD system. Apart from that, root is a user like any other. When you are logged in using your personal account, you may want to do something that requires the privileges of the root account. You can log out and log in again as root, of course, but there is a easier way: just use the superuser command su and respond with the password for the root user when prompted. Only users who belong to the group named wheel are authorized to use the su command.
FBSD, is a direct descendant of the multiuser system UNIX, and has inherited the underlining permission structure that FBSD uses for the control of sharing and managing requests for hardware devices, peripherals, memory, CPU time, files and directories. Everything FBSD manages has a set of permissions governing who can read, write, and execute the resource.
These permissions are stored as a 10 position control field.
The format of the permission control field, (from left to right) is
Position 1 values = d This is a directory
l This is
a link file
- This is
a file
The remaining 9 positions are broken into groups of 3 positions. The first group of 3 positions refers to the owner, the next group of 3 positions refers to the account group, and the last 3 positions refer to all other users. Any of the positions may hold a - dash which means no permission.
Position 2, 3, 4 = owner
Position 2 can contain an R means the owner has read access
- means the owner has no read access
Position 3 can contain a W means the owner has write access
- means the owner has no write access
Position 4 can contain an X means the owner has execute access
- means the owner has no execute access
Position 5, 6, 7 = account group
Position 2 can contain an R means the group has read access
- means the group has no read access
Position 3 can contain a W means the group has write access
- means the group has no write access
Position 4 can contain an X means the group has execute access
- means the group has no execute access
Position 8, 9, 10 - all users
Position 2 can contain an R means all users have read access
- means all users have no read access
Position 3 can contain a W means all users have write access
- means all users have no write access
Position 4 can contain an X means all users have execute access
- means all users have no execute access
Read permission: Enables you to look at a file or directory. You can use an editor to see the content of the file. You can copy this file. If it's a directory, lets you list content of directory.
Write permission: Enables you to change the content of the file and save it.
You need write permission to the directory to delete files or create new files.
Execute permission: Enables you to run the program or shell script
contained in the file.
You can use the ls -l command to view a long directory listing that displays the 10 position permission control field to the far left side of the listing.
For example, a ls -l /etc/
drwxr-xr-x 2 root wheel 512 Oct 9 2002 X11
-rw-r--r-- 1 root wheel 1340 Jan 7 2003 adduser.conf
lrwxrwxrwx 1 root wheel 12 Jan 9 2003 aliases -> mail/aliases
-rw-r--r-- 1 root wheel 65536 Jan 9 2003 aliases.db
-rw-r--r-- 1 root wheel 208 Oct 9 2002 amd.map
-rwxr-xr-x 1 root wheel 7183 Jan 7 2003 cvsupfile
drwxr-xr-x 2 root wheel 512 Jan 9 2003 defaults
-rw-r--r-- 1 root wheel 271 Oct 9 2002 dhclient.conf
-rw-r--r-- 1 root wheel 6990 Oct 9 2002 disktab
-rw-r--r-- 1 root wheel 478 Oct 9 2002 dm.conf
-rw-rw-r-- 1 root operator 0 Oct 9 2002 dumpdates
-rw-r--r-- 1 root wheel 142 Oct 9 2002 fbtab
-rwxr-xr-x 1 root wheel 832 Nov 10 13:13 fstab
-rwxr-xr-x 1 root wheel 1886 Jan 7 2003 gettytab
drwxr-xr-x 2 root wheel 512 Jan 9 2003 gnats
-rw-r--r-- 1 root wheel 477 Jul 9 18:14 group
-rwxr-xr-x 1 root wheel 1996 Jan 7 2003 newsyslog.conf
-rw------- 1 root wheel 1603 Oct 9 2002 nsmb.conf
Lets look closely at the first line in the above listing.
drwxr-xr-x 2 root wheel 512 Oct 9 2002 X11
The file and directory names are on the far right side. This is a directory, because the first position of the permission control field is populated with a d. The word root means the owner of the directory is root. The word wheel is the name of the account group. The permission control field says the owner root has read, write, and execute permission. The account group wheel has read and execute permission, and the same for all other users.
Lets look at one more
-rw-rw-r-- 1 root operator 0 Oct 9 2002 dumpdates
Here, this is a file, because position one of the permission control field has a -. Owner root has read and write permission, account group operator has same permission as owner root, while all other users only have read permission.
Root and members of the account group 'wheel' are the only users who have permission to change settings of files not belonging to themselves. The command chmod is used to change the permission settings in the permission control field. It accepts a 3 digit numerical number or a group of r's and w's as input. The 3 digit numerical number form of input is easier to understand and use. The 3 digit numerical number represents the 3 groups in the permission control field, one digit per category: owner, account group, and all other users. The permission digits are:
Digit Permission
0 None
1 Execute Only
2 Write Only
3 Write and Execute
4 Read Only
5 Read and Execute
6 Read and Write
7 Read, Write, and Execute
chmod 700 dumpdates
would assign owner read, write, and execute permissions, and account group and all other users get no permission.
An ls -l dumpdates would show this:
-rwx------ 1 root operator 0 Oct 9 2002 dumpdates
chmod 764 dumpdates
would assign owner read, write, and execute permissions, account group gets read and write permissions, and all other users get read only permission.
ls -l dumpdates would show this:
-rwxrw-r-- 1 root operator 0 Oct 9 2002 dumpdates
The chown command is used to change the owner. If my personal FBSD account name was joe and I wanted to change the owner of dumpdates from root to joe, I would use this:
chown joe dumpdates
The chgrp command is used the change the account group. If I wanted to change dumpdates group from operator to network, I would use this:
chgrp network dumpdates.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/10.11-Managing_your_configuration_changes.htm 000644 000000 000000 00000041270 10433404272 030641 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
Experience has taught me that it's a very good procedure to make a copy of all the configuration files you change during the process of configuring your FBSD system. You can copy them to a floppy for safe keeping just in case you happen to lose your hard drive where you cannot even boot from it or to install the next stable version of FBSD and populate it with your saved configuration files. My floppy containing only the changed configuration files has saved my butt before, and I highly recommend you do the same. You will be surprised at how few of the FBSD config files you really change during the process of installing your operating system and that they are mostly in the /etc directory. When you install ports or packages they also have config files that you may have to configure. Those files should also be saved. Then there are the password files, the group file and the log files you may have created to support new applications. I call these the primary config files which make your installation unique from all the other systems.
I find that having a single floppy that contains all the primary config files in a matching directory tree structure is very convenient when I install the next stable production release from scratch. All I have to do is copy the files from the floppy to their normal locations with one command and I have my basic system all configured.
Installer Note:
The concept presented here is just a skeleton directory configuration to convey how to set it up and use it. There will be other directories which contain configuration files. Its your responsibility to modify the /custom directory to contain these other directories and the backup and restore scripts so they work correctly with the additional directories you added.I create a directory named custom off the / base directory. Then make the directory tree inside it for the directories that contain the config files I change.
Follow these commands
cd / # point to the base of the FBSD directory tree
mkdir custom # create directory named custom
cd /custom # change into custom directory
mkdir root # create sub-directory named root
mkdir etc # create sub-directory named etc
Example: Following the instructions in the installer's guide you changed the /root/.cshrc file, so you would make your backup copy this way
cd /root # Change into the directory where the file lives
cp .cshrc /custom/root/
Here is some information you need to know about the copy command.
The cp command has mandatory fields that must be there for the command to work. The 'from location' and the 'to location'. In the above example you changed into the location where the file to be copied lives, so there was no requirement to give the path as part of the from location. As in:
cp /root/.cshrc /custom/root/
If you happened to leave the last / off the 'to location'
cp .cshrc /custom/root
then the file would be copied to the /custom directory and renamed as root. This was not what you wanted to do. As you see, the syntax of the from and to location is very important. Every time you change a configuration file, you have to copy it to the correct location in the /custom tree directory.
FBSD is a command line driven operating system. It's very hard to remember where all the config files are and what they are called. You have to be constantly working on your FBSD systems on a daily basis to remember all the commands you use to do repetitive things. I found that if I build a simple shell script and place the command I use, or the sequence of commands I used to perform repetitive tasks, I can give the script a long name that self describes what it does. All users have a bin directory which they can save their canned scripts in. The users bin directory is not created as part of the FBSD install so you must make one for root.
cd /root
mkdir bin
Now lets say for example I use IPFILTER for my firewall. I repeatedly edit the filter rules, load the rules, edit the NAT rules, and load the NAT rules. I simplify these admin functions by creating simple scripts with meaningful names.
ipf.edit.rules
ipf.load.rules
ipf.edit.natrules
ipf.load.natrules
Here is how to create simple script.
cd /root/bin
ee ipf.edit.rules
#! /bin/sh
ee /etc/ipf.rules
Close and save the file.
ls -l # will show you that this file only has read and write permission. It needs execute permission to run.
chmod 700 ipf.edit.rules # give it execute permission for root owner only
rehash # let the shell know about it
Enter ipf.edit.rules on the command line, and you find yourself looking at the screen displaying your rules file open and ready to edit.
Every time you want to create another script, copy an existing one and it will already have the correct permissions to execute.
#! /bin/sh
echo " "
echo "Script to copy /custom directory to floppy for bkup"
echo " floppy disk must be in drive first for this to work"
echo ' '
# Prepare the floppy to receive data
echo " "
echo "Deleting contents of floppy"
mount /a
rm -rfv /a
echo ' '
echo 'Copying custom to floppy'
cp -rpfv /custom/ /a/
umount /a
echo "Custom Image backup to floppy completed"
echo "and /a is unmounted"
#! /bin/sh
# script to restore FBSD SYS config files from custom bkup floppy
# to new fresh install of FBSD.
#
cd /
mkdir /custom # make custom directory
mkdir /a # make mount point for floppy drive
cd /root # root/bin is default search path for scripts
mkdir bin # Home of all custom scripts
echo 'Copying floppy custom to Hard Drive custom directory'
cp -rpfv /a/ /custom/
# copy custom files to there homes in FBSD
cd /
cp -rpfv /custom/etc/ /etc/
cp -rpfv /custom/root/ /root/ >
echo "CUSTOM RESTORE COMPLETED"
The FBSD handbook has a good section on creating CDs which gives a general overview. see:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/creating-cds.html
As FBSD releases each new stable production version to the public, they create install CD's. A compressed image .iso file is stored on the FBSD FTP mirror sites for people to download to their systems. This .iso file has to be written to a CD before it can be used to install the new version of FBSD on your system. The miniinstall.iso file is the smallest, because it does not contain any of the ports collection. It does contain everything necessary to install FBSD on your system. The .iso files are very large so you have to put it somewhere on your hard drive where you have room. Below is the pre-canned script I use to get the miniinstall.iso file. Notice that I am using the fetch program so the download can be resumed if an interruption occurs.
#! /bin/sh
# There is not enough disk space on the FBSD slice to hold the
# iso-image of the new FBSD miniinstall.iso version file.'
# so putting it in /usr where most of the free space is allocated
# replace the 4.10 with the version number you want to download
cd /usr
path="pub/FreeBSD/releases/i386/ISO-IMAGES"
fetch -avrAF ftp://ftp.FreeBSD.org/$path/4.10/4.10-RELEASE-i386-mini.iso
fetch -avrAF ftp://ftp.FreeBSD.org/$path/4.10/CHECKSUM.MD5
echo ' '
echo ' '
echo 'Run these steps to verify download is good'
echo 'ls -l to verify file sizes'
echo 'md5 4.10-RELEASE-i386-miniinstall.iso >> CHECKSUM.MD5 to create value & append to end
of file'
echo 'ee CHECKSUM.MD5'
echo 'second to last line = official hash value'
echo 'last line = downloaded file hash value'
echo 'if they do not match download again'
echo ' '
Be sure CD-writer drive contains a blank CDROM in it. For info on what the option flags mean, see 'man burncd' man page.
burncd -v -f /dev/acd0c -s 8 -e data /usr/4.9-i386-mini.iso fixate
FBSD is an all volunteer supported operating system. There is not any phone number to call to get technical support. The only avenue is the official mailing lists and the lists archives. See the following link for a list of the different mailing lists and instructions on how to subscribe to the mailing list of your choice.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL
The mailing list you should subscribe to is the FreeBSD-Questions list. Not only is it the list to ask your questions on, but it is the list most experienced users routinely read. It has the largest number of subscribers and has a large amount of traffic (IE: 30 to 100 posts per day). The volume goes up as new development releases are prepared to deploy as stable releases. You can learn a lot from just reading the posts for help and their replies.
When you need help with something you should first review the appropriate man pages on your system or use the online FBSD command lookup function for manual documentation on the command.
http://www.freebsd.org/cgi/man.cgiThen search the different list archives at
http://docs.freebsd.org/mail/archive/These official FBSD archives are not user friendly and do not have search ability.
has search ability, but it does not present the posts in thread form. Instead individual posts are displayed which is harder to navigate around.This is the search URL I use,
http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&group=lucky.freebsd.questionsIt uses the lucky.freebsd.question news group. Its only 8 hours behind the realtime activity on the FBSD questions list. It presents the answers to your search in thread format. Be sure to click on option to search within this newsgroup, or it will search all newsgroups which dilutes the results.
When searching the archives dont bother going back further than 24 months, generally information older than that is outdated as it does not reflect the current stable release.
When it comes time to submit a request for help to the questions list, the email subject line is the most important field to fill in when asking a question. Manny readers just blow right by any post that has blank subjects or subjects that have been covered in the list in the past few months. They know you have not done your homework. Always try to write the subject so its easy for the reader to understand what your question is about.
The general rule is you can never post to much information about your problem in the body of your email. Always say what FBSD version you are running, the age of the PC, and what hardware it uses. Post the full content of any config files that may shed light on your problem, like /etc/rc.conf, /var/run/dmesg.boot, firewall rules file, whatever. The more info you post the better the answer you will receive. Specially if you are a newbie and dont know the technical words to use, the more you describe the environment in your own words, the easier it is for the reader to comprehend what you are trying to say.
Nothing ticks off a responder to your post more than to see another post later from you where its obvious you did not try the responders solution. If you are not going to take the responders advance, you have no business posting to the questions list in the first place. You will be labeled as a troll and people will ignore your posts as background noise. You know the story about the sheepherder boy who called wolf.
When someone goes off list to work with you one on one, consider yourself privileged. When you have a solution that you have tested, its a courtesy to post the solution to the list using the original subject line so the next person can find it in the archives.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/11.00-Mail_Service.htm 000644 000000 000000 00000037657 10433404272 024002 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
FBSD provides email services with its built in SMTP server called sendmail. Sendmail has been the email server of choice by many commercial users for many years. It has the reputation of being hard to configure because of its large number of configuration options. There are books written just about configuring sendmail. FBSD has pre-configured sendmail's options so all sendmail needs to function is a domain name which it gets from the hostname= statement in rc.conf. Sendmail is an MTA (mail transport agent); its function in life is to listen on port 25 for inbound email originating from your LAN users or the public Internet. All email for users of its domain gets posted to the users sendmail mailbox. All email distined for domains on the public Internet gets sent out. Sendmail is the main post-office where the email is stored for all of the FBSD system defined users.
Sendmail defaults to disabled inbound connections from your LAN network. You have to add the following statement to /etc/rc.conf
sendmail_enable="YES"
If you want your LAN email clients to post their outbound email on the sendmail server then you need to enable it like above.
Sendmail can be configured to filter out spam and viruses. See Sendmail spam filtering
The second most popular email server is Postfix. It's know for it's ease of configuring. Postfix is in the FBSD ports collection. See Postfix spam filtering
The way sendmail receives its email from the public Internet depends on if you are a commercial user or not. Basically what determines that is how you are known to the public Internet. A commercial user has an always on, 24/7, permanently dedicated high-speed leased Internet line connecting them to their ISP and one or more static IP addresses assigned by their ISP. A static IP address is always the same number; it never changes between logins to the ISP. They have an official registered domain name that points to one of the static IP addresses which point to their gateway PC. Their email will arrive at the gateway PC and be processed by the sendmail server directly. Because a commercial users email server is online 24/7 the public Internet email always has a place to go. They do not use their ISP to receive and hold their email for them. They also have a POP3 server so their LAN users can retrieve their email from their mailbox on sendmail.
A non-commercial user, like the home user, uses a cable or phone line dial in login to their ISP on a limited speed connection and gets assigned a single dynamic IP address which changes every time they login. Their ISP receives and holds all their email for them. They use their email client software to fetch and send their email through the ISPs email servers. From the ISP viewpoint non-commercial users use a very small amount of its overall resources and so charges much less for a single user account. Most ISP's close the port numbers used by email servers and web servers to block their non-commercial users from hosting their own web site and email server, because the ISP wants to charge extra for those services.
A non-commercial user with or without a LAN can configure their gateway system to function like a commercial user in a limited way. Most ISP's block port 25 so your sendmail server will not be able to receive inbound email from the public Internet. All inbound email will go to your ISP's email servers. The gateway system can be configured to retrieve the users email from the ISP on a schedule and populate the sendmail server mailboxes. The gateway also needs a POP3 server so its LAN users can retrieve their email from their sendmail mailbox. Then the LAN PC client email software needs to be configured to retrieve the email from the gateways pop3 server and send their email through the gateway's sendmail server.
In addition, your sendmail server has to be configured to relay all outbound email to your ISP's email server. In today's world of spam, many ISP's do a port 25 challenge to the emails domain name to verify it's an authentic email server. Since most ISP block inbound port 25 for non-commercial accounts, your email will flagged as spam.
This involves a lot of unnecessary gateway configuration changes and the installing of two third party software applications.
All that is really necessary is to configure the LAN PC's email client software application to retrieve and send their email using their ISPs individual email accounts. That is the recommended method. Most ISPs allow 5 additional email accounts per each dial in access account, so this should not be a problem.
If you want to configure your email environment like a commercial user, then continue with the following steps.
cd /etc/mail/
On the command line, type: make
This will create some config files prefixed with the hostname you specified
in the rc.conf hostname statement.
ee <hostname>.mc
Locate the line in the file containing SMART_HOST.
Remove <dnl> from the start of this line to enable it.
In this line
replace <your.isp.mail.server> with the name of
your ISP's SMTP server name.
NOTE: make sure your quotes around the hostname are correct.
Save the file and exit.
Type: make && make install && make restart
This will compile the <hostname>.mc file, install it into sendmail,
and restart sendmail using this new config file.
Sendmail is only half of what is needed for a complete FBSD email solution. A pop3 or imap server is also needed. When a LAN user wants to retrieve his email from the sendmail email server, he uses his email client program which logs into the FBSD POP3 server, which in turns accesses the user's mailbox in sendmail, transmitting its contents back to the user. A POP3 server allows users to access their email using any (Post Office Protocol) POP3 client. Those of you who have configured Microsoft Outlook on Window98/ME/XP machines know that SMTP and POP3 servers are required.
Qpopper is the most widely-used server for the POP3 protocol (this allows users to access their email using any POP3 client). Qpopper supports the latest standards and includes a large number of optional features. It is normally used with standard UNIX/FBSD mail transfer agents such as sendmail or postfix.
For details see
http://www.eudora.com/products/unsupported/qpopper/index.htmlThere is a manual at
http://www.eudora.com/products/unsupported/qpopper/documentation.html that describes execution time override configuration file.The FBSD package of qpopper installs a very basic vanilla environment without any of qpopper's built in high performance options activated. Install the package and configure qpopper for high performance operation.
pkg_add rv qpopper
rehash
At the completion of the package install a message block is displayed that tells you to copy this statement into the /etc/inetd.conf file to activate qpopper.
You are not going to use that statement as is. You are going to add an option flag to it to enable qpopper to read a configuration option file so its high performance capabilities can be enabled.
Edit the /etc/inetd.conf and place the following pop3 qpopper statement at the front of the file after the info comments and just before the first FTP statement.
pop3 stream tcp nowait root /usr/local/libexec/qpopper qpopper -f /etc/qpopper.conf
Now create the qpopper override config file so it contains the following content:
ee /etc/qpopper.conf
# This is the qpopper configuration override file
#
# Mail statistics
# Write info message to log file every time user checks email.
# Uncomment for testing only
#set statistics = true
# Put qpopper in server mode for fast performance
set server-mode = true
# For security purposes do not announce banner showing qpopper version
set shy = true
# Turn on fast updates
set fast-update = true
# Turn off reverse lookup of clients IP address
set reverse-lookup = false
# Put qpopper messages in their own log file.
set log-facility = local2
Since you told qpopper to use local2 for logging in the qpopper configuration override file above, you now have to complete the logging environment.
Add this statement to /etc/syslog.conf:
local2.notice /var/log/qpopper.log
This log file does not exist, so you must create it.
touch /var/log/qpopper.log
Now you must set up log rotation. Add this statement to /etc/newsyslog.conf:
/var/log/qpopper.log 600 3 100 * B
You can change the log rotation triggers to whatever you want.
See man newsyslog for info on what they mean.
To activate the changes to /etc/inetd.conf you can reboot or bump the inetd task into re-reading /etc/inetd.conf by kill HUP pid. You get the pid (IE: process number) by listing the tasks with the ps ax command. Find inetd in the display and the pid number is the number in the left column.
To activate the changes to /etc/syslog.conf you can reboot or bump the syslog task into re-reading /etc/syslog.conf by kill HUP pid. You get the pid (IE: process number) by listing the tasks with ps ax command. Find syslogd in the display and the pid id is the number in the left column.
Installer Note:
All users defined on the gateway sendmail server system have to belong to the "mail" group, so the qpopper pop3 server can access the user's sendmail mailbox.
In Outlook click on tools/accounts/add/mail/ to enter a wizard that prompts you to fill in the following fields:
display name = whatever you want to be know by (next button)
email address = bob@fbsdjones.com (next button)
my incoming mail server is = pop3
incoming mail pop3 or imap server = 10.0.10.2
outgoing mail SMTP server = 10.0.10.2 (next button)
You can not use server names here because you do not have a private LAN DNS server to resolve the names to IP addresses, so you use the IP address of the LAN NIC in the FBSD gateway/firewall box.
Account name bob This is the LAN user's account name on the FBSD gateway box.
Password ****** This is the password for the above account name from adduser.
Check mark remember password (next button)
Click on Connect using my Lan (next button)
(finish button) and you return to the account window.
There will be an account named 10.0.10.2 showing. To give this account a meaningful name, highlight 10.0.10.2, click on properties and type over 10.0.10.2 with fbsdjones.com. (apply button) + (ok button). It should be marked as type = default; if not make it so by highlighting it and hitting the default button. Click the close button.
Now create a new email message using Outlook, and send it.
To bob@fbsdjones.com
Then click on send/receive to bring it back.
When you sent it, Windows talked to sendmail who received it and put it in bob's mailbox. When you told windows to retrieve the email it used pop3 protocol to talk to qpopper who looked in bob's mailbox, found the email and shipped it to the windows machine that requested it. If in the windows account, properties, advanced tab, delivery section, you check marked the 'leave copy on server' option, then that's just what qpopper did. If you did not have this option check marked them qpopper waited for Outlook to acknowledge it received all the email sent and then qpopper deleted the email from bob's mailbox in sendmail.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/11.06-Fetchmail.htm 000644 000000 000000 00000027031 10433404272 023323 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
To get email that is stored in your ISP mailbox waiting to be picked up and delivered to your user on your local FBSD box, you have to install another FBSD application. Fetchmail is a full-featured, robust, remote-mail retrieval and forwarding utility intended to be used over on-demand TCP/IP PPP connections. It supports every remote-mail protocol now in use on the Internet: POP2, POP3, RPOP, APOP, KPOP, all flavors of IMAP, ETRN, and ODMR. It can even support IPv6 and IPSEC. It may also be useful as a message transfer agent for ISP sites which refuse for security reasons to permit (sender-initiated) SMTP transactions for collecting email.
For the Fetchmail Reference Manual see
http://www.catb.org/~esr/fetchmail/fetchmail-man.html
The home page is at
http://www.catb.org/~esr/fetchmail/Fetchmail is commonly used to access your ISP email account using the pop3 protocol by logging into your ISP email server as you, retrieving the email, and delivering it to SMTP port 25 where the FBSD sendmail server is listening. Sendmail does not know the difference between this method or receiving public inbound email directed by a domain name, because in both cases email just shows up at its front door.
The fetchmail program is command line driven. By this I mean you can manually enter the fetchmail command on the FBSD command line any time you want get your email from your ISP account. It has a alternate mode of operation where you can tell it to start as a daemon to keep running and check email on a timed cycle. This is the customary way users configure it to function. You are going to put fetchmail in the root directory to make the startup of fetchmail at boot time. This is simple to accomplish during the manual configuration of fetchmail.
pkg_add rv fetchmail
rehash
After the package is installed, you are ready to manually create fetchmail's run time options file in the home directory of user root.
cd /root/
ee .fetchmailrc
set postmaster root
set no bouncemail
set no spambounce
# Example of fetching email from individual ISP email accounts and
# populating their sendmail server mailboxes.
# user statements show use of added readability words.
# Of course each ISP account has its own password.
poll mail.manbay.net, protocol pop3, no dns
user dadisp there with password xxxxxx is dadfbsd here
user momisp there with password xxxxxx is momfbsd here
user tomisp there with password xxxxxx is tomfbsd here
user bobisp there with password xxxxxx is bobfbsd here
# Example of fetching email from a multi-drop ISP account and
# populating the users sendmail server mailboxes.
# multi-drop means all the email for all of the users of registered
# domain name is forwarded to a single ISP account.
#
# If you are not doing this then delete this example.
# The poll statement option localdomains must be followed by the
# domain name sendmail thinks it's responsible for.
# From rc.conf hostname= statement.
#poll mail.manbay.net, proto pop3, no dns,
# envelope Envelope-To, localdomains yourdomainname.com,
# user dad0 there with password xxxxxx is * here
#
###################### End of File #####################################
postmaster is the account name of the user who will be the last-resort email recipient. root is a valid entry; It can be any user you want.
bouncemail & spambounce logical happened at the ISP so anything that fetchmail/sendmail thinks is wrong is really wrong, so 'no' means direct error email to postmaster.
The poll statement is the main control statement for specifying your target ISP and providing the account information to login and how your email is to be handled by fetchmail as it hands it off to sendmail.
Replace mail.manbay.com with the name of your ISP pop3 email server.
Replace tomisp with the account name of your ISP email account that you want to retrieve the email from.
Replace xxxxxx with the password of the ISP tomisp account.
Replace tomfbsd with the account name on FBSD you want the retrieved email put into. This is the account on the FBSD box where fetchmail will deposit the email it gets from your ISP.
For each ISP account that you want to retrieve email for and populate the users sendmail mailbox, just add another user statement following the same syntax.
Installer Note:
The FBSD account names you substituted for "tomfbsd" have to be created by adduser or pw before you use fetchmail.For security concerns you have to change the /root/.fetchmailrc file permissions to 600 (u=rw,g=,o=), on the command line enter:
chmod 600 /root/.fetchmailrc
In daemon mode there are no error messages coming out on the screen. They are going to the syslog facility named mail. The mail facility is also used by sendmail. The message level of mail.info posts an entry in the log for every time fetchmail is executed, which is every 5 minuets in daemon mode. This just fills up the log file with useless information. To correct this problem syslog.conf has to be updated. Change the mail.info statement so it look like this.
ee /etc/syslog.conf
mail.notice /var/log/maillog
To activate the changes to /etc/syslog.conf you can reboot or bump the syslog task into re-reading /etc/syslog.conf by kill HUP pid. You get the pid (IE: process number) by listing the tasks with the ps ax command. Find syslogd in the display and its pid is the number in the left column.
Set up fetchmail to automatically start up in daemon mode at boot time.
Create a script to start fetchmail at boot time.
ee /usr/local/etc/rc.d/fetchmail.sh
#! /bin/sh
fetchmail -d 300 --syslog
The -d 300 option says run fetchmail in daemon mode checking email every 5 minutes.
The 300 value is 5 minutes in seconds. You can change the interval to what ever you want, just as long you specify it in seconds.
The --syslog tells fetchmail to use the syslog facility.
The permission on this script file must be read, write, exec for owner root.
chmod 700 /usr/local/etc/rc.d/fetchmail.sh
You are now ready to perform your first test of fetchmail. On the command line enter:
fetchmail -v -c
The -v option creates verbose messages.
The -c option means just check my ISP email account and tell me how many emails are there. At this point you just want to see if you can log in to your ISP account.
Here is what the results should look like
fetchmail: 6.2.4 querying mail.manbay.com (protocol POP3) at Fri Mar 8
00:18:12 2002: poll started
fetchmail: POP3< +OK mail.manbay.com POP3 server (Post.Office v3.5.3 release
223 with ZPOP version 1.0 ID# 0-52377U2500L250S0V35) ready Fri, 8 Jan 2004
00:22:35 -0500
fetchmail: POP3> USER tomisp
fetchmail: POP3< +OK Password required for tomisp
fetchmail: POP3> PASS *
fetchmail: POP3< +OK Maildrop has 1 messages (6287 octets)
fetchmail: POP3> STAT
fetchmail: POP3< +OK 1 6287
fetchmail: POP3> LAST
fetchmail: POP3< +OK 0
1 message for tomisp at mail.manbay.com (6287 octets).
fetchmail: POP3> QUIT
fetchmail: POP3< +OK mail.manbay.com POP3 server closing connection
fetchmail: 6.2.4 querying mail.manbay.com (protocol POP3) at Fri Jan 8
00:18:16 2004: poll completed
fetchmail: normal termination, status 0
The above results will vary depending on what pop3 server software your ISP is using. If you did not receive something close to this you have problems. The last line status 0 is a return code. Status 1 means no mail to retrieve. See the fetchmail manual for the meanings of each status return code. The most common error here is you have an incorrect name for your ISP pop3 email server. If you are having problems logging in, call your ISP to verify your email account name and password and the email server name.
Enter on the command line one of these:
start daemon = fetchmail -d 300 --syslog
stop = fetchmail -q
start non-daemon = fetchmail -v
start check mail = fetchmail -v c
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/11.08-Email_Reading.htm 000644 000000 000000 00000037411 10433404272 024114 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
FBSD has a built in mail client application called mail. To put this in perspective, the mail command is FBSDs native version of the mail functions Microsoft Window users would think of as happening in Outlook. This client mail application is nowhere near as robust as Outlook. The basic mail subcommands necessary for you to work with your mail are covered. There are many other mail user agents (or UMAs) in the ports collection to chose from if you are going to use your FBSD system as a workstation. For the purpose of using your FBSD system as a gateway/firewall/email server/web server the built in email client application is more than adequate.
The mail client application is a very simplistic command line driven system that assigns a sequence number to each individual mail message in your mailbox. This email message number is the key to manipulating your mail.
There are two methods of targeting the email message you want to manipulate: the explicit and implied. With the explicit method you can jump straight to the message you want to manipulate by message number. The implied method means the mail subcommands you enter apply to the last message you just viewed. You can switch between the two methods seamlessly with out any problems.
When you are creating a new message or replying to one, the text you enter is in <input mode> meaning the only way to correct a misspelled word two lines back is to use the backspace key to erase everything you entered between your current position and the position you want to correct. There is a procedure to work around this <input mode> limitation. The mail application does not have a built in spelling checker.
Most users get their first introduction to the FBSD mail command when they logon to the FBSD system and receive the You have new mail message. Entering mail on the command line will bring up the mailbox content display showing a list of all the mail in your mailbox. This mailbox content display is refereed to in the mail application as the header list. It is the first 18 messages in your mailbox. You use the arrow keys to scroll through this list. If you have a lot of messages, use the + and keys to scroll through the following groups of 18 messages each.
At the end of the header display you will see a blank line that starts with an & (ampersand). This is the mail application's command line. Whenever you see this line you have the opportunity to issue commands to the mail application.
Normally you just hit enter and the first message in the header list will be displayed on your screen. Use the arrow or enter key to scroll through the message. When you reach the end of the message, the mail application command line is redisplayed. If you hit the enter key here, the next message will be displayed. If you hit the d key here, the message you just viewed will be deleted. If you hit the uppercase R key here, you will be able to reply back to the originator of the message you just viewed. If you hit the q key here, you will quit the mail system. All the messages you viewed will default to being moved from your MTA post office mailbox to the mbox file in your home directory. This is your archive file of viewed messages. All messages not viewed will remain in your MTA post office mailbox. All deleted messages vanish. A d * command before the quit command will delete all the messages in your mailbox.
There are four ways to create email messages. The most common is from the FBSD command line by entering 'mail user_account_name'. Mail will create a new email template using user_account_name as the targeted recipient of the message. Note: user_account_name can also be the complete email address of someone on the public Internet. The remaining three ways are from the mail system command line. You can enter the email user_account_name, or after viewing a message; enter uppercase R to Reply to the previous viewed message, or after locating the message number of the message you want to reply to in the header list; you can enter R message number. In all four cases a prompt line will return for a subject. Type in your subject title, then enter. The cursor returns with a blank line, and you are now ready to type in the body of your message.
If you want to include the contents of the implied previously viewed message into the body of your reply, you enter ~m on a blank line and hit enter, or ~m message number to include the contents of that message. The contents will be copied and inserted into the body of your reply beginning at that blank line and be shifted right by one tabstop from position 1 of the line.
Keep in mind that when entering text in the body of the message you are in <input mode>, meaning the only way to correct a missspelled word two lines back is to use the backspace key to erase everything you entered between your current position and the position you want to correct. If you let the line auto wrap for you, your message will be sent as one long line. You have to hit enter as you near the end of the line so it gets a carriage return to mark the end of the sentence. When you are finished, hit enter one more time so you have a blank line, then enter Ctrl + d keys at same time or use the period key followed by enter to end mail creation and send the email message.
An alternate method of entering the text for the body of the message that will allow you to use the arrow keys to edit text you have already entered is when you get the first blank line of your message body, enter ~e command to invoke your default editor. Now you have all the power of your editor to copy and paste text around and correct spelling anywhere in the text. When you are finished entering and editing your message text, exit your default editor and return to the mail application. You will still be in the mail enter text mode. Hit enter for the next blank line and enter Ctrl + d keys at same time to exit mail creation and send the message.
Sometimes you run out of time while composing your email. This mail application does not have a drift function where email in the process of being built can be saved & returned to at a later time. But, this function can be accomplished using the mail commands in this way.
When you're done entering the message body text for the time being, issue ~q command from the last blank line in the body text. This will save your message to your mbox file without sending it. Then exit the mail application issuing the q command. When you are ready to continue working on the unfinished message, issue mail f on the FBSD command line. This will start the mail application using the mbox file. Review the mailbox content summary list to find the message number of the message you want to return to. On the mail command line enter 'mail user_account_name. The user_account_name is the same one used to build the original message. When you get to the first blank line of the message body, enter ~f message number of the message you want to continue with. This will copy the complete message headers and text into the body of your current message. You will not be able to see the copied text so now enter ~e to go into your default editor. Now you can see the complete message text header and all. There will be duplicate headers which you will have to delete. When you're finished and ready to send, exit your default editor and return to the mail application. You will still be in the mail message enter text mode. Hit enter for the next blank line and enter Ctrl + d keys at the same time to exit mail creation and send the message.
When you use the mail subcommand quit or q to leave the mail application, mail writes all the viewed undeleted messages to the mbox file in your home directory and removes them from your MTA post office mailbox. This is your archive file of viewed messages. When you want to access these saved archive messages in your mbox, issue mail f from the FBSD command line. The mail application functions normally. It is just using a different mailbox file as source to the mail application.
When you quit by using the q key, mail writes undeleted messages back to this same file.
You can identify the mail application command line as the blank line that starts with the character & (ampersand). The following mail application sub-commands have both explicit and implied usages. If there are no more messages, mail says ``at EOF''.
? or help Displays a brief summary of commands.
headers (h) Display mailbox content screen. This is the current contents of the mailbox by range of headers, which is an 18-message group. If a `+' argument is given, then the next 18-message group is displayed, and if a `-' argument is given, the previous 18-message group is displayed. This display shows the message number of each message along with who the sender is, date & time it was received and the Subject.
n, numeric value of an explicit message number. Display that message.
hold (ho) Marks the viewed message to be saved in the user's MTA post office mailbox instead of being moved to the mbox archive file when the mail application is ended with quit command. Does not override the delete command.
delete (d) After viewing a message you can enter d to delete the previously viewed message. This is the implied usage of the command. You also could d 4 9 to delete message number 4 and message 9, or d 3-7 to delete messages 3 through 7. This is the explicit form of the command. Deletion causes the mail program to forget about the message. The special name `*' addresses all messages, and `$' addresses the last message, thus the command d * will delete all messages in the mailbox. This is not irreversible until you quit the mail application using the q command, after which the deleted messages disappear never to be seen again. The messages can be undeleted (u) by giving its message number, or the mail session can be aborted by giving the exit (x) command which will nullify the delete action.
Undelete (u) Takes an explicit message number or range of message numbers and marks each message as not being deleted. Note: This is a lower case u. u 5 or u 3 5 7 or u 4-23
unread (U) Takes a explicit message number or range of message numbers and marks each message as not having been viewed. Note this is an upper case U. U 5 or U 3 5 7 or U 4-23
quit (q) command ends the mail application. Messages which have been viewed go to the mbox file in your home directory. This is your archive file of viewed messages. Messages that have been deleted are discarded. Unviewed messages and messages marked with hold stay in your mailbox in the MTA post office. If new mail has arrived during the session, the message ``You have new mail'' is given upon return to the FBSD command line. If issued while using the mbox file (mail f), then the file is rewritten to the mbox minus all deleted messages.
exit (ex or x) Effects an immediate return to the FBSD command line without modifying the user's MTA post office mailbox or mbox file. This nullifies all deletes and returns the mail box back to its original content condition before the mail command was issued.
edit (e) Takes an explicit message number and opens your default editor so you can edit the complete text of that message. On exit from the editor, the message replaces the original in the mailbox with the edited version.
Reply (R) Note thats an uppercase R. Reply to originator, IE: the email address in the From: field. Does not reply to other recipients of the original message. This creates an empty message body for you to enter your reply message into.
While you are entering text into the body of the message, mail treats lines beginning with the character `~' as a command line. For instance, typing `~e' (alone on a line) will invoke the default text editor on the message built so far. Other ~commands will set up subject fields, add and delete recipients to the message and allow you to shell out to run some commands.
Some of these options are given in the summary below.
~e Invoke the text editor on the message built so far. After the editing session is finished, you may continue appending text to the message.
~f Copy the named messages into the message being sent. If no message number is specified, copy in the previously viewed message. You get headers and all text.
~m message number. Copy the numbered message body text into the message being built, indenting by one tab to the right. If no message number is specified, use the previous viewed message as the copy source. Message headers are not included.
~q Abort the message being built, do not send, and move the message to mbox in your home directory.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/11.09-Email_Vacation_Command.htm 000644 000000 000000 00000024176 10433404272 025752 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
FBSD has a vacation command that is built into the FBSD system. It comes enabled as part of the base FBSD system. Vacation auto replies a canned message to the sender of a just received email message telling them that you are currently on vacation and not reading your mail. The vacation command really has nothing to do with being on vacation. It uses the standard mail forwarding facility to get control every time an email is received for the user, and if this is the first message it has received from that sender it sends a reply message back to the sender. Your can have the canned reply message say anything you want. This auto reply function can be used for many other reasons than telling the sender you are on vacation.
See the man vacation page for details.
The vacation command is inserted into the control statement of the standard .forward file of the users home directory. A .vacation.msg file contains the content of the auto reply email message. The .vacation.db file controls the issuing of one vacation auto reply per unique sender email address per reply interval. In FBSD, the normal user account will not show the .files in the home directory.
To see them use the ll command.
When your MTA (sendmail or postfix) goes to put email in your mailbox it checks your home directory for a .forward file. It finds the forward command with vacation in it and executes the vacation program. No auto reply will be sent for any emails that have their "From:" header containing "???-REQUEST", "???-RELAY", "???-OWNER", "OWNER-???", "Postmaster", "UUCP", "MAILER", or "MAILER-DAEMON"' or if "Precedence: bulk" or "Precedence: junk" line is included in the mail headers. All these values are case insensitive.
Vacation then reads the emails "To:" and "Cc:" headers looking for a match to the login value it was passed or the -a values. On a match the .vacation.db file is searched to see if the sender email address has already been sent a reply. On a match no reply is sent. On a not found, the sender's email address is added to the .vacation.db file database and the auto reply message is sent.
Vacation expects a .vacation.msg file in your home directory containing the message to be sent back to the sender. You have to create this file by hand. The content of this reply message does not have to be vacation related. It must be an entire email message (including headers). For example:
From: bob@fbsdjones.com
Subject: Auto Responder
I am on vacation until July 22 2005.
If you have something very, very urgent, email
my Boss at king@fbsdjones.com.
Vacation expects a .vacation.db file in your home directory. You use vacation -i from the FBSD command line of the logged in user to activate the vacation facility.
vacation i This will create the .vacation.db file and post today's date as the start of the default 7 day auto reply interval.
vacation -i -r 14 would set the duration interval to 14 days, starting today, after the interval has expired the auto reply will stop.
vacation -i -r 0 will auto reply indefinitely, IE: has no interval trigger to stop the vacation auto reply function. The .vacation.db file can grow until it consumes all your free space on your hard drive, so issue vacation -i -r 0 once a week or monthly using a cron job to clear out and reset this file.
vacation -l will list the contents of the .vacation.db showing you a summary of who and when auto reply sent your .vacation.msg out.
Vacation expects a .forward file in your home directory. You must create this file by hand. The control statement in this file complies with the syntax of your MTA (sendmail, postfix). The normal coding of the control statement is like this:
\eric, "|/usr/bin/vacation eric"
The \eric, "|/path/program " is standard MTA .forward syntax.
The "/usr/bin/vacation eric" part points to the location where vacation lives and eric is the value being passed to the vacation program.
The user would replace both occurrences of eric in the above command with their login account ID.
vacation [-a alias] [-d] [-i] [-l] [-r interval] [-s address] login
-a alias Handle messages for alias in the same manner as those received for the user's login name.
-d Send error/debug messages to stdout instead of syslog. Otherwise fatal errors, such as calling vacation with incorrect arguments or with non-existent logins, are logged in the system log file using syslog(8). This should only be used on the command line, not in your .forward file. All syntax errors are displayed on the root console screen no matter who the user is that is using the .forward file containing the vacation command.
-i Initialize the vacation database files. It should be used before you modify your .forward file. This should only be used on the command line, not in your .forward file.
-l List the content of the vacation database file including the address and the associated time of the auto-response to that address. This should only be used on the command line, not in your .forward file.
-r interval Set the reply interval to interval days. The default is one week, 7 days from the day you use the i option on the .vacation.db file. An interval of ``0'' or ``infinite'' (actually, any non-numeric character) will auto reply indefinitely. The -r option should only be done when the vacation database is initialized (see -i above).
-s address Use address instead of the incoming message sender address on the From line as the recipient for the vacation message.
login Mandatory field in the vacation command of the .forward control statement. This tells vacation who the user is. These must be the last characters before the double quotes that end the control statement. All - options must come before the login value. This value must be the users login account name.
The user who wants to active the vacation responder logs into his FBSD account. In this example that would be user bob. Then bob has to manually create two files, the .forward and the .vacation.msg files.
Create the .vacation.msg file and make it look something like the following:
ee /root/.vacation.msg
From: bob@fbsdjones.com
Subject: Auto Responder
I am on vacation until July 22 2005.
If you have something very, very urgent, email
my Boss at
Now create the .forward file:
ee /root/.forward
\bob, "|/usr/bin/vacation bob"
If the 7 days default life time for the auto responder to function is ok then you are done. If you need a longer period, then issue the vacation command to set a longer period like this for an auto reply interval of 14 days
vacation -i -r 14
During the auto reply interval you can disable it by commenting out the vacation statement in the .forward file.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/12.00-Ports_packages.htm 000644 000000 000000 00000051234 10433404272 024371 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
The 3rd Party Software Applications Collection.
FBSD has a very large collection of over 10,100 Unix flavored software applications which have been 'ported' (IE: converted) to install and run on the FBSD system. The ports collection is constructed using five small config files for each software application port. These config files contain all the necessary information to allow your system to automatically download, unpack, patch, compile, and install the port. Downloading these config files does not install the actual port program. After downloading the port's config files, you have to change into the directory structure on your system where the port you want to install has its port config files located and then issue the 'make install clean' command to really install the port. The FBSD documenters of the port application used the brute force method in the design of how they tell you to manage the ports collection on your system. Their recommended method entails the downloading of all the 5 small config files for each of all the 10,100 ports available. This may consume all your hard drive disk space and on a slow Internet connection take so long that your download task gets suspended or timed out by the FBSD ports FTP server. The ports applications are grouped into categories, and you can bypass categories you have no interest in. But even doing that, most categories still contain hundreds of applications. The shortcuts that eliminate this brute force approach are absent from the official documentation.
The brute force approach is not covered here, only the shortcut approach that results in only downloading the config files of the selected ports is covered.
To simplify the ports collection and eliminate the huge disk storage requirements while also drastically reducing the download bandwidth requirement, a large percent (96%) of the ports have been pre-installed and converted into packages. The ones which are not made into packages have technical or legal license restrictions about distribution of binary versions. Installing a package version of a software application does not require any resident config files or compiling. It's just a matter of the package loading the pre-compiled binary execution modules to their directory locations on your running system. Even the downloaded package is deleted after it installs itself. If the packaged software application depends on one or more other software applications to function, the packaged version of those dependents will be automatically downloaded and installed if they are not already on your system. This is definitely more convenient, uses much less disk space, and most important, the download is smaller and quicker on dial in type of Internet connections.
So really the 3rd Party Software Applications Collection is maintained in two separate collections, the ports collection and the packages collection. The cvsup program is used by the ports collection to control the selection and downloading of the config files, and then the 'make' program does the actual install. The 'pkg_add' program is used for the package collection to select, download, and install the desired package.
Installer Note: Lets be absolutely clear what the FBSD 3rd Party Software Collection is comprised of. When a complete software application, or some special purpose code, or some new function to a member of the current 3rd Party Software Collection is found on any of the other license free Unix flavored operating systems or from any of the Unix shareware development sites, the volunteer members of the ports team create the FBSD five port config files necessary to install that item on a FBSD system. The problem with this process is that there is no documentation generated by the individual creating the port config files on what the intended purpose is, how to use it or configure the software the port delivers. After you cvsup download the ports config files and install it on your system, its just there and its up to you to try to figure out from where to use it and just what its suppose to do. The FBSD 3rd Party Software Collection is not a library collection of professional grade software. Its a collection of legally contributed bits and pieces of code, and in some cases complete applications which have their own separate maintenance team and documentation totally unrelated to the FBSD project. Some of the ports you see with massive dependency lists are really pre-configured desktop environments for the x-graphical server. Even the fact that this is what the port is, is not even expressed in any way. This lack of an informative narrative overview on the majority (IE: 95 percent) of the 10,100 members of the 3rd Party Software Collection leaves many a person totally confused as to what to do next. This is just another symptom of the lack of standards and enforcement common to an all volunteer organization. The only way to fix this problem is when you figure out how to configure and use the port, you should write your own narrative overview synopsis of 300 words or less and then submit a port problem report requesting your included synopsis to be added to the ports description or comments config files.
http://www.freebsd.org/send-pr.html
With 10,100+ 3rd Party Software Applications to choose from, the task of finding the correct Software Application that meets your needs can be a very hard task indeed.
The FBSD online web site provides three aides to help you in your quest.
1. An application name search by FBSD release distributions
http://www.freebsd.org/cgi/ports.cgi
2. A category index with application name search
http://www.freebsd.org/ports/index.html3. And the alphabetic list in internal name order of the latest versions
http://www.freebsd.org/ports/master-index.htmlThe overall collection is just so darn large, and even some of the categories are so large it's just such a hard task navigating around looking and reading descriptions, that a person becomes overwhelmed. I found it's easier to ask a question on the FBSD questions mailing list describing what I wanted to do or what I was looking for, and have somebody recommend an application. With an application name in hand, I used one of the tools above to drill down into the listing of the collection, looking to see what other similar applications are out there around the individual application I an interested in.
Once you find an application you want to install, you have to find its download name that is used by cvsup for the ports collection and by pkg_add for the package collection. All of the three FBSD online web site aides display the internal application name with its version suffix and this misleads the reader into using it as the application name, which is incorrect.
Example: I am interested in the Apache server application and from the response I received from the questions list I know its in the WWW category. Using the FBSD online web site aide
www.freebsd.org/cgi/ports.cgi I do the following:Enter the word apache in the search argument box on the far left.
In the distribution box on the right just before the search button, I use the pull down arrow and select the 4.10-RELEASE/i386 to identify my FBSD system, because this is the release distribution pkg_add defaults to using.
Click on the search button to launch the search.
The search returns a display of every application where the word apache was found grouped by category. The results show me all the applications that are in any way related to apache, most are extensions, add-ons, or plug-ins, until you come to the WWW category. This is what is displayed for apache-1.3.29_1.
apache-1.3.29_1
The extremely popular Apache http server. Very fast, very clean
Maintained by: ache@freebsd.org
Requires: expat-1.95.6_1
Description : Sources : Changes : Download
The Description : Sources : Changes : Download line contain links.
Click on the Description link and another display comes up.
The heading of the display says Port description for www/apache13
WWW is the category and apache13 is the download name which is used by both the ports and package collections.
You can see that our apache example requires one other application to function, indicated by the 'Requires:' field.
The package system will automatically download and install all the interdependencies for you.
If you chose to use the ports system, you need to click on the required dependent link and it will show you its details. Then click on its Description link to get its category and download name. Sometimes dependents have there own dependences. You have to insure that all the interrelated dependenices have their port config files downloaded by cvsup before you start installing the parent port you selected. You should be writing down the category and ports download name for the port you want and all of its dependents and their dependents, you will need it later when you go to build the control statements to tell cvsup what config files to download.
You are beginning to see that there is a lot of prep work to installing only port config files for the ports you want. This is why many people just select the complete category and download all the config files so they do not have to mess with the manual research to determine the interrelated dependencies and download their config files. They trade off disk space, longer backup times, and consumed bandwidth for being lazy. It's really up to you how you do it in the end.
You should also realize from this explanation just how convenient the package collection is to use.
A compressed package tarball file is much smaller than the compressed tarball file containing the source code for the application.
Packages do not require any additional compilation. For large applications, such as Mozilla, KDE, OpenOffice or GNOME this can be very important, particularly if you are running on a PC with legacy CPU megahertzs speeds (IE: less than 800 megahertz).
Packages do not require any understanding of the process involved in compiling software on FreeBSD.
Packages do not require the downloading and permanent inventory on your system's hard drive of the five separate mandatory config files per application and their interrelated dependences config files.
Packages by their very nature are appropriate for users who have 56K modem access to the Internet.
Packages are for users who have no interest in or lack the ability to read or hack the source application code.
Some applications have other applications which are add-ons or plug-ins that add additional functions to the base application. For example, Apache can be configured with a wide variety of different add-on functions. By building from the port you do not have to accept the default install options, and can set them yourself.
In some cases, multiple packages will exist for the same application to specify certain settings. For example, GhostScript is available as a GhostScript package and a GhostScript-nox11 package, depending on whether or not you have installed an X11 server. This sort of rough tweaking is possible with packages, but rapidly becomes impossible if an application has more than one or two different compile time options.
The licensing conditions of some software distributions forbid binary distribution. They must be distributed as source code.
Some people do not trust binary distributions. At least with source code, you can (in theory) read through it and look for potential problems yourself.
If you have local patches, you will need the source in order to apply them.
Some people like having code around so they can read it if they get bored, hack it, borrow from it (license permitting, of course), and so on.
Installer Note:
The pkg_add r command uses the fetch command which is really a wrapper for the FTP command. It defaults to using FTP passive mode. Its a mandatory requirement that your firewall rules allow the FTP port 21, and FTPs passive data port > 1024, bi-directional access to the public Internet. Otherwise you will never be able to use the package collection.The pkg_add command is used to fetch and install a package. The command syntax is
pkg_add -rv xxxxx
Where xxxxx is the download name you retrieved above. The -r means to fetch from the remote FBSD ftp server, the 'v' means to be verbose in displaying messages about what is happening. For example:
pkg_add -rv apache13
This command will fetch the requested package from the remote FTP server, download the package file to a temporary location on your system, determine if it has dependences and first download and install them in correct order, then execute itself to move the execution binaries to the proper locations in the directory tree, and then remove its downloaded package file and all its temporary work files.
After installing a package you have to issue the 'rehash' command which tells your shell to scan through all the /bin directories defined in your /root/.chsrc file path statement looking for new unknown programs or scripts and build an entry in its internal hash table of available commands for it. Remember this command, as you will have to use it after every port or package install.
rehash
When you use one of the FBSD online aids to search the third party software application collection you are always shown the official name with the version suffix. For some unknown reason the pkg_add command does not use this name, but instead uses a name which does not have the version suffix.
The pkg_add command defaults to using a directory path that targets the Latest directory. This directory contains the names on all the 10,200 packages without the version suffix, and its massive size makes it almost impossible to manually verify the name by FTPing there by hand. The package FTP site also maintains a directory tree structure of all the categories containing package names with the version suffix which are really links back to the All directory, which is where the package really lives.
I have found it much more convenient and reliable to use the pkg_add environment variable PACKAGESITE to change the default path location to use the category directory structure and the official package name with its version suffix that is easily found by the online aids. This makes it much easier to manually verify the name by FTPing there by hand, because the target category only contains the names belonging to that category and not all 9,600 packages. Another benefit is the directory packages is linked to packages-4-stable which contains more current versions of the packages.
setenv PACKAGESITE ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages
echo $PACKAGESITE will display the contents of the variable.
The pkg_add command will now use a different format:
pkg_add rv /category/full-official-name
So using the official package name for apache you would enter:
pkg_add rv /www/apache-1.3.29_1
After setting the environment variable PACKAGESITE, it only stays enabled for the duration of your login session. Its best to set this permanently.
Edit /root/.cshrc and add the following setenv statement to make this permanent.
setenv PACKAGESITE ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages
Log off and log back on to enable your changes.
Any time you want to temporarily disable this Alternate Access method, just edit your /root/.cshrc file and comment out the setenv PACKAGESITE statement, and logoff and log back on.
For a non-permanent, one-time temporary use of a different directory path,
you can use this form of the pkg_add command.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/12.06-Using_the_ports_collection.htm 000644 000000 000000 00000051400 10433404272 027014 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
Installer Note:
The cvsup command uses the tcp port 5999. Its a mandatory requirement that your firewall rules allow the tcp port 5999 bi-directional access to the public Internet. Otherwise you will never be able to use the ports collection.Before you can do anything with the ports collection you have to install the cvsup program on your FBSD system. The cvsup program handles accessing the ports cvsup server and the in mass downloading of the config files for all the applications in a category of the port collection you selected. It's also used to download the current source code that comprises the FBSD operating system when you want to do an operating system upgrade in place. For some unknown reason the basic FBSD install does not come with this very important program bundled in.
You can download and install the package version of cvsup with this command. Be sure your firewall allows passive FTP access to the public Internet.
pkg_add -rv cvsup-without-gui
rehash
Configure the cvsup control file. There are examples of different cvsup control files you can use. To see them:
cd /usr/share/examples/cvsup/
ls
Now copy this one to customize and use
cp ports-supfile /etc/
ee /etc/ports-supfile
This file has loads of comments at the beginning. You can delete all those comments until you come to this line:
*default host=CHANGE_THIS.FreeBSD.org
Replace the 'CHANGE_THIS.FreeBSD.org' with a real mirror site name.
See
http://www.freebsd.org/doc/handbook/mirrors.html for a complete listing of mirror sites. The statement should look something like this:*default host=cvsup1.us.FreeBSD.org
Leave the rest of the *default statements as is and look for this statement:
ports-all
This statement means you want to download the complete ports collection. Just look a little further down into the file and you will see all the categories this statement will download. You really don't want to do this!
Comment out the ports-all statement and uncomment the ports-base statement, because it contains all the behind-the-scene makefiles and the ports index file, all of which are mandatory for the cvsup ports collection to function on your FBSD system.
Execute the cvsup program to download the ports-base category config files:
cvsup -g -L 2 /etc/ports-supfile
The -g option means no GUI interface, the -L 2 means list verbose level 2 and /etc/ports-supfile points to the cvsup config file to use.
If you get a message 'Connection Refused' hit ctrl and 'c' keyboard keys at same time to terminate cvsup, because the server is busy right then. Re-edit the ports-supfile file and change the number in the server name to try a different server until you find one that is available, or use this format of the command:
cvsup -g -L 2 -h 'cvsup7.us.FreeBSD.org' /etc/ports-supfile
After this completes, issue the 'rehash' command to enable all the functions downloaded as part of ports-base.
There is no mandatory requirement to populate your system's hard drive with config files for the whole complete 10,200 ports collection, or even to populate your system's hard drive with config files for a complete category. All you really need is the port config files for the single port you want to install and any ports it depends on to function, if any. Some ports have a whole lot of dependencies.
You should have already created your list of port download names and their categories as instructed in Finding the Application Download Name Section.
So following our example we have www/apache13 and its dependents textproc/expat2 and devel/libtool13.
Edit your /etc/ports-supfile file:
Be sure all the ports-whatever statements are commented out except for the port-www, port-textproc, and port-devel statements which should be uncommented.
Use this format of the cvsup command to download only config files for the selected ports:
cvsup -g -L 2 -i ports/www/apache13 /etc/ports-supfile
cvsup -g -L 2 -i ports/textproc/expat2 /etc/ports-supfile
cvsup -g -L 2 -i ports/devel/libtool13 /etc/ports-supfile
or this format which does the same thing with one execution of the cvsup program:
cvsup -g -L 2 i ports/www/apache13 \
-i ports/textproc/expat2 \
-i ports/devel/libtool13 \
/etc/ports-supfile
At the completion:
cd /usr/ports # change into directory
ls -l # long list of directory contents
cd www/apache13 # change into directory
make install clean # Install the port
This last command will read the apache port config files; determine it has dependecies to install first: download the expat2 dependent libtool13 distribution source file, compile and install it; then download the expat2 distribution source file, compile and install it; and then download the apache13 distribution source file, compile and install it; and finish up by posting them as installed into the ports/package install history database. During this process you will see massive messages roll off your screen. There is no log to review later if there is a problem installing.
What I do to create a log of the install process; is start the script program to capture everything displayed to the console screen to a file for later review before issuing the make install command. You do that like this:
script /root/apache.install.list # you can name the file anything you want
exit # exit to stop script recording.
I also like to run the 'make install clean' command on each of the dependent ports manually, starting with the lowest dependency, so I have individual install logs for each one instead of letting the primary port do it all for me automatically. This helps greatly in limiting the scope of debugging install problems.
Installer Note:
Using the cvsup process presented above only positions you for the initial install of your selected ports. After a time you may be interested in checking if your installed collection has updated versions available. To do that you have to download the ports-base category to get a current INDEX file, followed by the use of the pkg_version command. If you find installed ports that have an updated version available that you want to make your system use, you will have to download that ports config files again to get the current port config file's content. Then delete the installed port binary execution files using the pkg_delete command and run the make install clean command on the selected port. For convenience you may want to save the cvsup commands you used during the creation of your initial port config file inventory in a file /etc/cvsup.cmds so you can use it to update all your port config files in mass some time in the future. You will have to do some manual editing of the files contents to create a command stream that will execute correctly, but at least you will have all the i statements for all your ports so you will not have to do all that research work again. An alternative is to use the following script as a template, making the appropriate changes for each port application you want, naming the script with a name that identifies its purpose and saving it to /root/bin, so you can use it in the future to update the ports config file contents.
The following script is an example of a method to further simplify the port config downloading process. It packages the whole process into a script which you can name and save in /root/bin.
ee /root/bin/port.apache13.cvsup
#! /bin/sh
# This script downloads the port config files for Apache13
# and all its dependencies.
echo ' '
echo 'port.apache13.cvsup script processing starting '
echo ' '
# Load script symbolic field with path & file name
cvsupfile=/root/temp.cvsupwork.file
# Check to see if file exists & delete it if it does
[ -e "$cvsupfile" ] && rm -f "$cvsupfile"
# Load instream data to file until EOD line.
cat >> "$cvsupfile" <<EOD
*default base=/usr
*default release=cvs
*default delete use-rel-suffix
*default host=cvsup11.FreeBSD.org
*default tag=.
ports-www
ports-textproc
ports-devel
EOD
# Display contents of loaded file to screen for testing
#cat $cvsupfile
# DO the cvsup to download just the selected port config files
cd /usr/ports/
cvsup -g -L 2 i ports/www/apache13 \
-i ports/textproc/expat2 \
-i ports/devel/libtool13 \
"$cvsupfile"
# Delete file we are done with it
rm -f "$cvsupfile"
echo ' '
echo 'port.apache13.cvsup script processing completed '
echo ' '
You will have to issue the chmod command to make the script executable.
chmod 700 /root/bin/port.apache13.cvsup
There are five package commands; two are specific to the package applications and the remaining apply to both the installed ports and installed packages. I am not going into details about the commands, because the man pages are pretty clear and easy to understand. Where xx is the port/package name.
pkg_add xx # Fetch package from server and install it,
# or install package you created from port.
pkg_create xx # Create package out of port you have installed
pkg_info xx # Create list of installed ports and packaged on your
# system from the installed software history database.
pkg_delete xx # Delete installed port or package. Uses the name
# from the pkg_info list display.
pkg_version xx # List version info about installed software from
# installed software database. This command compares
# packages version and port versions to the
# /usr/ports/index file to determine if they are out
# of date. For
an installed package only environment
# the index file has never been downloaded, so
# this command has no relevance. For installed ports
# environment the ports-base category has to be
# recently downloaded to get
a current /usr/ports/index
# before this command has relevance.
pkg_info xx\* # To find out which
packages/ports are dependent on it.
The 'man make' info is not the correct place to look for the 'make
sub-commands' for installing ports. Instead use the 'man ports' page instead. It's
very important that you understand that for the make command to be successful,
all the config files for all the dependencies and all their dependencies have to be
on your systems hard drive in the correct directory tree layout. If you missed
downloading one of the sub-dependency's config files then the parent port does not
know it's missing and you will get compile errors for something missing.
You must cd into the directory of the port you want to install before
executing any of the following commands.
make install # Normal way to install port
make install clean # Remove the expanded source code,
# including the
dependencies at completion
make install distclean # Remove expanded source code &
# distribution files, including the
#
dependencies at completion
make all-depends-list # List all dependent ports
make fetch # This will fetch the distribution file
make fetch-recursive # This will fetch all the distribution
# files of the port and for all its
# dependencies.
make checksum-recursive # This will fetch all the distribution
# files of the port and for all its
# dependencies and checksums them.
You must cd into the /usr/ports directory before executing the search commands.
The make search command reads the /usr/ports/INDEX file for the search argument. Its imperative that the INDEX file is current and up to date with the INDEX file on the FBSD cvsup server. You have to cvsup the ports-base category to download the current INDEX file. The INDEX file does not contain the download port names. It contains the port names with the version suffixes. The search option displays all the port's dependencies. You will have to search on the named dependencies to find if it has dependencies or not. This is a good way to acquire the info needed to verify you have all of the primary port's interdependences coded in cvsup commands before trying to download all the ports config files.
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/13.00-Kernal_customizing.htm 000644 000000 000000 00000026777 10433404272 025312 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
The kernel that comes with the FBSD install includes device statements for many of the most common devices on the market. It's very general on purpose so it will work for the majority of PC hardware configurations in public use. It's a rare occurrence when a FBSD system user never builds a custom kernel to fix problems or adds functions or hardware unique to their needs. Building a custom kernel is a normal process in the life of a FBSD system. If nothing else, just removing all the devices your particular system does not use will decrease the size of the kernel module causing it to load faster at boot time. As part of the basic FBSD install, FBSD provides a copy of the kernel source used to build the running kernel named GENERIC. Another kernel source named LINT contains all the kernel configuration statements with comments that are allowed in the kernel. The LINT file is your reference place where you would look for configuration statements for hardware devices or kernel options not in the GENERIC file. Please note the spelling of the names of these two files, Their names are in capital letters, and that's the way their file names are really spelled in the directory where they live.
Do not edit GENERIC directly, as it may get overwritten the next time you CVS update your kernel source and your kernel modifications will be lost. The GENERIC kernel config file lives in a directory which is five sub-directories deep. This becomes such a pain in the butt, typing in this long path every time you want to edit your custom kernel file. Your custom kernel config file is a very important element of your FBSD system. It should really live in the /etc directory with the other FBSD config files for easy backup. There is no reason your custom kernel config has to live in the same directory with GENERIC. It's a good idea to name your custom kernel config file after your machine's hostname= statement in rc.conf. You should call the new customized kernel config file 'gateway'.
Follow these instructions
cd /usr/src/sys/i386/conf # point to correct directory
cp GENERIC /etc/kernel.gateway # copy and rename to whatever you want
ln -s /etc/kernel.gateway # create a link to its new home
ee /etc/kernel.gateway # edit your kernel source
Edit your gateway file making the changes you want. Feel free to change the comment lines at the top to reflect your configuration or the changes you have made to differentiate it from GENERIC.
You must execute all of the following commands under the root account or you will get permission denied errors.
1. Change into this directory location (mandatory)
cd /usr/src/sys/i386/conf
2. Run config program against kernel.gateway to generate the kernel source code.
/usr/sbin/config kernel.gateway
3. Change into the build directory.
cd ../compile/kernel.gateway
4. Issue compile commands
make depend # When this completes then issue next command
make # When this completes then issue next command
make install # When this completes reboot to enable new kernel
Or combine all the single commands into one command line so all the make steps will run one after the other.
make depend && make && make install
As part of the "make install" process the current /boot/kernal/ directory is renamed to /boot/kernal.old/ then a empty /boot/kernal/ directory is populated with the new kernal files. Now, reboot the system to use your new kernel.
FBSD only maintains the current kernel; in the default directory location /boot/kernel/, and the previous kernel; in the /boot/kernel.old/ directory location. After completing your first successful kernel compile the /boot/kernal.old/ directory holds the generic version of the kernel. It's common practice to make a copy of it to safe guard you ability to all ways be able boot your system.
mkdir /boot/kernel.generic/
cp -Rfv /boot/kernel.old/ /boot/kernel.generic/
Never delete the /boot/kernel.GENERIC/ directory. The /kernel.generic should be kept in case you compile a faulty kernel that won't boot properly and you need to boot from a kernel known to work. After you perform a couple of compiles in a row your original working kernel has rolled off and you have nothing to recover to.
Another common practice is to give special names to different kernels indicating what was added. Say in the current kernel you added IPFW statements to compile in IPfirewall. You should make a copy of /boot/kernel/ and give it a name that has meaning to you.
mkdir /boot/kernel.ipfw/
cp -Rfv /boot/kernel/ /boot/kernel.ipfw/
Use these commands
cp -Rfv /boot/kernel.generic/ /boot/kernel # replace kernel with different one
reboot
There maybe times when you have made changes to /etc/rc.conf or created a new kernel, and the FBSD will not boot successfully, or you forgot the root password.
You need to gain access to your FBSD system in some way so you can fix your problems. You do this be going into single user mode. This can only be done from the FBSD system console.
During the normal boot process, it pauses for 10 seconds at the beastie menu. At this pause select option 4 for single user mode:
At the prompt for shell path, just hit enter on keyboard.
When the system comes up you have to manually mount all filesystems to gain access:
fsck -p
mount -u /
mount -a -t ufs
swapon -a
Now you have a running system as normal except you are the only one with access from the system console. Do whatever you need to do to repair your problem. When you have completed your repairs, enter the reboot command.
During the normal boot process, it pauses for 10 seconds at the beastie menu. At this pause select option 4 for single user mode:
At the prompt for shell path, just hit enter on keyboard.
At the 'ok' prompt enter this commands
passwd root
and follow the prompts. When complete, enter the reboot command.
During the normal boot process, it pauses for 10 seconds at the beastie menu. At this pause select option 4 for single user mode:
At the prompt for shell path, just hit enter on keyboard.
At the 'ok' prompt enter these commands to load the GENERIC kernel or the kernel you want.
unload # unloads all modules that are positioned to boot from
load /boot/kernel.GENERIC/kernel # Load the kernel you want or the generic one
boot # start the boot process over again using your kernel
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/14.00-FTP_Telnet.htm 000644 000000 000000 00000041425 10433404272 023373 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
FTP is a dinosaur left over from the time before the internet was born, when research universities were leased lined together and FTP was used to share files among research Scientists. This was a time when data security was not even an idea yet. Over the years the FTP protocol became buried into the backbone of the emerging internet and it's un-secure protocol was never changed to address new security concerns. FTP has 2 flavors, it can run in active mode or passive mode. The difference is in how the data channel is acquired. Passive mode is more secure as the data channel is acquired be the ordinal ftp session requester. For a real good explanation of FTP and it's different modes read this
http://www.slacksite.com/other/ftp.htmlTelnet is another dinosaur from before the internet. It's used by a remote user to gain access to their account on an Unix type system.
FTP and Telnet share the same security concern, they both pass the logon ID and password as open text over the internet. It is technically possible for a remote user to capture and interrogate all the packets traveling the public internet looking for FTP or Telnet login requests, and then to use the captured info to gain access to your system as an official user. This does not mean they are in any kind of position to do anything more harmful than the official user could do. The same thing is happening in FTP when it's configured as a anonymous server. But some Information Technology security officials who are overly paranoid consider this a security hole even though the odds of this happing is very, very remote. I know commercial sites who have been using both Telnet and FTP in their native form of open text logins for over 30 years without any security problems. Using the native form of FTP and Telnet for the users on your private LAN is not a security risk, so it's covered here in detail so the reader learns how to enable it.
Installer Note.
There are 82 other third party FTP software applications in the ftp category of the ports collection to chose from if you want or need something different than the built in FBSD FTP server. Telnet also has other ports to chose from in the net and security port categories.
The inetd utility daemon is enabled at boot time by /etc/rc.conf. It listens for connections on Internet sockets it's configured for. When a connection is received on one of its sockets, it launches the configured program corresponding to that socket. After the launched program is finished, inetd closes down the launched program and returns to listen on the socket for the next service request. Essentially, inetd allows running one daemon (itself) to dynamically launch several others, reducing the load on the system from having each running its own daemon all the time. FTP and Telnet are just two of the many possible pre-configured, commented out services which are available. Most of the services are leftover dinosaur's from life before the Internet and are normally not used. See 'man inetd' for more info.
You edit the /etc/inetd.conf file and uncomment the follow statements to enable then:
#ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l
#telnet stream tcp nowait root /usr/libexec/telnetd telnetd
Add this statement to your /etc/rc.conf file and reboot to enable.
inetd_enable="YES" # Run the Super Server daemon dispatcher
Without a firewall to deny access to these services from the public Internet, any user who has an account on your FBSD box can use these service from the LAN or public Internet.
The FTP default configuration is defined so any user with an ID & password on your system will be able to upload and download into their /home directory. They also have the ability to cd (change directory) into any directory on the system and download from it. This is not a good situation. There are two config files available to you to control who has FTP access and confine them to their home directories. They are:
/etc/ftpusers You add the account name of users who you do not want to have access to FTP services.
/etc/ftpchroot This file is not there as part of the install process. You have to create it. You add the account names of the users who you want their FTP access on your system confined to their home directories. This should be everyone.
There are two other server options which can control the user's FTP abilities.
-o This puts the FTP server in upload only mode, the download function is disabled.
-r This puts the FTP server in read only mode. All commands which can modify files or directories are disabled. Example: delete file, rename file, make directory, and delete directory commands.
You would add these FTP server run time options to the end of the FTP statement in the inetd.conf file, like this:
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -rol
The -l option means to enable logging.
There is one more native FTP function called 'Anonymous FTP Server'. The sysinstall program will build an Anonymous FTP Server environment for you. The sysinstall process on all FBSD versions since FBSD version 4.4 including the FBSD 5.2 version is outdated and no longer accurate. It builds and populates an anonymous directory tree which is unnecessary.
I will explain how to clean up the unneeded directories.
Start sysinstall by entering the following on the command line:
/stand/sysinstall
From the main menu select:
Configure Do post install configuration of FreeBSD
From the Configuration Menu select:
Networking Configure additional network services
From the Networking Services Menu select:
Anon FTP This machine wishes to allow Anonymous FTP
A request confirmation window opens:
Respond YES
A configure options window pops up.
Tab to path configuration option.
Change path from /var/ftp to /usr/ftp
Tab to upload sub-directory:
Change it to anonymous.ftp
Tab to ok and hit enter
You are asked if you want to create welcome message file:
Answer NO
Then move the highlight bar to the exit line and hit enter.
Then again move highlight bar to the exit line and hit enter.
Tab to exit and hit enter to leave sysinstall.
Now you have to clean up the directories that sysinstall created for you but which are no longer necessary.
cd /usr
ls -l
drwxrwxr-x 2 root operator 512 Dec 25 16:48 .snap
drwxr-xr-x 2 root wheel 7168 Dec 25 16:54 bin
drwxr-xr-x 2 root wheel 512 Dec 25 16:54 compat
dr-xr-xr-x 6 root wheel 512 Dec 28 14:49 ftp
drwxr-xr-x 2 root wheel 512 Dec 25 16:54 games
drwxr-xr-x 3 root wheel 512 Dec 28 14:46 home
You see the ftp directory sysinstall created for you.
cd ftp
ls -l
drwxrwxrwt 2 root wheel 512 Dec 28 14:49 anonymous.ftp
dr-xr-xr-x 2 root wheel 512 Dec 28 14:49 bin
dr-xr-xr-x 2 root wheel 512 Dec 28 14:49 etc
drwxr-xr-x 2 root wheel 512 Dec 28 14:49 pub
The ftp directory contains those sub-directories. Look at the permissions on the anonymous.ftp directory. It ends with a t. This is the directory that is going to be the FTP anonymous server new upload/download directory.
You are going to copy this directory to its final location.
cp -rpf anonymous.ftp /usr/home/
Now you can remove the ftp directory and all its sub-directories:
cd .. # back down one level in the directory tree
rm -rf ftp # Remove them all
ls # look to be sure it gone
Lets look to verify the new directory is there:
cd /usr/home
ls -l
drwxrwxrwt 2 root wheel 512 Dec 28 14:49 anonymous.ftp
It's there and it has the correct permissions.
Now you have to edit the password file and change the FTP user to point to the correct location of its upload/download directory:
vipw
Find this line:
ftp:*:14:5::0:0:Anonymous FTP Admin:/usr/ftp:/nonexistent
Change it so it looks like this with the directory path pointing to the new location:
ftp:*:14:5::0:0:Anonymous FTP Admin:/usr/home/anonymous.ftp:/nonexistent
Your Anonymous FTP server configuration is now completed.
There is one major problem that all anonymous FTP servers are faced with: limiting the size of the disk space of the upload directory. You also have this problem with your users home directories. The directory size will just keep growing until all the free space in the /usr slice is consumed. The size in the directories can by restricted to a pre-defined size using quotas.
See this for more info:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/quotas.html
To enable the quotas function you have to add this statement to your kernel source and recompile.
options QUOTA
Edit /etc/fstab and change the /usr slice to look like this to enable quotas on it.
The keyword userquota is for individual user quotas. The keyword groupquota is for quotas on all the users belonging to a group. Best to specify both keywords now so you can select later how you want to use it.
/dev/ad0s1f /usr ufs rw,userquota,groupquota 2 2
After rebooting your system, issue the following command to create all the quota files needed by the quota system.
quotacheck -a
Issue the following command to start the quota system on the /usr slice:
quotaon -a
To edit user quotas for anonymous FTP, issue the following command:
edquota -u ftp
To enable quotas every time you reboot your system edit /etc/rc.conf and add this:
quota_enable="YES"
check_quotas="YES"
To check on quota usage of anonymous FTP, issue the following command as root:
quota ftp
Telnet is dynamically launched by the inetd utility daemon the same way FTP is. The telnet client program on FBSD systems use SRA to encrypt the id and password so it does not go over the Internet in clear text. So as long as you are using a FBSD system as the remote system to login to your telnet server there is no security problem. The problem is with MS/Window boxes using standard telnet to access your telnet server. They transmit the ID and password over the public Internet in plain text.
There are MS/Windows clients which use ssh to login to your FBSD system using the sshd daemon. The sshd has its own built in version of a telnet server and an FTP like function for uploading and downloading from the user's home directory. These programs can use all the different kinds of secure and encrypted login functions. Describing them is out of the scope of this instructional guide. Here are some links to the most popular clients programs for MS/Windows that work with your FBSD system.
http://winscp.sourceforge.net/eng/about.php http://www.vandyke.com/products/securecrt/
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/15.00-Masquerading_as_an_Commercial_User.htm 000644 000000 000000 00000054305 10433404272 030343 0 ustar 00root wheel 000000 000000
Home______________________________________________________________________
Masquerading as a commercial user is a way for a 24/7 DSL or cable home user to host their own SMTP mail server and web server.
There is a way for non-commercial users to masquerade as a commercial user on the public Internet. The success of masquerading is based totally on whether their ISP has blocked email port 25 and web site port 80 from public Internet access for the ISP's non-commercial users. Sometimes the blocked ports are stated in the ISP's customer usage agreement contract. If you ask the ISP's technical support people it will only give them cause to monitor your account. So what I am saying here is, it may work or may not. If you're caught by your ISP they can terminate your account with them, but since they do not take legal action because the legal costs far outweigh the actual cost of the damages, what do you care, just sign up with a different ISP.
There are no rules or regulations which prohibit a non-commercial user from acquiring an official registered domain name for themselves. Anybody can get a registered domain name. You have to use an official domain name registrar. Each country in the world has one or more commercial companies that are authorized to register the domain name of your choice for a yearly fee. In the USA I use
http://www.enom.com/ .Generally your domain registrar has Internet applications where you can forward your domain name email to your ISP email account or forward all www port 80 requests to your public domain IP address.
The problem is the registered domain name has to be associated with an IP address that points to the non-commercial user 24/7 (IE: thats 24 hours a day 7 days a week). Non-commercial users get dynamic IP addresses which can change at any time. So you need some way to automatically determine when your dynamic IP address has changed and update your domain name to point to the new IP address. There are services on the public Internet which provide dynamic DNS. They manage your domain name on public domain name servers and you can update the IP address associated with your domain name automatically by using a program that runs on your FBSD system. The following companies provide this service free of charge.
www.dyndns.orghttp://www.no-ip.com/ http://www.technopagan.org/dynamic/
FBSD contains a package application to monitor your IP address to see if it has changed, and if it has, it submits an update request to the dynamic DNS service you are using to update your domain name's IP address with the new IP address.
See http://www.freebsd.org/cgi/ports.cgi?query=ez-ipupdate&stype=all
Before going through all the effort of installing and configuring sendmail and Apache web server, it would be nice to verify that your ISP is not blocking the STMP port 25 and the www port 80. Since you would have to install and configure the Apache server before the port 80 would answer to public requests, an easier approach is needed. You can change the port telnet uses (23) very easily to port 80 so there is an application to respond to port 80 connection requests. This is how you do it.
On the gateway system you want to masquerade as a commercial user:
Edit the /etc/services file. It contains a list of all the ports and the service names that use each port number.
Locate the HTTP 80 statements and comment them out.
Locate the telnet 23 statements and comment them out.
Copy the telnet tcp 23 statement and change the 23 to 80 and uncomment the statement.
Remember what you did, because after your test you will have to put this file back to its original condition by deleting the statement you added and uncommenting the ones you commented out.
Edit /etc/inetd.conf and un-comment the telnet tcp statement.
Edit /etc/rc.conf and add these statement inetd_enable="YES"
Check your firewall rules to ensure that they allow ports 25 and 80 in from the public Internet.
Reboot your system to enable the changes.
Issue ifconfig and write down your current ISP assigned IP address.
Leave your system up.
Then from a friend's MS/Windows PC that uses a different ISP than you do, use telnet to connect to ports 25 and 80 on your gateway system to see if your ISP is blocking those ports. In the following telnet command xxx.xxx.xxx.xxx is the current public IP address of your gateway system.
Click on start, run.
Enter: C:\windows\command.com
When a native DOS window opens, enter:
telnet xxx.xxx.xxx.xxx 25
If your ISP is not blocking the sendmail port and your friends PC does not have a firewall blocking this port, you will get a connected message followed by the sendmail version banner message. Press the keyboard ctrl and ] keys at same time to close the sendmail connection, then enter quit to exit the telnet program.
telnet xxx.xxx.xxx.xxx 80
If your ISP is not blocking the WWW port, and your friends PC does not have a firewall blocking this port, you will get a connected message followed by the telnet login prompt. Press the keyboard ctrl and ] keys at same time followed by enter key to close the telnet session.
If you received the connected message from your systems sendmail port 25, get a registered domain name and use ZoneEdit.com for dynamic IP address updates and point all your domain name email traffic to your sendmail server.
If you did not received the connected message from your systems sendmail port 25, you can still get a registered domain name and use ZoneEdit.com for dynamic IP address updates and forward your domain name email traffic to your ISP email account.
If you received the connected message from port 80, install the Apache web server application on your gateway PC, get a registered domain name, use ZoneEdit.com for dynamic IP address updates and point all your WWW traffic to your Apache web server.
If you did not receive the connected message from port 80, you can still get a registered domain name and use ZoneEdit.com to redirect all your domain name WWW traffic to a different port number, install the Apache web server application on your gateway PC and configure Apache to listen on the different port instead of the default port 80.
ZoneEdit is not a domain name registrar. They provide DNS network management services. They have a national network of DNS (domain name system servers) and have an online control panel for easy user self-management of their own officially registered domain names. Their environment provides a method utilizing the dynamic IP address and web page redirection to enable the users public domain name to function like a commercial user. Their service is free of cost for the first 5 domain names with each one being allowed 1,000,000 DNS queries before you have to pay $10.95 for the next million DNS queries. If you have that kind of activity you must be selling something that everybody wants and for sure can afford the $10.95. ZoneEdit does not apply any banners or other form of advertising to the traffic passing through them like some of the other companies that offer the same services. The public Internet users that go to your web site dont even know they passed through ZoneEdit.
Typically a commercial user has a 24/7 Internet connection with a range of static IP addresses assigned by their ISP. Their IP addresses never change. Their officially registered domain name points to the static IP addresses permanently.
Cable and DSL users have the a 24/7 Internet connection just like a commercial user. They can register their desired domain name if its not all ready taken with an official registrar which will permanently associate the domain name with whatever IP address their told. Normally the official registrar has online management menus which, at a minimum, allow you to forward your domain's email to your ISP email account, direct all web site requests to a provided pre-fabricated parking web site, and change the DNS servers that control your domain name's presence on the public Internet from the official registrar DNS servers to any other DNS servers you want.
The problem the non-commercial cable and DSL users have is their IP address is not static. Instead, they get assigned dynamic IP addresses by their ISPs. This means it can change every time their cable or DSL modem is powered off and back on, or if their ISP uses DHCP to assign dynamic IP address automatically, it can change at boot time or periodically when the DHCP lease is renewed. When this happens the registered domain name no longer points to the correct IP address and people on the public Internet can no longer reach the web site. To get back online they have to use their official registers on-line menus to manually change the permanent IP address and wait while the new domain name / IP address combination is distributed across the national DNS server network before people can find them again.
What ZoneEdit does for you is act as your intermediary by being the permanent IP address for your domain name, and then providing the ability to redirect all email and web traffic directly to the dynamic IP address which is currently assigned to you. In this way, your sendmail email server and apache web server receives the traffic. You would use a simple program on your system that executes at boot time and every time your ISP renews your DHCP lease to inform ZoneEdit of your current IP address. This allows you to always have a relationship between your public Internet official domain name and the IP address which is assigned to you.
Now, because many ISPs block the email server port number 25 and the web site port number 80, the previously described situation no longer helps you. To combat this, ZoneEdit has additional options: email forwarding, and web site redirection which address the ISP blocked ports issue.
Currently, ZoneEdit does not have any way to redirect your domain name email to a different port number instead of port 25 so it can reach your domain name email server. They do have a facility where you define your domain name email users and the email address at your ISPs email server where you want the email forwarded to.
The ZoneEdit Web site redirect facility is the key to circumventing the blocked port 80 problem. All your domain name web site traffic for port 80 that arrives at ZoneEdit for you is redirected to a different port number at the dynamic IP address which designates your location. It takes the combination of two different ZoneEdit facilities to achieve this: Dynamic IP address update and web site redirection.
First you need to register your desired domain name with an official registrar. In selecting an official registrar the registration cost and yearly renewal costs should not be your only selection criteria. If they do not offer an on-line management menu which allows you to forward your domain's email to your ISP email account, direct all web site requests to a provided pre-fabricated parking web site, and allow the changing of the DNS servers that control your domain's presence on the public Internet from the official registrar DNS servers to any other DNS servers you want, then look for a different official registrar. In the following discussion the example fbsdjones.com is the new officially registered domain name.
Go to www.zoneedit.com. In the upper right corner of the screen is the sign up link. Click on this and fill out the form. After completion you have to wait for an email from ZoneEdit with your login ID and password which gives you access to their online management menu application.
After receiving your email from ZoneEdit which takes less that 30 minutes to happen, go back to the same URL and this time on the upper left is the LOGIN link. Click on that and a window pops up. Enter the login ID and password contained in the email. The first thing to do is change that password to something you can remember easily. At the top of the screen is the menu bar. Click on User Options. On the screen that pops up change your password and set the default email address you want to use as the target to forward your domain name email users to. When finished, click on Add Zones from the menu at the top of the screen.
At the top of the Add Zones screen is a white window which you are to type in your domain name. Enter fbsdjones.com and click on the add zone button. It goes and does a lookup on the domain name you entered to see who its registered to and displays that information. Scroll down to the end of the screen and click on the Start editing zone button.
You're now presented with the Edit Zone screen. If you want to set up records to forward you domain email to your ISP email account. Click on the MailForwards highlighted link and follow the instructions. Thats real easy to do.
If you are also interested in redirecting all public web site traffic for your public Internet domain name www.fdsdjones.com and fbsdjones.com to your dynamic IP address using a different port number. Click on the WebForwards button.
On the WebForwards screen:
enter www in the new domain window
and
http://ww2.fbsdjones.com:6080/ in the redirects to window.
The 6080 is the port number your web server should be configured to be listening on. Do not select cloaked, or when one of the many Internet search robots come to your domain name site to collect the meta tags which you painstakingly added to each web page so you get indexed the way you want to in their search engine, your site will not be scanned and all that work will be for nothing. Its not important here what your domain name is. Its the www to ww2 and the :xxxx port number which is very important here. You can select any port number you want between 6000 and 9000. The important thing about the port number used is that you configure your web server software to listen on that port number instead on the default of 80. Click on the Add New button. A confirmation screen pops up. Select yes to the question about both fbsdjones.com and www.fbsdjones.com to be forwarded.
At the top of the screen, click on the IP Address (A) link. When that screen shows up, this is where you associate your currently assigned dynamic IP address to the name of the web site you previously specified as the redirect target on the WebForwards screen. That would be ww2.fbsdjones.com. So in the name window type ww2. In the Numeric IP window enter your currently assigned dynamic IP address if you know it. If you do not know it, thats not important right now, so enter 10.0.10.2 just to pass the syntax check and click on the Add new IP address button. Answer yes to the confirmation question.
At the top of the screen click on the Add Zones link. After that screen displays, click on the Edit Zone link and you will get a small box with "Choose Zone in it. Click on your zone to get the full zone display screen below. This screen shows all the configuration you did. It should look like this.
What this means is that your public Internet domain name fbsdjones.com and the FQDN (IE: fully qualified domain name) www.fbsdjones.com has a permanent IP address which directs all the traffic to ZoneEdit. When any traffic arrives for your domain name, ZoneEdit reads the Zone configuration records you built for your domain name and redirects the traffic to ww2.fbsdjones.com with the port number 6080, using the IP address in the IP address field. Email traffic for the specified users is forwarded to your specified ISP email account or accounts.
Now here is the real power and conveyance of using ZoneEdit. The 10.0.10.2 IP address value contained in the ZoneEdit IP address field in the about screen shot can be updated with your current dynamic IP address by your computer executing a simple program.
FreeBSD has a few different specially coded applications in the ports/packages collection to perform this function. I chose the wget application.
pkg_add rv wget
will download the package and install it. When the install completes, issue the rehash command. This is the format to the wget command to use:
wget -O - --http-user=username --http-passwd=password \ 'http://dynamic.zoneedit.com/auth/dynamic.html?host=ww2.fbsdjones.com'
Put your ZoneEdit issued user ID and your password in the appropriate fields.
Create an /etc/dhclient-exit-hooks file and put the wget command in it. The contents of this file is executed whenever dhclient is run, and the wget command will automatically update your ZoneEdit dynamic IP address.
How this works is the wget command is really issuing a web page request to ZoneEdit's special dynamic IP web site. The packet containing this request also carried the IP address of the requester (IE: your current dynamic IP address). The ZoneEdit special web site captures the requester IP address and updates your zone configuration IP address record with it.
The above wget command displays the result message to the screen and it gets lost. Its a good idea to log those messages, and you can do that be changing the wget command so it looks like this:
wget a /var/log/zoneedit.log \
--http-user=username --http-passwd=password \
'http://dynamic.zoneedit.com/auth/dynamic.html?host=ww2.fbsdjones.com'
You have to create that log like this:
touch /var/log/zoneedit.log
Also add it to newsyslog.conf so it gets archived.
Previous Page Next Page
This FreeBSD Installer Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.
usr/local/share/doc/FBSD_Install_Guide/favicon.ico 000644 000000 000000 00000007066 10433404272 022401 0 ustar 00root wheel 000000 000000 h & ( @ » ȶ JB oh f\ x aZ jd ~ HA ! u [Q d\ /$ ytz XNy x lfx lfw v u s =5o m E
mw=o[ӭ|SC3!' E{&{5JS Œ%BաVq/rɮY]Ҳ:MkWx㎟,~mWQ4SCwmyc K~H0Eeެ ʪY~-K]o0kzqus`';MhH"])#zacFQj\|I+V'_#ר:JݡogXH 1|e\lVx#" j⏆?7fk,S7L Mn7g_&\ou8NvZ$m鶿. utW~7\{6^ѵ _b<qw:oT,IG+U%Oށ> hx3Ggxø%Ťq}K˂y :ڷa9FK5K]n{앣̩5m>Hs<xF)|9HQǥ*kRD& "/,aV?zDKz7-h_ {_Gj*˦^ u͈a
dD*2#2F[DŽ } $& ky;)ۻj vA^pQ)W˖Vef~W{RrM[| T%m ! <=xWO(__I &'{IO)!<:=|n`]lj |%u*J$ifx#^n[Z&6 [D~'|#:eV > -Y ,N$k WkKpzzFdnJܦFK^oGʐx~3S=ibrx4KŲoy 4i
wXV|;./|+e$Zƽ 1Eu @ss_ZQ\j**OYIIޓ]-&ػZ H>)|<]}bW-u]/qkz05x/ ⟴YeJHLM G |Keqy'_ľ G1Go,my {"BƲ)xUd'֢yyZ=OSQ>ix WDе_A=z'IjeC+Y!x: xVm'oM4YM#īc.$s=zOl .M֦yB͌GEm[hJO}= ݷm{MJ6I*
u??W@լ>#9:߇u}>Gmw[({7t% D:yy S]xŰNes-6M-Q |R#.k|M&3 ~j~f
j a//\ׇ-~-~-#kt O4 K5KeYZ6ROW?
8Rcl|?(C[xε7|#uỘ4? ˉa, F ) tD@ [( TiA-YmTZwAX+|G]{L턒U&H!XV454'ggKC?%ះմ?_5ۯhc-zh]QsI y QkXq|Ie6xZEީxR}.c *>KNL
0S}E~a^^MQ})FSM_ |o?2NUKPo{oPny!ALReN[>^+ -νQj|2,Gk}D֗s]3X$;ldDfq%IJ?̈הVK(2TRDP.Z$ee$ z VCN Û-#Oe=Fs>DN0)'̅m]gu{Ik; $ڏt3 &iR!mg]͈ j
(h-_oQ ľ
@Zԫ%
1LMm4m: X {[hqC dhSO
'ou6Vv[}#{kn_ֿ|mo:đFū,2Xy3#1S)7O=h K֩⏈l(SM(6չ֭믝+w .x&N6s|`x=DŽB|BC
$͌)g+Ql3XG_+Aacko-5[#R1RG}5E f'%Bd?x`{E