IPFW IPFW Syntax

M

mikhail1

IPFW Syntax

Q1:
From the man page for IPFW:
'A backslash (`\') can be used to escape the dash (`-') character in a service name (from a shell, the backslash must be typed twice to avoid the shell itself interpreting it as an escape character).'

An example of this 'escaping':
/sbin/ipfw add 10190 set 1 count log proto udp src-ip 192.168.64.0/24 src-port netbios\\-ns dst-ip 192.168.64.255 dst-port netbios\\-ns in recv igb3
When executed the echoed command is:
10190 count log proto udp src-ip 192.168.64.0/24 src-port 137 dst-ip 192.168.64.255 dst-port 137 in recv igb3

My question:
Why does the service name, netbios\\-ns, need escaping and src-port does not?
They both contain a 'dash'.


Q2:
Using the same example but altering it such that dst-port netbios\\-ns is replaced with 137 works as expected:
/sbin/ipfw add 10190 set 1 count log proto udp src-ip 192.168.64.0/24 src-port netbios\\-ns dst-ip 192.168.64.255 dst-port 137 in recv igb3
If dst-port 137 is replaced with dst-port 99999999999999
/sbin/ipfw add 10190 set 1 count log proto udp src-ip 192.168.64.0/24 src-port 137 dst-ip 192.168.64.255 dst-port 99999999999999 in recv igb3
on execution shows:
10190 count log proto udp src-ip 192.168.64.0/24 src-port 137 dst-ip 192.168.64.255 dst-port 16383 in recv igb3
AFAICT:
* The binary represntation of dst-port 99999999999999 when trucated to 16 bits gives dst-port 16383.
* There is no bounds checking on a 'port value' and no syntax error for the rule with dst-port 99999999999999

My question:
Should there be bounds checking on the 'port value'?


Q3:
From the man page for IPFW:
COMMAND OPTIONS
The following general options are available when invoking ipfw:
-n Only check syntax of the command strings, without actually passing them to the kernel.

When used for an 'add' rule the interpreted rule is echoed back to the console and so can be visually validated:
/sbin/ipfw -n add 10190 set 1 count log proto udp src-ip 192.168.64.0/24 src-port netbios\\-ns dst-ip 192.168.64.255 dst-port netbios\\-ns in recv igb3
10190 count log proto udp src-ip 192.168.64.0/24 src-port 137 dst-ip 192.168.64.255 dst-port 137 in recv igb3

When used for a 'nat' rule the interpreted rule is NOT echoed back to the console.
/sbin/ipfw -n nat 10000 config if igb0 log same_ports unreg_only reset redirect_port tcp 172.16.31.252:smtp smtp
It is echoed back when option '-n' is removed:
ipfw nat 10000 config if igb0 log same_ports unreg_only reset redirect_port tcp 172.16.31.252:25 25

My question:
Is there any way to have /sbin/ipfw syntax check a 'nat' rule?


Thanks in advanced for any feedback.
 
Q1. The man page description of service names states that the backslash must be typed twice, to avoid the shell itself interpreting it as an escape character. The ipfw command parser then receives 'netbios-ns' as the lookup key for /etc/services instead of 'netbios\-ns'. The other terms 'src-port' and 'dst-port' are individual tokens in the ipfw grammar and do not need an escape character.

Q2. Yes, there should be bounds checking in all cases. At present, there are some cases that do (skipto 999999999 returns an error), and some that don't as shown above.

Q3. Yes, the nat command does not echo with ipfw -n. With ipfw -n the command is parsed and the shell exit value 0 indicates success. However, ipfw does not actually create the nat object. So you do get assurance that the command is correct, just not a visible echo. To create the nat object, re-run the command without -n.
 
Jim B. said:
Q1. The man page description of service names states that the backslash must be typed twice, to avoid the shell itself interpreting it as an escape character. The ipfw command parser then receives 'netbios-ns' as the lookup key for /etc/services instead of 'netbios\-ns'. The other terms 'src-port' and 'dst-port' are individual tokens in the ipfw grammar and do not need an escape character.

Q2. Yes, there should be bounds checking in all cases. At present, there are some cases that do (skipto 999999999 returns an error), and some that don't as shown above.

Q3. Yes, the nat command does not echo with ipfw -n. With ipfw -n the command is parsed and the shell exit value 0 indicates success. However, ipfw does not actually create the nat object. So you do get assurance that the command is correct, just not a visible echo. To create the nat object, re-run the command without -n.
Click to expand...
Thanks for your reponse.
Re your IPFW Primer Document Draft; I am slowly reading it; Good to see this sort of thing for IPFW.

To rephrase Q1:
From the IPFW man page:
LIST OF RULES AND PREPROCESSING
To ease configuration, rules can be put into a file which is processed using ipfw as shown in the last synopsis line. An absolute pathname must be used. The file will be read line by line and applied as arguments to the ipfw utility.

So for a command line such as:
/sbin/ipfw /etc/ipfw_rules
where /etc/ipfw_rules contains:
add 10190 set 1 count log proto udp src-ip 192.168.64.0/24 src-port netbios\\-ns dst-ip 192.168.64.255 dst-port 137 in recv igb3
the output on execution is:
Line 1: invalid source port netbios\\-ns
which is to be expected as it is /sbin/ipfw reading the file not the shell.

Changing the rule based on your reponse to Q1, "The ipfw command parser then receives 'netbios-ns'" such that /etc/ipfw_rules contains:
add 10190 set 1 count log proto udp src-ip 192.168.64.0/24 src-port netbios-ns dst-ip 192.168.64.255 dst-port 137 in recv igb3
the output on execution is:
Line 1: invalid source port netbios-ns

Changing the rule to its representation after the shell has parsed it(and then executes it) such that /etc/ipfw_rules contains:
add 10190 set 1 count log proto udp src-ip 192.168.64.0/24 src-port netbios\-ns dst-ip 192.168.64.255 dst-port 137 in recv igb3
the output on execution is:
10190 count log proto udp src-ip 192.168.64.0/24 src-port 137 dst-ip 192.168.64.255 dst-port 137 in recv igb3
ie. It works correctly.

So /sbin/ipfw, which is reading the rule directly from /etc/ipfw_rules, expects 'netbios\-ns'.

To feed the rule to /sbin/ipfw via the shell requires the blackslash to be escaped via another backslash.

So my question is: Why does /sbin/ipfw require the 'dash' in a service name to be escaped with a backslash?
 
I remember the 'why' now:
From the IPFW man page:
ports: {port | port-port}[,ports]
where:
The `-' notation specifies a range of ports (including boundaries).
 
You must log in or register to reply here.
Back
Top