firewall problem for my DSLmodem/router. [Archive]

roadorange

05-24-2007, 03:37 PM

i read "help" instruction, but it seems difficult. Firewall isn't an easy topic :"(
any firewall expert here???
here i copy/paste the instruction:

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.