FreeBSDwiki - User contributions [en]

Disaster Recovery Scheme

2012-08-14T00:50:58Z

173.88.199.104: /* Dump To Remote Host */

== Disaster Recovery Scheme ==

The biggest error made by computer users is ignoring the importance of backing up their systems. Now for home personal systems where there is no real user data or the system is not used as the major vehicle to interface with the Internet, then a backup of your hard drive may not be necessary. But if you have a desktop installed or more than a few ports installed ‘IT IS NECESSARY’ to make a backup of your customized system as reinstalling everything from scratch is much more of a effort than just restoring the backup of your system. Professional users have an even more pressing need for back ups as they are generally required to provide 7/24 available which means they do not have time to reinstall and configure from scratch.

The second biggest error made by computer users is not testing the restore process before it’s required in an emergence caused my hard drive failure or security compromise of the system or just plain stupid administration operator errors. Having a pre-tested documented restore process is essential in a professional 7/24 available environment. Nothing is worse then trying to use your backup files and finding out they are un-usable or incomplete. This is why a Disaster Recovery simulation is so necessary.

== Two Categories of Backups ==

System Backups

System backups mean the file systems where the operating system runs from. The basic system runs out of the / file system and uses the /var file system. The /usr file system is where all the ports are run from and installed to as well as any system sources if installed.

User Data Backups

User data backups means backing up the data created by the users. Normally the directory /usr/home/user is the location for desktop application created user data files such as spreadsheet files or text files or document files. The location of Database data may also be a directory under /usr. This is ok on systems with only a few users and databases used for developing applications or only containing small amounts of data. Since ‘dump’ only works on ‘file systems’, dumping the /usr file system will back them up.

Backing up user data separate from the system has it logical benefits. In environments containing a large number of active users and production databases it’s desirable to allocate separate file systems for /usr/home and /myDataBase on the same hard drive or on a separate hard drive depending on their size. Backing up Database data with the dump command should not be the only mode of database backup. All database software has it’s own dump and restore functions and should be used separately and in addition to the dump command generated backups.

== Dump Command ==

The dump command is designed for writing an complete image of non-mounted file systems. Dump cannot select a directory tree or individual files to dump. Non-mounted file systems means ‘currently not in use’. When you are running in MUM (multi-user-mode) there are services and other background processes (IE: sendmail or postfix, cron, DHCP, apache, mysql.) changing the content of the files in the live file system being dumped. Trying to dump the file systems that your system is running from may result in dumping files that are changing in flight thus causing the dump file to contain "time skew" corruption making it un-usable for restore. There are 2 ways to eliminate this problem.

== Multiple-User-Mode ==

In MUM (multiple-user-mode) which is the normal way FreeBSD runs, you give the ‘dump command’ the –L flag. This tells dump that its going to be reading a live file system and to first take a snapshot of the file system in the .snap directory of that file system. The point of the snapshot is to give a point-in-time consistent view of the filesystem.

== Single-User-Mode ==

The alternate method is by booting your system in SUM (single-user-mode). In SUM your system is isolated from the network, all file systems are un-mounted except / which is in read only mode and there is only one active process in your system, the root shell you are using to dump and or restore the file systems. In this environment you leave off the –L flag from the dump command.

To enter SUM:
During the normal boot process, it pauses for 10 seconds at the FreeBSD 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 are in SUM, all file systems are un-mounted except / which is mounted read only.

Then issue the dump command writing the dump of each individual file system out to another motherboard cabled hard drive or USB cabled hard drive or USB memory stick, or to old fashion tape drive.

<pre>
Pros and Cons of SUM verse MUM for dump processing
MUM Pros: Can target remote hosts as depository of the backup
file directly while the dump is running.
No schedule problem of when to run the dump.
Cons: The –L flag will cause dump to hesitate while the
snapshot is taken.
The length of this hesitation depends on what services
and or applications are running on the file system
being dumped.
These services and or applications may also pause or
stop momentarily.

SUM Pros: Minimally shorter elapse running time because
no snapshot taken.
Cons: On busy production systems may not be able to schedule
reboot time to do dump.
Cannot target remote hosts as depository of the
backup file directly while the dump is running.
</pre>

== In summary ==

There is no technical reason for selecting to do SUM dumps verse MUM –L dumps. In both cases the resulting dump files are equivalent. Writing SUM dump files to a local host backup file system and when MUM is resumed transferring them to a remote host depository duplicates the function MUM –L has of being able to target remote hosts as depository of the backup file directly while the dump is running. Dumping and restoring requires a (Driver) running system. It does not matter if the (Driver system) is the system booted from the motherboard cabled hard drive, USB external cabled hard drive or USB memory stick containing a full installed system or booted from CD disk containing the livefs system. The livefs is burned to CD from the livefs.iso.

== How often to dump ==

You can do full dumps and dumps of just what has changed since the last time a file was dumped. These are called full dumps and change dumps. The documentation refers to them as level 0 for full dump and level 1-9 as the change dumps. The man pages give a complicated scheme for managing full and change dumps. Probably most people really need only a level 0 and a level 1, maybe a level 2.

Basically the point of the change dumps is to make smaller backup files, which takes less time and less media. You only make the full dump (level 0) once every week or every month - whatever you’re needs are. Then in between you only dump the files that have changed since the last full dump. If that change dump file gets too big as well, then you jump to the next level on change dump. So, you do a level 0, then, the next day a level 1. If it is small (meaning only a relatively few files have changed) then the third day you still make a level 1. If the level 1 dump is now real big (meaning a lot of files changed) then on day 4 you go to a level 2 dump, etc. It is probably a good idea to regularize the process of choosing levels. That is why the man page has such a complicated scheme that covers all conditions. But most people with a personal or office/department level server often need only a regular full (level 0) dump, plus a daily level 1 dump in between the full dumps. In fact, many servers are small enough that a daily level 0 dump is all that is needed.

Now, if you have a big system with lots of new files and changed files all the time, then you will have to organize your dumps in a more sophisticated manner. Generally, level 0 dumps take whatever amount of media they need to contain the whole filesystem. Then, for the change dumps (level 1..9) you hope to keep then to only one unit of media. If a change dump goes over one unit of media, then you move up a level the next time. The same goes for if the change dump starts to take a lot of extra time.

== Where To Write The Dump ==

Your backup dumps are the single most critical item in your Disaster Recovery Scheme. Your level 1...9 change dumps must be associated with their full dump level0 companion. Now in a large data environment having massive user data changed it might take two 3gb tapes to hold the full level0 dump and a single 3gb tape partly full for each daily level1 dump. A naming convention would be used in labeling the tapes to associate the dump0 tapes with it's dump1 tapes. When using a remote or local large hard drive for storage of your dumps a suitable naming convention would also suffice. The problem with using a central depository for all your dump files is when that device fails all your backups go with it.

== How Many Backup Copies Do You Keep ==

In a professional Disaster Recovery Scheme environment separate media would be used to contain the files in a son, father, grandfather rotation. For example, The production system is froze, meaning no new ports are being installed. The system (IE /, /var. /usr) gets a level0 dump every Sunday night. Each Sunday nights dump is written to a 4GB USB stick. The first Sunday this is the son backup. The second Sunday, the same level0 dump is written to a new USB stick as the son and the previous son becomes the father. On the third Sunday, The same level0 dump is written to a new USB stick as the son and the previous son becomes the father and the previous father becomes the grandfather. On the fourth Sunday, The previous grandfather is written as the new son and each one bumps over one in rotation. The advantage to this rotation is upon restoring you find the son USB stick has a hardware problem or what you are trying to recover is not on that version of the backup you always have the father and grandfather version as safe guards.

Another example. Using the same frozen system we have /usr/home and /database as a separate file system to segregate the user data from the system data. The system hosts hundreds of login accounts for a college computer programming students. We still do the Sunday night Full level0 dump to the son 32GB USB stick and an six nightly level1 dumps to the same son USB stick. We rotate through the 3 USB sticks as for the system dumps the only difference is the USB stick contains the dump0 and it's companion change level1 change dumps.

Modify this rotation concept to fit you particular needs.

== Dump To Remote Host ==

Dump doesn't cross file systems. In a typical FreeBSD install, /, /var, and /usr are separate file systems. A dump of / won't get them all at once. You have to issue dump command for each individual file systems, IE: /, /tmp. /var, and /usr. If you have a configuration where everything goes into a big /, dumping it will get all data from that partition. Slices and MBR are out of dump's scope.

Here is sample commands to dump from a host running in MUM (multiple-user-mode) and storing the dump file on a remote host. To make the identification of the dumps easier the first sample commands make copies of the partition label, the last boot messages, the MBR (Master Boot Record), and the fstab file. Port 777 on localhost is a pipe to the remote host with a 800 GB hard drive.

<pre>
bsdlabel ad4s1 | ssh -p 777 tom@remotehost dd of=/bkup/bsdlabel_ad4s1
dmesg -a | ssh -p 777 tom@remotehost dd of=/bkup/dmesg
dd if=/dev/ad4 count=1 | ssh -p 777 tom@remotehost dd of=/bkup/MBR
cat /etc/fstab | ssh -p 777 tom@remotehost dd of=/bkup/fstab
dump -0Lan -f - / | gzip | ssh -p 777 tom@remotehost dd of=/bkup/dump0-root.gz
dump -0Lan -f - /tmp | gzip | ssh -p 777 tom@remotehost dd of=/bkup/dump0-tmp.gz
dump -0Lan -f - /var | gzip | ssh -p 777 tom@remotehost dd of=/bkup/dump0-var.gz
dump -0Lan -f - /usr | gzip | ssh -p 777 tom@remotehost dd of=/bkup/dump0-usr.gz
</pre>

== Backup Script ==

The following script (fbsd2dump) will use a 1GB USB stick as depository for the dump files. A standard FreeBSD install with postfix, mysql, apache, php only consumes 600MG in dump format and only took 13 minutes to dump.

<pre>
#!/bin/sh
# This script will use dump command to backup your running
# system to a USB flash stick.
# This is run as root.
#
# Change these device unit pre-fixs in the code below as needed
# ad0 is the live file system
# da0 is the target
#
# Comment or uncomment the 4 dump statements depending on
# whether you want to compress the saved dump file.
#
# Be sure to unplug your USB stick and re-plug it in to
# mount it again.

echo " "
echo " "
echo "Starting time for this live file system dump is"
date

echo " "
echo " "
echo "Prepare the target"
dd if=/dev/zero of=/dev/da0 count=4
fdisk -BI /dev/da0
bsdlabel -B -w da0s1
newfs -U /dev/da0s1a
mount /dev/da0s1a /mnt
cd /mnt

echo " "
echo " "
echo "Post the dump date"
date > date.of.dump
cat date.of.dump

echo " "
echo " "
echo "Post the MBR"
dd if=/dev/ad0 count=1 > MBR
#dd if=/dev/ad0 count=1 | od -c

echo " "
echo " "
echo "Collect live Slice Partition sizes and save"
bsdlabel ad0s1 > liveSPsizes
cat liveSPsizes

echo " "
echo " "
echo "Collect live file system sizes and save"
df -h > liveFSsizes
cat liveFSsizes

echo " "
echo " "
echo "Post the fstab"
cp /etc/fstab > fstab
cat /etc/fstab

echo " "
echo " "
echo "Post the script used to create this dump"
cp /root/bin/fbsd2backup > fbsd2backup

echo " "
echo " "
echo "Post the script used to restore this dump"
cp /root/bin/fbsd2restore > fbsd2restore

echo " "
echo " "
echo "Dump file system 'a' / "
dump -0Lauf dump0-root /dev/ad0s1a
#dump -0Lauf dump0-root /dev/ad0s1a | gzip

echo " "
echo " "
echo "Dump file system 'd' /var "
dump -0Lauf dump0-var /dev/ad0s1d
#dump -0Lauf dump0-var /dev/ad0s1d | gzip

echo " "
echo " "
echo "Dump file system 'e' /tmp "
dump -0Lauf dump0-tmp /dev/ad0s1e
#dump -0Lauf dump0-tmp /dev/ad0s1e | gzip

echo " "
echo " "
echo "Dump file system 'f' /usr "
dump -0Lauf dump0-usr /dev/ad0s1f
#dump -0Lauf dump0-usr /dev/ad0s1f | gzip
sync
cd /root
umount /mnt

echo " "
echo " "
echo "Ending time for this live file system dump is"
date

echo " "
echo " "
echo "Script completed"
echo " "
echo " "
echo "Unplug your USB stick NOW"
</pre>

== Disaster Recovery Restore Script ==

The following script (fbsd2restore) is the companion restore script using the dump files on the USB stick created by the above fbsd2dump script.

<pre>
#!/bin/sh
# This script will use restore command to restore your running
# system from a USB flash stick containing the dumped file systems.
# This is run as root.
#
# Change these device unit pre-fixes in the code below as needed
# ad0 is the target system
# da0 is the USB flash stick
#
# This script assumes that the target of the restore is of same
# size or larger as the hard drive the saved dump file were
# created from and only has a single slice allocating all the space.
#
# Secondly, That the currently running Freebsd system was booted
# from a fixit cd or a USB cabled external hard drive or USB stick.
# IE: The target hard drive is not in use.
#
# Instructions to use when booting from fixit cd.
# use df -h to show you the mounted file systems
# Boot from fixit cd. Hit enter to accept English documentation.
# From the sysinstall main menu select fixit and then option 1 CD.
# You will get fixit command line prompt. enter this
# mount /dev/da0s1a /mnt # mount the USB stick holding the dump files
# cd /mnt # change into mount point
# cp fbsd2restore /bin/ # copy the restore script to location in path
# chmod 760 /bin/fbsd2restore # give script exec permissions
# fbsd2restore # exec the script
# when script finishes in about 13 minutes enter exit to return to sysinstall.
# Exit sysinstall and system reboots. Remove your fixit cd from the drive.
#

echo " "
echo " "
echo "Starting time for this file system restore is"
date

# make target mount point
cd /
mkdir -v target

echo " "
echo " "
echo "Prepare the target"
dd if=/mnt/MBR of=/dev/ad0 count=1
bsdlabel -B -w ad0s1

# You may want to edit the liveSPsizes file to change the
# file system allocation sizes.
# ee /mnt/liveSPsizes

bsdlabel -R ad0s1 /mnt/liveSPsizes
newfs -U /dev/ad0s1a
newfs -U /dev/ad0s1d
newfs -U /dev/ad0s1e
newfs -U /dev/ad0s1f

# The restore flag -N means
# Do the extraction normally, but do not actually write any changes
# to disk. This can be used to check the integrity of dump media
# or for Disaster Recovery simulation purposes.
#
# Note the -N flag IS used here and must be removed to run live

echo " "
echo " "
echo "Restore file system 'a' / "
mount -v /dev/ad0s1a /target
cd /target
restore -rvf /mnt/dump0-root
#restore -rNf /mnt/dump0-root
#gzip /mnt/dump0-root | restore -rf-

echo " "
echo " "
echo "Restore file system 'd' /var "
mount -v /dev/ad0s1d /target/var
cd /target/var
restore -rvf /mnt/dump0-var
#restore -rNf /mnt/dump0-var
#gzip /mnt/dump0-var | restore -rf-

echo " "
echo " "
echo "Restore file system 'e' /tmp "
mount -v /dev/ad0s1e /target/tmp
cd /target/tmp
restore -rvf /mnt/dump0-tmp
#restore -rNf /mnt/dump0-tmp
#gzip /mnt/dump0-tmp | restore -rf-

echo " "
echo " "
echo "Restore file system 'f' /usr "
mount -v /dev/ad0s1f /target/usr
cd /target/usr
restore -rvf /mnt/dump0-usr
#restore -rNf /mnt/dump0-usr
#gzip /mnt/dump0-usr | restore -rf-

sync
cd /

# Note that restore leaves a file restoresymtable in the root
# directory to pass information between incremental restore passes.
# This file should be removed when the last incremental has been restored.

rm -v /target/usr/restoresymtable
rm -v /target/tmp/restoresymtable
rm -v /target/var/restoresymtable
rm -v /target/restoresymtable

umount -v /target/usr
umount -v /target/tmp
umount -v /target/var
umount -v /target
rmdir -v target

echo " "
echo " "
echo "Ending time for this live file system dump is"
date

echo " "
echo " "
echo "Script completed"
</pre>

[[Category:Common Tasks]]
[[Category:Securing FreeBSD]]
[[Category:FreeBSD for Servers]]

Disaster Recovery Scheme

2012-08-14T00:48:12Z

173.88.199.104: Disaster Recovery Scheme

Personal Scripts

2012-08-14T00:39:19Z

173.88.199.104: Created page with " == Personal Scripts == 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 co..."

== Personal Scripts ==

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

<pre>
#! /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
</pre>

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.

[[Category:Common Tasks]]
[[Category:FreeBSD for Servers]]

File Permissions

2012-08-14T00:32:19Z

173.88.199.104: File Permissions

== File Permissions ==

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

<pre>
Position 1 values = d This is a directory
l This is a link file
- This is a file
</pre>

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.

<pre>
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
</pre>

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/

<pre>
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
</pre>

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.

== Managing Permissions ==

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

<pre>
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
</pre>

Change file permissions
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

== Change file owner ==
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

== Change file group ==
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.

[[Category:Common Tasks]]
[[Category:Securing FreeBSD]]
[[Category:FreeBSD for Servers]]

User Account Admin

2012-08-14T00:19:55Z

173.88.199.104: User Account Admin

== User Account Admin ==

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.

== Configure the pw Command ==

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:

<pre>
pw adduser -D # this will create the /etc/pw.conf file.
</pre>

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

<pre>
#
# /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
</pre>

Examples of pw command usage
pw adduser -D = create /etc/pw.conf file>

<pre>
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
</pre>

The pw subcommands can be written in reverse order:

adduser & useradd mean same thing.

pw command embedded in a script
<pre>
#! /bin/sh
pw adduser tom -m -c testing -h 0 <<EOD
water
EOD
# water is the password to be assigned to tom
</pre>

== passwd command ==
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

== chpass command ==
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

[[Category:Common Tasks]]
[[Category:FreeBSD for Servers]]

Local Area Network (LAN)

2012-08-14T00:09:56Z

173.88.199.104: /* DHCP Configuration Instructions */

== Setting up Local Area Network (LAN) ==

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

See 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

== Home User LANs ==

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.

Topography of a LAN
__________ ________ _____
| | | | | |
| 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.

== Installing the LAN ==

Your PC should have two NIC already installed.
During the boot of FBSD review the /var/run/dmesg.boot log to verify that your PCI NIC were 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 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.

== LAN private IP address ==

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:

<pre>
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
</pre>

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.

== Manually Configuring the Gateway host ==

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.

== Manually configuring LAN FBSD PC ==

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

== Manually config MS/Windows LAN PC ==

This procedure has been tested on MS/Windows 98, ME and XP.

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.

== DHCP (Dynamic Host Configuration Protocol) ==

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.

What function does DHCP perform?
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.

== DHCP Server ==

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

== How DHCP Works ==

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.

== DHCP Configuration Instructions ==

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

<pre>
dhcpd_enable="YES"
dhcpd_conf="/usr/local/etc/dhcpd.conf"
dhcpd_ifaces="xl0"
dhcpd_flags="-q"
</pre>

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

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

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;

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

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.

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

<pre>
local1.notice /var/log/dhcpd.log
</pre>

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 force the syslogd task into re-reading /etc/syslog.conf by issuing this console command
<pre>
/etc/rc.d/syslogd reload
</pre>

Now you must set up log rotation. Add this statement.

ee /etc/newsyslog.conf

<pre>
/var/log/dhcp.log 600 3 100 * B
</pre>

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

<pre>
/usr/local/etc/rc.d/isc-dhcp.sh start
stop
restart
</pre>

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.

== Testing the DHCPD Daemon ==

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, ME and XP 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.

== FBSD as a DHCP Client ==

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

<pre>
ifconfig_dc0="DHCP" # Where dc0 is the FBSD Nic card interface name.
</pre>

That's it, configuration complete. Reboot to activate your changes.

[[Category:Common Tasks]]
[[Category:FreeBSD for Servers]]

Local Area Network (LAN)

2012-08-14T00:04:00Z

173.88.199.104: /* DHCP Configuration Instructions */

== Setting up Local Area Network (LAN) ==

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

See 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

== Home User LANs ==

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.

Topography of a LAN
__________ ________ _____
| | | | | |
| 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.

== Installing the LAN ==

Your PC should have two NIC already installed.
During the boot of FBSD review the /var/run/dmesg.boot log to verify that your PCI NIC were 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 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.

== LAN private IP address ==

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:

<pre>
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
</pre>

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.

== Manually Configuring the Gateway host ==

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.

== Manually configuring LAN FBSD PC ==

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

== Manually config MS/Windows LAN PC ==

This procedure has been tested on MS/Windows 98, ME and XP.

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.

== DHCP (Dynamic Host Configuration Protocol) ==

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.

What function does DHCP perform?
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.

== DHCP Server ==

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

== How DHCP Works ==

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.

== DHCP Configuration Instructions ==

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

<pre>
dhcpd_enable="YES"
dhcpd_conf="/usr/local/etc/dhcpd.conf"
dhcpd_ifaces="xl0"
dhcpd_flags="-q"
</pre>

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

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

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.

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 force the syslogd task into re-reading /etc/syslog.conf by issuing this console command
/etc/rc.d/syslogd reload

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.

Testing the DHCPD Daemon
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.

== FBSD as a DHCP Client ==

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

<pre>
ifconfig_dc0="DHCP" # Where dc0 is the FBSD Nic card interface name.
</pre>

That's it, configuration complete. Reboot to activate your changes.

[[Category:Common Tasks]]
[[Category:FreeBSD for Servers]]

Local Area Network (LAN)

2012-08-14T00:01:48Z

173.88.199.104: /* LAN private IP address */

== Setting up Local Area Network (LAN) ==

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

See 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

== Home User LANs ==

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.

Topography of a LAN
__________ ________ _____
| | | | | |
| 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.

== Installing the LAN ==

Your PC should have two NIC already installed.
During the boot of FBSD review the /var/run/dmesg.boot log to verify that your PCI NIC were 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 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.

== LAN private IP address ==

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:

<pre>
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
</pre>

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.

== Manually Configuring the Gateway host ==

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.

== Manually configuring LAN FBSD PC ==

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

== Manually config MS/Windows LAN PC ==

This procedure has been tested on MS/Windows 98, ME and XP.

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.

== DHCP (Dynamic Host Configuration Protocol) ==

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.

What function does DHCP perform?
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.

== DHCP Server ==

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

== How DHCP Works ==

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.

== DHCP Configuration Instructions ==

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

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

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.

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 force the syslogd task into re-reading /etc/syslog.conf by issuing this console command
/etc/rc.d/syslogd reload

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.

Testing the DHCPD Daemon
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.

== FBSD as a DHCP Client ==

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

<pre>
ifconfig_dc0="DHCP" # Where dc0 is the FBSD Nic card interface name.
</pre>

That's it, configuration complete. Reboot to activate your changes.

[[Category:Common Tasks]]
[[Category:FreeBSD for Servers]]

Local Area Network (LAN)

2012-08-13T23:54:31Z

173.88.199.104:

== Setting up Local Area Network (LAN) ==

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

See 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

== Home User LANs ==

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.

Topography of a LAN
__________ ________ _____
| | | | | |
| 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.

== Installing the LAN ==

Your PC should have two NIC already installed.
During the boot of FBSD review the /var/run/dmesg.boot log to verify that your PCI NIC were 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 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.

== LAN private IP address ==

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.

== Manually Configuring the Gateway host ==

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.

== Manually configuring LAN FBSD PC ==

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

== Manually config MS/Windows LAN PC ==

This procedure has been tested on MS/Windows 98, ME and XP.

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.

== DHCP (Dynamic Host Configuration Protocol) ==

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.

What function does DHCP perform?
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.

== DHCP Server ==

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

== How DHCP Works ==

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.

== DHCP Configuration Instructions ==

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

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

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.

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 force the syslogd task into re-reading /etc/syslog.conf by issuing this console command
/etc/rc.d/syslogd reload

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.

Testing the DHCPD Daemon
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.

== FBSD as a DHCP Client ==

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

<pre>
ifconfig_dc0="DHCP" # Where dc0 is the FBSD Nic card interface name.
</pre>

That's it, configuration complete. Reboot to activate your changes.

[[Category:Common Tasks]]
[[Category:FreeBSD for Servers]]

Local Area Network (LAN)

2012-08-13T23:34:57Z

173.88.199.104: Local Area Network (LAN)

Example of configuring OpenSSH

2012-08-13T23:20:04Z

173.88.199.104: /* WinSCP3 Setup Steps */

== Example of configuring OpenSSH ==
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.

== Example Environment Description ==

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.

== Host Setup Steps ==
<pre>
1. Edit /etc/rc.conf and add this statement
sshd_enable="YES"
Make sure your firewall allows port 22 in from the public internet.
Reboot your system to activate sshd and login as root.
If this is your first time booting with sshd you will have to
create the host keys.
sshd will show you this on the first sshd boot only.

====================================================
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 use the Host 'root' account to initiate a ssh
session with an remote system you have to perform step 4 above.
If you want to do remote ssh login to this Host as user ‘root’, you
have to edit /etc/ssh/sshd_config on the this Host and change;

#PermitRootLogin no to PermitRootLogin yes

Then /etc/rc.d/sshd reload

to make sshd task reread it’s sshd_config file.

</pre>

== FBSD-client Setup Steps ==
<pre>
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 system’s 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
</pre>

== Using Midnight Commander for SFTP ==

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.

== Win-client Setup Steps ==

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.

<pre>
Putty Setup Steps
1. You have to get windows putty program from
http://www.chiark.greenend.org.uk/~sgtatham/putty/
Download the current windows installer program.
Currently that’s 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 it’s 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.
</pre>

== WinSCP3 Setup Steps ==

<pre>

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.
</pre>

[[Category : Common Tasks]]
[[Category : Securing FreeBSD]]

Example of configuring OpenSSH

2012-08-13T23:18:51Z

173.88.199.104: /* Win-client Setup Steps */

== Example of configuring OpenSSH ==
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.

== Example Environment Description ==

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.

== Host Setup Steps ==
<pre>
1. Edit /etc/rc.conf and add this statement
sshd_enable="YES"
Make sure your firewall allows port 22 in from the public internet.
Reboot your system to activate sshd and login as root.
If this is your first time booting with sshd you will have to
create the host keys.
sshd will show you this on the first sshd boot only.

====================================================
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 use the Host 'root' account to initiate a ssh
session with an remote system you have to perform step 4 above.
If you want to do remote ssh login to this Host as user ‘root’, you
have to edit /etc/ssh/sshd_config on the this Host and change;

#PermitRootLogin no to PermitRootLogin yes

Then /etc/rc.d/sshd reload

to make sshd task reread it’s sshd_config file.

</pre>

== FBSD-client Setup Steps ==
<pre>
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 system’s 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
</pre>

== Using Midnight Commander for SFTP ==

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.

== Win-client Setup Steps ==

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.

<pre>
Putty Setup Steps
1. You have to get windows putty program from
http://www.chiark.greenend.org.uk/~sgtatham/putty/
Download the current windows installer program.
Currently that’s 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 it’s 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.
</pre>

== WinSCP3 Setup Steps ==

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.

[[Category : Common Tasks]]
[[Category : Securing FreeBSD]]

Example of configuring OpenSSH

2012-08-13T23:16:43Z

173.88.199.104: /* FBSD-client Setup Steps */

== Example of configuring OpenSSH ==
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.

== Example Environment Description ==

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.

== Host Setup Steps ==
<pre>
1. Edit /etc/rc.conf and add this statement
sshd_enable="YES"
Make sure your firewall allows port 22 in from the public internet.
Reboot your system to activate sshd and login as root.
If this is your first time booting with sshd you will have to
create the host keys.
sshd will show you this on the first sshd boot only.

====================================================
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 use the Host 'root' account to initiate a ssh
session with an remote system you have to perform step 4 above.
If you want to do remote ssh login to this Host as user ‘root’, you
have to edit /etc/ssh/sshd_config on the this Host and change;

#PermitRootLogin no to PermitRootLogin yes

Then /etc/rc.d/sshd reload

to make sshd task reread it’s sshd_config file.

</pre>

== FBSD-client Setup Steps ==
<pre>
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 system’s 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
</pre>

== Using Midnight Commander for SFTP ==

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.

== Win-client Setup Steps ==

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.

Putty Setup Steps
1. You have to get windows putty program from
http://www.chiark.greenend.org.uk/~sgtatham/putty/
Download the current windows installer program.
Currently that’s 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 it’s 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.

== WinSCP3 Setup Steps ==

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.

[[Category : Common Tasks]]
[[Category : Securing FreeBSD]]

Example of configuring OpenSSH

2012-08-13T23:14:53Z

173.88.199.104: /* Host Setup Steps */

== Example of configuring OpenSSH ==
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.

== Example Environment Description ==

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.

== Host Setup Steps ==
<pre>
1. Edit /etc/rc.conf and add this statement
sshd_enable="YES"
Make sure your firewall allows port 22 in from the public internet.
Reboot your system to activate sshd and login as root.
If this is your first time booting with sshd you will have to
create the host keys.
sshd will show you this on the first sshd boot only.

====================================================
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 use the Host 'root' account to initiate a ssh
session with an remote system you have to perform step 4 above.
If you want to do remote ssh login to this Host as user ‘root’, you
have to edit /etc/ssh/sshd_config on the this Host and change;

#PermitRootLogin no to PermitRootLogin yes

Then /etc/rc.d/sshd reload

to make sshd task reread it’s sshd_config file.

</pre>

== FBSD-client Setup Steps ==

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 system’s 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

== Using Midnight Commander for SFTP ==

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.

== Win-client Setup Steps ==

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.

Putty Setup Steps
1. You have to get windows putty program from
http://www.chiark.greenend.org.uk/~sgtatham/putty/
Download the current windows installer program.
Currently that’s 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 it’s 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.

== WinSCP3 Setup Steps ==

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.

[[Category : Common Tasks]]
[[Category : Securing FreeBSD]]

Example of configuring OpenSSH

2012-08-13T23:11:23Z

173.88.199.104: Created page with " == Example of configuring OpenSSH == Normally, when using native telnet, rlogin, or ftp your login ID, password and tramsmitted data is sent over the network in an clear, un..."

== Example of configuring OpenSSH ==
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.

== Example Environment Description ==

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.

== Host Setup Steps ==

1. Edit /etc/rc.conf and add this statement
sshd_enable="YES"
Make sure your firewall allows port 22 in from the public internet.
Reboot your system to activate sshd and login as root.
If this is your first time booting with sshd you will have to
create the host keys.
sshd will show you this on the first sshd boot only.

====================================================
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 use the Host 'root' account to initiate a ssh
session with an remote system you have to perform step 4 above.
If you want to do remote ssh login to this Host as user ‘root’, you
have to edit /etc/ssh/sshd_config on the this Host and change;

#PermitRootLogin no to PermitRootLogin yes

Then /etc/rc.d/sshd reload

to make sshd task reread it’s sshd_config file.

== FBSD-client Setup Steps ==

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 system’s 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

== Using Midnight Commander for SFTP ==

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.

== Win-client Setup Steps ==

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.

Putty Setup Steps
1. You have to get windows putty program from
http://www.chiark.greenend.org.uk/~sgtatham/putty/
Download the current windows installer program.
Currently that’s 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 it’s 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.

== WinSCP3 Setup Steps ==

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.

[[Category : Common Tasks]]
[[Category : Securing FreeBSD]]

Defending Against Attacks

2012-08-13T23:00:41Z

173.88.199.104:

== Defending Against Attacks ==
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.

== Know Who Your Attacker is ==
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.

== Stopping Login Attacks ==
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:

<pre>
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
</pre>

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. The PF firewall has built in self limiting parameters (max-src-conn & max-src-conn-rate)which when execded can add the offending IP address automatically into a table of IP address that are blocked by the firewall.

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

PF Firewall Method Using the self limiting parameters max-src-conn & max-src-conn-rate coupled with the overload and expiretable parameters for automatic population of a table containing the offending IP address and the automatic removal of the offending IP address after no activity in a predefined time span. This method works for FTP, telnet, and ssh bruteforce logon type attacks in a simple and clean manner. IPFW & IPF firewalls do not have this built in capacity

See this link for rule coding details: http://www.bgnett.no/~peter/pf/en/bruteforce.html

== Stopping Web Server attacks ==
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.

[[Category:Securing FreeBSD]]

Defending Against Attacks

2012-08-13T22:55:38Z

173.88.199.104: Created page with " == Defending Against Attacks == 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 ..."

== Defending Against Attacks ==
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.

== Know Who Your Attacker is ==
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.

== Stopping Login Attacks ==
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. The PF firewall has built in self limiting parameters (max-src-conn & max-src-conn-rate)which when execded can add the offending IP address automatically into a table of IP address that are blocked by the firewall.

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

PF Firewall Method Using the self limiting parameters max-src-conn & max-src-conn-rate coupled with the overload and expiretable parameters for automatic population of a table containing the offending IP address and the automatic removal of the offending IP address after no activity in a predefined time span. This method works for FTP, telnet, and ssh bruteforce logon type attacks in a simple and clean manner. IPFW & IPF firewalls do not have this built in capacity

See this link for rule coding details: http://www.bgnett.no/~peter/pf/en/bruteforce.html

== Stopping Web Server attacks ==
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.

[[Category:Securing FreeBSD]]

IPFIREWALL (IPFW) Firewall

2012-08-13T22:48:12Z

173.88.199.104:

== IPFIREWALL (IPFW) Firewall ==

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.

== Enabling IPFW ==
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 it’s 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:

<pre>
ee /etc/sysctl.conf

net.inet.ip.fw.verbose_limit=5
</pre>

== Kernel options ==
It is not a mandatory requirement that you enable IPFW by compiling the following options into the FBSD kernel. It’s 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.
<pre>
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=5
option IPDIVERT
</pre>

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

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.

== RC.CONF Options ==
You have to tell FBSD to active it at boot time. You do that by adding the following statements to /etc/rc.conf:

<pre>
firewall_enable="YES" # Start IPFW daemon
firewall_script="/etc/ipfw.rules" # Use my custom rules.
filewall_logging="YES" # Enable packet logging
</pre>

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

== IPFW Command ==
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.

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.

<pre>
ipfw list List all rules in rule number sequence.

ipfw -t list List rules in rule number 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 number Clear accounting counter just for this rule number.

ipfw show | more
</pre>

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.

== IPFW Rule Sets ==
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.

== Rule Syntax ==
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

http://www.freebsd.org/cgi/man.cgi?query=ipfw&apropos=0&sektion=0&manpath=FreeBSD+9.0-RELEASE&format=html

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.

<pre>
# 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.
</pre>

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.

<pre>
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.
</pre>

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. It’s 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:

<pre>
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).
It’s 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 it’s 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.
</pre>

== Stateful Rule Option ==

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.

== Logging Firewall Messages ==
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.

== Building Rule Script ==
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.
<pre>

############### 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 ############
</pre>

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

<pre>
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
</pre>

== Stateful Rule Set ==

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 don’t 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

== Example Inclusive Rule Set ==

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 don’t 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

<pre>
################ 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 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 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 that’s 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 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 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 ###############################
</pre>

== Stateful + NATD Rule Set ==

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.

<pre>
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
</pre>

The rc.conf needs the following statements added to the already mentioned statements which are reproduced here:

<pre>
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
</pre>

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.

<pre>
#!/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 tcp from any to xx.168.240.2 53 out via $pif setup $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 ##################
</pre>

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.

<pre>
#!/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
$cmd 021 $skip 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.
$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 ###############################
</pre>

[[Category:Securing FreeBSD]]

IPFIREWALL (IPFW) Firewall

2012-08-13T22:35:45Z

173.88.199.104:

IPFIREWALL (IPFW) Firewall

2012-08-13T22:31:43Z

173.88.199.104: /* Example Inclusive Rule Set */

IPFIREWALL (IPFW) Firewall

2012-08-13T22:28:33Z

173.88.199.104:

IPFIREWALL (IPFW) Firewall

2012-08-13T22:25:36Z

173.88.199.104: /* Building Rule Script */

IPFIREWALL (IPFW) Firewall

2012-08-13T22:23:18Z

173.88.199.104: /* Rule Syntax */

IPFIREWALL (IPFW) Firewall

2012-08-13T22:00:39Z

173.88.199.104:

IPFIREWALL (IPFW) Firewall

2012-08-13T21:54:18Z

173.88.199.104: /* IPFW Command */

IPFIREWALL (IPFW) Firewall

2012-08-13T21:52:22Z

173.88.199.104: /* Kernel options */

IPFIREWALL (IPFW) Firewall

2012-08-13T21:50:51Z

173.88.199.104: /* Enabling IPFW */

IPFIREWALL (IPFW) Firewall

2012-08-13T21:49:23Z

173.88.199.104: IPFIREWALL (IPFW) Firewall

IPFILTER (IPF) Firewall

2012-08-13T21:38:50Z

173.88.199.104: /* RC.CONF Options */

== IPFILTER (IPF) Firewall ==
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. IPF’s 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

== Enabling IPF ==
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.

== Kernel options ==
It is not a mandatory requirement that you enable IPF by compiling the following options into the FBSD kernel. It’s 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 it’s 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.

== RC.CONF Options ==
You need the follow statements in /etc/rc.conf to activate IPF at boot time.
<pre>
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

</pre>

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.

<pre>
gateway_enable="YES" # Enable as LAN gateway
ipnat_enable="YES" # Start ipnat function
ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat
</pre>

== IPF COMMAND ==
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.

== IPFSTAT Command ==
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.

== IPMON Command ==
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:

<pre>
ipmon_flags="-Ds" # D = start as daemon
# s = log to syslog
# v = log tcp window, ack, seq
# n = map IP & port to names
</pre>

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.

It’s 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.

== IPMON Logging ==
Syslogd uses its own special method for segregation of log data. It uses special groupings called ‘facility’ and ‘level’. IPMON in –Ds mode uses local0 as the ‘facility’ name. All IPMON logged data goes to local0.

You have to manually configure the /etc/syslog.conf file by adding the statements to direct the Local0 'facility' to the log file name recording the log records. FBSD keeps all of its syslog files in /var/log/ directory.

First allocate the new named log file for the IPFMON 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.

You will have to edit the /etc/syslog.conf file.

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.

To activate the changes to /etc/syslog.conf you can reboot or force the syslogd task into re-reading /etc/syslog.conf by issuing this console command
/etc/rc.d/syslogd reload

Don’t forget to change /etc/newsyslog.conf to rotate the new named IPFILTER log you just created above.

== Format of Logged Messages ==
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).

== Building Rule Script ==
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.
<pre>
############# 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 ########################
</pre>

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

<pre>
#!/bin/sh
sh /etc/ipf.rules.script
</pre>

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.

== IPF Rule Sets ==
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.

== Rule Syntax ==
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

<pre>
# 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.
</pre>
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 it’s 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/ipcalc

port 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 ==
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.

== Inclusive Rule set Example ==
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 don’t 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 don’t 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
<pre>
#################################################################
# 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 ISP’s 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 that’s 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 don’t 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 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.
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 #################################
</pre>

== NAT Explanation ==
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. ISP’s 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 PC’s 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 PC’s 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

== IPNAT Command ==
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.

<pre>
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.
</pre>

== NAT Rules ==
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).

<pre>
# 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.
</pre>

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:

map dc0 10.0.10.1/29 -> 0.32

map = The keyword map starts the rule.

dc0 = The interface name of the interface facing the public Internet.

10.0.10.1/29 = The IP address range of the private LAN.

-> = Mandatory arrow symbol.

0.32 = The IP address/netmask assigned by your ISP.
The special alias keyword 0.32 tells ipnat to get the current public
IP address of the interface specified on this statement and
substitute it for the 0.32 keyword.

== How NAT works ==
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.

== Enabling NAT ==
To enable the IPNAT function add these statements to /etc/rc.conf

<pre>
gateway_enable="YES" # Enable as LAN gateway
ipnat_enable="YES" # Start ipnat function
ipnat_rules="/etc/ipnat.rules" # ipnat rules definition file
</pre>

== NAT for very large LAN ==
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.

== Directing traffic to LAN servers ==

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.
Such as this for the above example:

pass in quick on xl0 proto tcp from any to 10.0.10.5 port = 80 flags S keep state

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 Special NAT Handling ==
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:

<pre>
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
</pre>

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.

== FTP Filter rules ==
Only one filter rule is needed for FTP if NAT FTP proxy is used

<pre>
# 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
</pre>

Three Filter rules are needed for FTP if no NAT FTP proxy is used

<pre>
# 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
</pre>

[[Category:Securing FreeBSD]]
[[Category:Configuring FreeBSD]]

IPFILTER (IPF) Firewall

2012-08-13T21:38:04Z

173.88.199.104: /* Kernel options */

IPFILTER (IPF) Firewall

2012-08-13T21:37:25Z

173.88.199.104: /* Enabling IPF */

IPFILTER (IPF) Firewall

2012-08-13T21:36:48Z

173.88.199.104: /* IPMON Logging */

IPFILTER (IPF) Firewall

2012-08-13T21:36:08Z

173.88.199.104: /* IPMON Command */

IPFILTER (IPF) Firewall

2012-08-13T21:35:31Z

173.88.199.104: /* IPFILTER (IPF) Firewall */

IPFILTER (IPF) Firewall

2012-08-13T21:35:00Z

173.88.199.104: /* IPFSTAT Command */

IPFILTER (IPF) Firewall

2012-08-13T21:34:18Z

173.88.199.104: /* IPF COMMAND */

IPFILTER (IPF) Firewall

2012-08-13T21:33:38Z

173.88.199.104: /* RC.CONF Options */

IPFILTER (IPF) Firewall

2012-08-13T21:32:57Z

173.88.199.104: /* Kernel options */

IPFILTER (IPF) Firewall

2012-08-13T21:29:19Z

173.88.199.104: /* FTP Special NAT Handling */

== IPFILTER (IPF) Firewall ==
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. IPF’s 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

== Enabling IPF ==
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.

== Kernel options ==
It is not a mandatory requirement that you enable IPF by compiling the following options into the FBSD kernel. It’s 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 it’s 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.

== RC.CONF Options ==
You need the follow statements in /etc/rc.conf to activate IPF at boot time.
<pre>
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

</pre>

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.

<pre>
gateway_enable="YES" # Enable as LAN gateway
ipnat_enable="YES" # Start ipnat function
ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat
</pre>

== IPF COMMAND ==
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.

== IPFSTAT Command ==
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.

== IPMON Command ==
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:

<pre>
ipmon_flags="-Ds" # D = start as daemon
# s = log to syslog
# v = log tcp window, ack, seq
# n = map IP & port to names
</pre>

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.

It’s 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.

== IPMON Logging ==
Syslogd uses its own special method for segregation of log data. It uses special groupings called ‘facility’ and ‘level’. IPMON in –Ds mode uses local0 as the ‘facility’ name. All IPMON logged data goes to local0.

You have to manually configure the /etc/syslog.conf file by adding the statements to direct the Local0 'facility' to the log file name recording the log records. FBSD keeps all of its syslog files in /var/log/ directory.

First allocate the new named log file for the IPFMON 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.

You will have to edit the /etc/syslog.conf file.

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.

To activate the changes to /etc/syslog.conf you can reboot or force the syslogd task into re-reading /etc/syslog.conf by issuing this console command
/etc/rc.d/syslogd reload

Don’t forget to change /etc/newsyslog.conf to rotate the new named IPFILTER log you just created above.

== Format of Logged Messages ==
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).

== Building Rule Script ==
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.
<pre>
############# 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 ########################
</pre>

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

<pre>
#!/bin/sh
sh /etc/ipf.rules.script
</pre>

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.

== IPF Rule Sets ==
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.

== Rule Syntax ==
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

<pre>
# 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.
</pre>
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 it’s 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/ipcalc

port 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 ==
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.

== Inclusive Rule set Example ==
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 don’t 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 don’t 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
<pre>
#################################################################
# 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 ISP’s 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 that’s 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 don’t 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 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.
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 #################################
</pre>

== NAT Explanation ==
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. ISP’s 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 PC’s 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 PC’s 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

== IPNAT Command ==
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.

<pre>
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.
</pre>

== NAT Rules ==
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).

<pre>
# 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.
</pre>

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:

map dc0 10.0.10.1/29 -> 0.32

map = The keyword map starts the rule.

dc0 = The interface name of the interface facing the public Internet.

10.0.10.1/29 = The IP address range of the private LAN.

-> = Mandatory arrow symbol.

0.32 = The IP address/netmask assigned by your ISP.
The special alias keyword 0.32 tells ipnat to get the current public
IP address of the interface specified on this statement and
substitute it for the 0.32 keyword.

== How NAT works ==
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.

== Enabling NAT ==
To enable the IPNAT function add these statements to /etc/rc.conf

<pre>
gateway_enable="YES" # Enable as LAN gateway
ipnat_enable="YES" # Start ipnat function
ipnat_rules="/etc/ipnat.rules" # ipnat rules definition file
</pre>

== NAT for very large LAN ==
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.

== Directing traffic to LAN servers ==

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.
Such as this for the above example:

pass in quick on xl0 proto tcp from any to 10.0.10.5 port = 80 flags S keep state

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 Special NAT Handling ==
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:

<pre>
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
</pre>

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.

== FTP Filter rules ==
Only one filter rule is needed for FTP if NAT FTP proxy is used

<pre>
# 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
</pre>

Three Filter rules are needed for FTP if no NAT FTP proxy is used

<pre>
# 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
</pre>

[[Category:Securing FreeBSD]]
[[Category:Configuring FreeBSD]]

IPFILTER (IPF) Firewall

2012-08-13T21:26:59Z

173.88.199.104:

== IPFILTER (IPF) Firewall ==
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. IPF’s 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

== Enabling IPF ==
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.

== Kernel options ==
It is not a mandatory requirement that you enable IPF by compiling the following options into the FBSD kernel. It’s 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 it’s 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.

== RC.CONF Options ==
You need the follow statements in /etc/rc.conf to activate IPF at boot time.
<pre>
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

</pre>

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.

<pre>
gateway_enable="YES" # Enable as LAN gateway
ipnat_enable="YES" # Start ipnat function
ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat
</pre>

== IPF COMMAND ==
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.

== IPFSTAT Command ==
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.

== IPMON Command ==
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:

<pre>
ipmon_flags="-Ds" # D = start as daemon
# s = log to syslog
# v = log tcp window, ack, seq
# n = map IP & port to names
</pre>

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.

It’s 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.

== IPMON Logging ==
Syslogd uses its own special method for segregation of log data. It uses special groupings called ‘facility’ and ‘level’. IPMON in –Ds mode uses local0 as the ‘facility’ name. All IPMON logged data goes to local0.

You have to manually configure the /etc/syslog.conf file by adding the statements to direct the Local0 'facility' to the log file name recording the log records. FBSD keeps all of its syslog files in /var/log/ directory.

First allocate the new named log file for the IPFMON 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.

You will have to edit the /etc/syslog.conf file.

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.

To activate the changes to /etc/syslog.conf you can reboot or force the syslogd task into re-reading /etc/syslog.conf by issuing this console command
/etc/rc.d/syslogd reload

Don’t forget to change /etc/newsyslog.conf to rotate the new named IPFILTER log you just created above.

== Format of Logged Messages ==
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).

== Building Rule Script ==
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.
<pre>
############# 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 ########################
</pre>

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

<pre>
#!/bin/sh
sh /etc/ipf.rules.script
</pre>

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.

== IPF Rule Sets ==
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.

== Rule Syntax ==
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

<pre>
# 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.
</pre>
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 it’s 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/ipcalc

port 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 ==
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.

== Inclusive Rule set Example ==
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 don’t 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 don’t 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
<pre>
#################################################################
# 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 ISP’s 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 that’s 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 don’t 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 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.
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 #################################
</pre>

== NAT Explanation ==
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. ISP’s 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 PC’s 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 PC’s 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

== IPNAT Command ==
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.

<pre>
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.
</pre>

== NAT Rules ==
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).

<pre>
# 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.
</pre>

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:

map dc0 10.0.10.1/29 -> 0.32

map = The keyword map starts the rule.

dc0 = The interface name of the interface facing the public Internet.

10.0.10.1/29 = The IP address range of the private LAN.

-> = Mandatory arrow symbol.

0.32 = The IP address/netmask assigned by your ISP.
The special alias keyword 0.32 tells ipnat to get the current public
IP address of the interface specified on this statement and
substitute it for the 0.32 keyword.

== How NAT works ==
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.

== Enabling NAT ==
To enable the IPNAT function add these statements to /etc/rc.conf

<pre>
gateway_enable="YES" # Enable as LAN gateway
ipnat_enable="YES" # Start ipnat function
ipnat_rules="/etc/ipnat.rules" # ipnat rules definition file
</pre>

== NAT for very large LAN ==
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.

== Directing traffic to LAN servers ==

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.
Such as this for the above example:

pass in quick on xl0 proto tcp from any to 10.0.10.5 port = 80 flags S keep state

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 Special NAT Handling ==
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.

== FTP Filter rules ==
Only one filter rule is needed for FTP if NAT FTP proxy is used

<pre>
# 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
</pre>

Three Filter rules are needed for FTP if no NAT FTP proxy is used

<pre>
# 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
</pre>

[[Category:Securing FreeBSD]]
[[Category:Configuring FreeBSD]]

IPFILTER (IPF) Firewall

2012-08-13T21:15:08Z

173.88.199.104:

== IPFILTER (IPF) Firewall ==
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. IPF’s 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

== Enabling IPF ==
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.

== Kernel options ==
It is not a mandatory requirement that you enable IPF by compiling the following options into the FBSD kernel. It’s 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 it’s 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.

== RC.CONF Options ==
You need the follow statements in /etc/rc.conf to activate IPF at boot time.
<pre>
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

</pre>

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.

<pre>
gateway_enable="YES" # Enable as LAN gateway
ipnat_enable="YES" # Start ipnat function
ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat
</pre>

== IPF COMMAND ==
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.

== IPFSTAT Command ==
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.

== IPMON Command ==
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:

<pre>
ipmon_flags="-Ds" # D = start as daemon
# s = log to syslog
# v = log tcp window, ack, seq
# n = map IP & port to names
</pre>

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.

It’s 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.

== IPMON Logging ==
Syslogd uses its own special method for segregation of log data. It uses special groupings called ‘facility’ and ‘level’. IPMON in –Ds mode uses local0 as the ‘facility’ name. All IPMON logged data goes to local0.

You have to manually configure the /etc/syslog.conf file by adding the statements to direct the Local0 'facility' to the log file name recording the log records. FBSD keeps all of its syslog files in /var/log/ directory.

First allocate the new named log file for the IPFMON 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.

You will have to edit the /etc/syslog.conf file.

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.

To activate the changes to /etc/syslog.conf you can reboot or force the syslogd task into re-reading /etc/syslog.conf by issuing this console command
/etc/rc.d/syslogd reload

Don’t forget to change /etc/newsyslog.conf to rotate the new named IPFILTER log you just created above.

== Format of Logged Messages ==
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).

== Building Rule Script ==
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.
<pre>
############# 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 ########################
</pre>

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

<pre>
#!/bin/sh
sh /etc/ipf.rules.script
</pre>

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.

== IPF Rule Sets ==
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.

== Rule Syntax ==
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

<pre>
# 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.
</pre>
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 it’s 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/ipcalc

port 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 ==
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.

== Inclusive Rule set Example ==
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 don’t 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 don’t 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
<pre>
#################################################################
# 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 ISP’s 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 that’s 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 don’t 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 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.
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 #################################
</pre>

[[Category:Securing FreeBSD]]
[[Category:FreeBSD for Servers]]
[[Category:Configuring FreeBSD]]

IPFILTER (IPF) Firewall

2012-08-13T21:11:34Z

173.88.199.104: /* Rule Syntax */

IPFILTER (IPF) Firewall

2012-08-13T21:09:01Z

173.88.199.104:

IPFILTER (IPF) Firewall

2012-08-13T21:02:49Z

173.88.199.104:

IPFILTER (IPF) Firewall

2012-08-13T20:55:04Z

173.88.199.104: /* IPFSTAT Command */

IPFILTER (IPF) Firewall

2012-08-13T20:54:09Z

173.88.199.104: /* IPF COMMAND */

IPFILTER (IPF) Firewall

2012-08-13T20:53:12Z

173.88.199.104: /* RC.CONF Options */

IPFILTER (IPF) Firewall

2012-08-13T20:49:22Z

173.88.199.104: IPFILTER (IPF) Firewall

Firewall

2012-08-13T20:35:45Z

173.88.199.104:

== Firewalls ==
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.

== Firewall Rule Set Types ==
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.

== Firewall Software Applications ==
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.

[[Category:Securing FreeBSD]]
[[Category: FreeBSD Terminology]]

Burncd

2012-08-13T20:03:57Z

173.88.199.104:

NOTE: In Release 9.0 and newer the burncd utility is obsolete and does not function any more. You have to use cdrtools system utilites for writing cd and dvd media.<br>
<br>
pkg_add -r cdrtools

[[Category:FreeBSD for Workstations]]
[[Category:Common Tasks]]

Installing fonts

2012-08-13T20:01:07Z

173.88.199.104:

Install Xfstt through packages

shell# pkg_add -r xfstt

Follow the instructions after xfstt is installed

<pre>
You will have to install your TrueType fonts in

PREFIX/lib/X11/fonts/TrueType

Remember to run the "xfstt --sync" command if you
add fonts while the font server is running.

You should also add the following line to the "Files"
Section of /etc/XF86Config:

FontPath "unix/:7101"
</pre>

Under FreeBSD 5.4 I installed my TrueType fonts in:
/usr/X11R6/lib/X11/fonts/TrueType

shell# xfstt --sync

Now you have to restart X

== For those who have X.Org ==

One can install Truetype fonts just by installing any of the truetype ports in the $PREFXports/x11-fonts
<pre>
# cd /usr/ports/x11-fonts && make search key=truetype
</pre>

Xorg can handle the fonts directly and therefore doesn't require you to use Xfstt.

[[Category:Common Tasks]]