1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
|
.LP
.TH ipftest 8
.SH NAME
ipftest - test packet filter rules with arbitary input.
.SH SYNOPSIS
ipftest [-vbdPSTEHX] [-I interface] -r <filename> [-i <filename>]
.SH DESCRIPTION
.LP
.PP
\fBipftest\fP is provided for the purpose of being able to test a set of
filter rules without having to put them in place, in operation and procede
to test their effectiveness. The hope is that this minimises disruptions
in providing a secure IP environment.
.PP
\fBipftest\fP will parse any standard ruleset for use with \fBipf\fP
and apply input, returning output as to the result. However, \fBipftest\fP
will return one of three values for packets passed through the filter:
pass, block or nomatch. This is intended to give the operator a better
idea of what is happening with packets passing through their filter
ruleset.
.PP
When used without eiether of \fB-S\fP, \fB-T\fP or \fB-E\fP,
\fBipftest\fP uses its own text input format to generate "fake" IP packets.
The format used is as follows:
.nf
"in"|"out" "on" if ["tcp"|"udp"|"icmp"]
srchost[,srcport] dsthost[,destport] [FSRPAU]
.fi
.PP
This allows for a packet going "in" or "out" of an interface (if) to be
generated, being one of the three main protocols (optionally), and if
either TCP or UDP, a port parameter is also expected. If TCP is selected,
it is possible to (optionally) supply TCP flags at the end. Some examples
are:
.nf
# a UDP packet coming in on le0
in on le0 udp 10.1.1.1,2210 10.2.1.5,23
# an IP packet coming in on le0 from localhost - hmm :)
in on le0 localhost 10.4.12.1
# a TCP packet going out of le0 with the SYN flag set.
out on le0 tcp 10.4.12.1,2245 10.1.1.1,23 S
.fi
.SH OPTIONS
.IP -v
Verbose mode. This provides more information about which parts of rule
matching the input packet passes and fails.
.IP -d
Turn on filter rule debugging. Currently, this only shows you what caused
the rule to not match in the IP header checking (addresses/netmasks, etc).
.IP -b
Cause the output to be a brief summary (one-word) of the result of passing
the packet through the filter; either "pass", "block" or "nomatch".
This is used in the regression testing.
.IP -I <interface>
Set the interface name (used in rule matching) to be the name supplied.
This is useful with the \fB-P, -S, -T\fP and \fB-E\fP options, where it is
not otherwise possible to associate a packet with an interface. Normal
"text packets" can override this setting.
.IP -P
The input file specified by \fB-i\fP is a binary file produced using libpcap
(ie tcpdump version 3). Packets are read from this file as being input
(for rule purposes). An interface maybe specified using \fB-I\fP.
.IP -S
The input file is to be in "snoop" format (see RFC 1761). Packets are read
from this file and used as input from any interface. This is perhaps the
most useful input type, currently.
.IP -T
The input file is to be text output from tcpdump. The text formats which
are currently supported are those which result from the following tcpdump
option combinations:
.PP
.nf
tcpdump -n
tcpdump -nq
tcpdump -nqt
tcpdump -nqtt
tcpdump -nqte
.fi
.LP
.IP -H
The input file is to be hex digits, representing the binary makeup of the
packet. No length correction is made, if an incorrect length is put in
the IP header.
.IP -X
The input file is composed of text descriptions of IP packets.
.IP -E
The input file is to be text output from etherfind. The text formats which
are currently supported are those which result from the following etherfind
option combinations:
.PP
.nf
etherfind -n
etherfind -n -t
.fi
.LP
.IP -i <filename>
Specify the filename to take input from. Default is stdin.
.IP -r <filename>
Specify the filename from which to read filter rules.
.SH FILES
.SH SEE ALSO
ipf(1), ipf(5), snoop(1m), tcpdump(8), etherfind(8c)
.SH BUGS
Not all of the input formats are sufficiently capable of introducing a
wide enough variety of packets for them to be all useful in testing.
|
