Asking again: string match fails to find anything

Asking again: string match fails to find anything

[gypsy]

Facts:
iptables 1.2.9 built against kernel v 2.4.25 or .26 depending on which
computer.
kernel 2.4.26
os fingerprinting only works on the internal interface,  not eth1.
"tcpdump -n -i eth1 -w /tmp/dump" clearly shows the text I am attempting
to match.
I have a test bed with very little traffic so that using a string match
will not bog down.
Repeats on 3 different computers all running Slackware 9.1.
Several other POM / POM-NG modules are installed.
When I "make modules", the only issue with ipt_string is:
in function `search_sublinear':
:55: warning: subscript has type `char'
:80: warning: subscript has type `char'
(referring to needle and haystack)

Problem:
No matter what text is in $STRING, iptables fails to see the match.

iptables -I INPUT -m string --string $STRING -j LOG

"iptables -nvL | grep STRING" has zeros in the counters.

Example:
Replace $STRING with "oreilly".  From a remote computer run "lynx
http://myurl/oreilly" and variants until at least 30 pages have been
displayed to be certain that at least one packet is not so fragmented
that "oreilly" isn't there (see also Facts above).  On the "myurl"
computer iptables counters are zero.

QUESTION:
How can I find out why the string match fails to find the intended
text?  (Later on I may ask how to fix that...)

gypsy

RE: Asking again: string match fails to find anything

[Jason Opperisano]

is it possible that a rule above your "-m string --string $STRING" is matching the data packets of the connection; i.e, a "-m state --state ESTABLISHED -j ACCEPT" rule?

-j

-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of gypsy
Sent: Tuesday, July 20, 2004 9:57 AM
To: netfilter
Subject: Asking again: string match fails to find anything


Facts:
iptables 1.2.9 built against kernel v 2.4.25 or .26 depending on which
computer.
kernel 2.4.26
os fingerprinting only works on the internal interface,  not eth1.
"tcpdump -n -i eth1 -w /tmp/dump" clearly shows the text I am attempting
to match.
I have a test bed with very little traffic so that using a string match
will not bog down.
Repeats on 3 different computers all running Slackware 9.1.
Several other POM / POM-NG modules are installed.
When I "make modules", the only issue with ipt_string is:
in function `search_sublinear':
:55: warning: subscript has type `char'
:80: warning: subscript has type `char'
(referring to needle and haystack)

Problem:
No matter what text is in $STRING, iptables fails to see the match.

iptables -I INPUT -m string --string $STRING -j LOG

"iptables -nvL | grep STRING" has zeros in the counters.

Example:
Replace $STRING with "oreilly".  From a remote computer run "lynx
http://myurl/oreilly" and variants until at least 30 pages have been
displayed to be certain that at least one packet is not so fragmented
that "oreilly" isn't there (see also Facts above).  On the "myurl"
computer iptables counters are zero.

QUESTION:
How can I find out why the string match fails to find the intended
text?  (Later on I may ask how to fix that...)

gypsy

Re: Asking again: string match fails to find anything

[gypsy]

Jason Opperisano wrote:
> 
> is it possible that a rule above your "-m string --string $STRING" is matching the data packets of the connection; i.e, a "-m state --state ESTABLISHED -j ACCEPT" rule?
> 
> -j
            |
No.  That   V "I" down there says not.
> iptables -I INPUT -m string --string $STRING -j LOG
            ^
            |
Gypsy

RE: Asking again: string match fails to find anything

[Jason Opperisano]

This isn't an actual answer to your question--but I think your problem *may* be a userland/kernel/version/compile problem (which I have no business answering) vs. a configuration syntax problem.

What I can tell you--I hopped on a test machine (a suse 9.0 machine):

# uname -a
Linux test-fw 2.4.21-199-default #1 Fri Mar 12 08:27:41 UTC 2004 i686 i686 i386 GNU/Linux

# iptables -V
iptables v1.2.8

# iptables -I FORWARD -m string --string testing -j LOG --log-prefix "FW STRING: "

I then hit http://my.site.behind.this.firewall/testing/ from an external machine...

And these showed up in the logs:

Jul 21 03:01:23 test-fw kernel: FW STRING: IN=eth1 OUT=eth0 SRC=clientip DST=serverip LEN=543 TOS=0x00 PREC=0x00 TTL=39 ID=39276 DF PROTO=TCP SPT=40746 DPT=80 WINDOW=5840 RES=0x00 ACK PSH URGP=0

Jul 21 03:01:23 test-fw kernel: FW STRING: IN=eth0 OUT=eth1 SRC=serverip DST=clientip LEN=889 TOS=0x00 PREC=0x00 TTL=63 ID=32019 DF PROTO=TCP SPT=80 DPT=40746 WINDOW=6432 RES=0x00 ACK PSH URGP=0

So, the theory works--it matched in both a request and a reply.  And the rule syntax you posted appears to be valid...

Like I said--not an answer, but maybe someone else on the list can shed some light on your specific kernel/iptables/pom version and maybe a possible issue with string matching?

-j

-----Original Message-----
From: gypsy [mailto:gypsy@iswest.com] 
Sent: Wednesday, July 21, 2004 2:08 AM
To: Jason Opperisano; netfilter
Subject: Re: Asking again: string match fails to find anything


Jason Opperisano wrote:
> 
> is it possible that a rule above your "-m string --string $STRING" is matching the data packets of the connection; i.e, a "-m state --state ESTABLISHED -j ACCEPT" rule?
> 
> -j
            |
No.  That   V "I" down there says not.
> iptables -I INPUT -m string --string $STRING -j LOG
            ^
            |
Gypsy

Re: Asking again: string match fails to find anything

[gypsy]

Jason Opperisano wrote:
> Like I said--not an answer, but maybe someone else on the list can shed some light on your specific kernel/iptables/pom version and maybe a possible issue with string matching?

I'm pointing a finger at gcc 3.3.3 for lack of a better idea.  It is one
of the commonalities on the 3 machines where I'm having problems.

1) Do you know what version of gcc compiled SuSE 9?
2) Did I miss something in POM?  (Is there more than 1 version of string
match there?)

Thanks for your input!

Gypsy