2 edits | reply to KachiWachi
Re: Westell 2200 Firewall Rule Explanation Needed Here is the Help file that the 2200 provides (please excuse the formatting) -
Packet Filtering Firewall User Manual
File/Buffer Format
The RDL file or buffer format is divided into two sections. The
first portion of the file defines any number of keys and associated
values. The second portion contains the filtering rule
definitions.
Key Definition Section
A key definition consists of the key followed by the associated
value. A value is actually a character string. The string is
delimited by the open and close square brackets. An example of a
keyword definition would look like the following.
title [ High security RDL file ] The packet filter engine does not use keys. They are intended to
provide information associated with the file. The user interface
treats the key definition and value pairs as standard text.
Rules Section
The rules section of the RDL file or buffer is delimited by the
begin an end keywords. The rules listed between these
delimiters are parsed and converted to a decision tree data
structure used by the packet filter engine. The rules listed are
implemented sequentially as listed in the RDL source. Once the
packet filter engine finds a match for a rule it will note the
filter action to be taken (pass or drop) and continue to compare the
following rules with the given packet unless otherwise instructed
(see the description of the done action in section
3.2.1.2.3).
Rule Names
RDL rules may be given names. The packet logging facility and the
user interface uses these rule names. A name applies to all rules
following its declaration in the Rules Section until another name is
declared or the end statement. An identifier (one or more
alphanumeric characters beginning with an alpha character) on a line
by itself declares a new name for the following rule(s).
RDL Comments
Comments begin with the # character. The parser ignores
all characters following the comment character to the end of the
line.
RDL Command Syntax
An RDL command consists of a filter keyword followed by a
condition expression optionally followed by one or more action
keywords.
Filter Condition [, Condition2, ] [
>> Action, Action2, ] The filter keyword specifies if the packet will be passed or
dropped. The condition defines the portion of the packet and the bit
string to which it will be compared. The action keyword may specify
additional action(s) to be taken.
Filter Keywords
The RDL filter token may be either passed or dropped.
pass Specifies that the matching
packet is to be passed onto the associated interface or the SENS
MUX.
drop Specifies that the matching
packet will not be forwarded to the associated interface or the
SENS MUX. Condition Keywords
The condition expression determines if the rule is a match for
the given packet.
all Specifies all packets. If the all
condition is specified in a rule, all other conditions are
ignored.
match layer offset
{bit-string[:mask]} Specifies one or
more explicit bit strings and offsets into the layer header to
compare. This keyword is followed by three parameters. The first
numeric parameter is the header layer, valid values include 2
though 4 (Ethernet = 2, ip = 3, tcp/udp/icmp/igmp = 4). The second
numeric parameter is the offset into the packet to begin the
comparison. T and the third third parameter, is the representation
of the bit string and comparision bit maskitself. The bit stringIt
is delimited with the open and close curly braces ({}). A colon
delimits the bit string and mask. If no mask is provided, a mask
value of all ones is assumed. Each byte of the bit string and mask
is represented by a two character hexadecimal number and is
separated by white space from the previous byte
representation.
from | to [addr ip-addr/:mask] | [port port_n
|port >= port_n | port >= port_n]
Specifies particular fields (IP address or
TCP/UDP port number) of the IP header. The from keyword
designates the source fields, and the to keyword designates
the destination fields. One or more "A" descriptors of the
fields and their its contents then follows the keyword. A list of
descriptors is to be separated by colon(s). These field
descriptors include addr (IP address), mask (network mask), and
port (TCP or UDP port number).
addr Specifies the source or
destination IP address field and comparison mask. This keyword
is followed by a IP address in dotted-decimal notation and mask
separated by a forward slash. The mask is a number from 1 to 32
and it signifies how many bits of the IP address are compared.
If no mask is provided, a mask value of 32 is assumed.
port Specifies the source or
destination UDP/TCP port number. This keyword is followed by the
16 bit port number represented hexadecimal or decimal format.
Using the >= or >= operators allows for matching on ranges
of ports. protocol tcp | udp | icmp | igmp |
value Specifies the value of the
protocol field found in the IP header. It is followed by a
parameter that specifies the protocol value. There are built in
keywords for the TCP, UDP, ICMP, and IGMP protocols. If a
different protocol value is required, it may be represented by a
decimal or hexadecimal value between 0 and 255.
tcp Specifies the TCP protocol.
udp Specifies the UDP protocol.
icmp Specifies the ICMP protocol.
igmp Specifies the IGMP
protocol. flags urg | ::ack | :: psh | ::rst | ::syn | ::fin
Specifies some combination of the flag bits
found in the TCP header. The parameters following the keyword
should be represented in a colon delimited list.
igmp-type query |
report Specifies the IGMP packet type
found in the IGMP header. The report type checks for both
version 1 and version 2 type codes. No check is made by the parser
to verify that the IGMP protocol is specified. So it is up to the
user to include the protocol igmp condition in a rule using
the igmp-type condition.
icmp-type request |
reply Specifies the ICMP packet type
found in the ICMP header. No check is made by the parser to verify
that the ICMP protocol is specified. So it is up to the user to
include the protocol icmp condition in a rule using the
icmp-type condition. Action keywords
Specifies any further action to be taken upon a match between the
rule condition and the packet content.
log level Specifies
that the contents of any matching packet header should be recorded
in the log table. The level parameter is a mechanism to
indicate the source of the log entry. This value rule name is
stored with each log entry resulting from this rule. The log may
subsequently be searched or sorted by this valuee rule name. Log
entries appear in the table with a default severity of 0. The
level value is represented by a decimal or hexadecimal
value between 0 and 255.
alert severity [Alert
text] Specifies that the contents of any
matching packet header should be recorded oin the log table with
the corresponding severity value and text explanation. Severity is
a decimal number between 0 and 4. The alert text is delimited by
bracketsBrackets delimit the alert text.
done Specifies that the filtering
engine should stop checking any subsequent rules should this rule
match. This action provides a mechanism to optimize the decision
tree implemented by the filtering engine.
state Specifies that the TCP/ICMP/IGMP
session (particularly the sequence number in the case of TCP and
the packet type and source/destination addresses and ports in the
case of ICMP and IGMP) associated with this packet will be added
to the state table maintained by the filtering engine. As long as
that session remains in the state table all packets associated
with that session are passed without comparing them to the rules
decision tree. The filtering enginestate table logic maintains the
state of the session with successive packets and closes or times
it out (removes it from the state table) whenever
appropriate. --
CPU - DFI 586IPVG, Cyrix MII 433, K6-2/+ 450, i430VX, 128MB EDO.
BIOS patched by BiosMan.
VOL (ex-BA) 768/128, Westell 2200. |
