In order for ipmon to properly work, the kernel option IPFILTER_LOG must be turned on. This command has two different modes it can be used in. Native mode is the default mode when you type the command on the FBSD console command line without the –D flag.
Daemon mode is for when you want to have a continuous system log file available so you can review logging of past events. This is how FBSD and IPFILTER are configured to work together. FBSD has a built in facility to automatically rotate syslogs. That is why outputting the log information to syslogd is better than the default of a regular file. In the rc.conf file you see the ipmon_flags statement uses the "-Ds" flags:
ipmon_flags="-Ds" # D = start as daemon
# s = log to syslog
# v = log tcp window, ack, seq
# n = map IP & port to names
The benefits of logging are obvious. Logging provides the ability to review after the fact information like what packets have been dropped, what addresses they came from, and where they were going, giving you a significant edge in tracking down attackers.
Even with the logging facility enabled, IPF will not generate any rule logging on its own. The firewall administrator decides what rules in the rule set he wants to log and adds the log keyword to those rules. Normally only deny rules are logged.
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.
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:
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
Don’t forget to change /etc/newsyslog.conf to rotate the new named IPFILTER log you just created above.
Fields common to all messages are:
1. The date of packet receipt.
2. The time of packet receipt. This is in the form HH:MM:SS.F, for hours, minutes, seconds, and fractions of a second (which can be several digits long).
3. The name of the interface the packet was processed on, e.g., dc0.
4. The group and rule number of the rule, e.g., @0:17.
These can be viewed with ipfstat -in.
5. The action: p for passed, b for blocked, S for a short packet, n did not match any rules, L for a log rule. The order of precedence in showing flags is:
S, p, b, n, L. A capital P or B means that the packet has been logged due to a global logging setting, not a particular rule.
6. The addresses. This is actually three fields: the source address and port (separated by a comma), the -> symbol, and the destination address and port. 126.96.36.199,80 -> 188.8.131.52,1722.
7. PR followed by the protocol name or number, e.g., PR tcp.
8. len followed by the header length and total length of the packet,
e.g., len 20 40.
If the packet is a TCP packet, there will be an additional field starting with a hyphen followed by letters corresponding to any flags that were set. See the ipf.conf manual page for a list of letters and their flags.
If the packet is an ICMP packet, there will be two fields at the end, the first always being `ICMP' and the next being the ICMP message and sub-message type, separated by a slash, (e.g., ICMP 3/3 for a port unreachable message).
Some experienced IPF users create a file containing the rules and code them in a manner compatible with running them as a script with symbolic substitution. The major benefit of doing this is you only have to change the value associated with the symbolic name, and when the script is run all the rules containing the symbolic name will have the value substituted in the rules. Being a script, you can use symbolic substitution to code frequently used values and substitute them in multiple rules. You will see this in the following example.
The script syntax used here is compatible with the ‘sh’, ‘csh’, and ‘tcsh’ shells.
Symbolic substitution fields are prefixed with a dollar sign $.
Symbolic fields do not have the $ prefix
The value to populate the Symbolic field must be enclosed with "double quotes".
Start your rules file with this.
############# Start of IPF rules script ########################
oif="dc0" # name of the outbound interface
odns="192.0.2.11" # ISP's dns server IP address Symbolic>
myip="192.0.2.7" # My Static IP address from ISP
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
################## End of IPF rules script ########################
That’s all there is to it. The rules are not important in this example; how the Symbolic substitution field are populated and used are. If the above example was in the /etc/ipf.rules.script file, I could reload these rules by entering on the FBSD command line:
There is one problem with using a rules file with embedded symbolics. IPF has no problem with it, but the rc.conf
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
and put the following script in this directory:
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.
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.
Previous Page Next Page
This FreeBSD Install Guide is an public domain HOW-TO. This content may be reproduced, in any form or by any means, and used by all without permission in writing from the author.