CentOS

An additional note. If the DNS query is done via TCP instead of UDP the string (0000ff0001) offset is at 80 (0x50). So that may be where the 50 came from in stuff I found online before.

Though still doesn't explain why the offset seems to be getting applied as hex.

the offset is supposed to be in decimal

The offset IS in decimal here. Tested twice. Always decimal.

I agree that it is intended to be decimal. None of the documentation suggests otherwise. But it does not work here unless it is provided as hex. And if it is specified as hex (0x36) it gets converted to decimal 54. And thus does not match. Have to enter the hex value as though it is decimal. 36 works for UDP and 50 works for TCP. The respective decimal offsets 54 and 80 do not find a match.

P.S. Updated the other thread with correct UDP offset (36 instead of 32) and added TCP capture.
viewtopic.php?f=51&t=62148&p=261980#p261980

If you output the iptables what does it show for the offset? Does it show the same value that was supplied to create the rule?

example:

Code: Select all

iptables -t raw -nvL
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 STRING match  "|0000ff0001|" ALGO name bm FROM 36 TO 65535

It's exactly the same.

Code: Select all

[root@vmhost ~]# iptables -t nat -I PREROUTING 1 -p udp --dport 53 -m string --hex-string "|01000029|" --algo bm --from 44 --to 48 -j LOG
[root@vmhost ~]# iptables-save | grep string
-A PREROUTING -p udp -m udp --dport 53 -m string --hex-string "|01000029|" --algo bm --from 44 --to 48 -j LOG
[root@vmhost ~]# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 43 packets, 6655 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 STRING match  "|01000029|" ALGO name bm FROM 44 TO 48 LOG flags 0 level 4

What shell are you using?

Everything seems to point to BASH (as expected). The offset also behaves the same when the rule is loaded automatically at boot up from /etc/sysconfig/iptables (or systemctl start iptables).

Code: Select all

[root@VPS1 ~]# echo $SHELL
/bin/bash

[root@VPS1 ~]# ps $$
  PID TTY      STAT   TIME COMMAND
19328 pts/0    Ss     0:00 -bash

[root@VPS1 ~]# ls -la /bin/bash
-rwxr-xr-x. 1 root root 964544 Apr 10 17:53 /bin/bash

[root@VPS1 ~]# lsof -a -p $$ -d txt
-bash: lsof: command not found

[root@VPS1 ~]# ls -la `which /bin/bash`
-rwxr-xr-x. 1 root root 964544 Apr 10 17:53 /bin/bash

[root@VPS1 ~]# echo "$$"
19328

[root@VPS1 ~]# ps -p 19328
  PID TTY          TIME CMD
19328 pts/0    00:00:00 bash

[root@VPS1 ~]# sh -c 'ps -p $$ -o ppid=' | xargs -i readlink -f /proc/\{\}/exe
/usr/bin/bash

[root@VPS1 ~]# sh -c 'ps -p $$ -o ppid=' | xargs ps -o cmd= -p
-bash

May have figured this out.

IP tables is working at the Internet Protocol level. Thus the Ethernet header needs to be subtracted from the offset (14 bytes).

So 54 becomes 40 for UDP DNS queries offset. And 80 (actually 66*) becomes 66 (actually 52*) for TCP DNS queries offset. These decimal offset values work as expected. * See the topic at link below for offset value calculation details.

Did the packet dump in your telnet test include an Ethernet header?

Does this make sense?
Does iptables string matching module discount the Ethernet header?
Does the Ehternet header get removed before iptables processing?

Thanks for your help and any additional insights you (or others) can provide.

Updated:
DNS Query Root ANY (all) Filter
viewtopic.php?t=62148

CentOS

iptables string module; bug?

Re: iptables string module; bug?

Re: iptables string module; bug?

Re: iptables string module; bug?

Re: iptables string module; bug?

Re: iptables string module; bug?

Re: iptables string module; bug?

Re: iptables string module; bug?