Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: Ben K <benkloester@gmail.com>, netfilter@vger.kernel.org
Subject: Re: iptables --string-replace
Date: Fri, 21 Jan 2011 11:24:07 +0100	[thread overview]
Message-ID: <4D395EC7.5070408@netfilter.org> (raw)
In-Reply-To: <alpine.LNX.2.01.1101211105350.9744@obet.zrqbmnf.qr>

On 21/01/11 11:09, Jan Engelhardt wrote:
> On Friday 2011-01-21 11:04, Pablo Neira Ayuso wrote:
> 
>> On 17/01/11 04:41, Jan Engelhardt wrote:
>>> On Monday 2011-01-17 03:44, Ben K wrote:
>>>
>>>>> Matching across packets would incur unwanted complexity.
>>>>
>>>> Just curious, does the current string match implementation match
>>>> across packets? If not, then surely adding replace functionality (with
>>>> the same compromise) is not overly complex?
>>>
>>> The string match does indeed not work across packets. I do not know why 
>>> we have it, it won't have much use for stream protocols either and was 
>>> probably devised for datagrams.
>>
>> Could you tell me why is not useful for stream protocols?
> 
> Because the stream may be segmented at about any point, thereby
> splitting the very string the user was trying to match on
> across two packets.

It's not hard to extend the textsearch infrastructure to perform
searches across packets.

Anyway, I don't believe that normal TCP traffic would experience such
splitting, in general.

And there are tons of way to defeat pattern matching filtering, this is one.

>>> I can't say for sure what the original 
>>> authors' intentions were. xt_string also works on the entire IP packet, 
>>> so there is a chance for false positives if one only wants to match 
>>> actual L7 payload.
>>
>> It's easy to extend it to make it start after the IP header. I'll send a
>> patch for this.
>>
>> I guess that it's going to be hard to find some pattern that matches in
>> the IP header, so that false positive that you mention has a very low
>> probability.
> 
> That does of course depend on the length of the pattern.

and the pattern itself.

> If you only search for "GET", you could for example match
> on the sequence number.

That's possible, although quite unlikely.

Even if we start in the payload of the packet, pattern matching
infrastructures still have false positives. This is something you'll
have to live with.

And smart guys will always find the way to by-pass it.

  reply	other threads:[~2011-01-21 10:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-16 22:43 iptables --string-replace Ben K
2011-01-16 23:51 ` Jan Engelhardt
2011-01-16 23:58   ` Ben K
2011-01-17  1:20     ` Jan Engelhardt
2011-01-17  2:44       ` Ben K
2011-01-17  3:41         ` Jan Engelhardt
2011-01-17 10:52           ` Amos Jeffries
2011-01-17 11:27             ` Jan Engelhardt
2011-01-21 10:04           ` Pablo Neira Ayuso
2011-01-21 10:09             ` Jan Engelhardt
2011-01-21 10:24               ` Pablo Neira Ayuso [this message]
2011-01-21 10:25         ` Pablo Neira Ayuso
2011-01-17 13:03 ` /dev/rob0

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D395EC7.5070408@netfilter.org \
    --to=pablo@netfilter.org \
    --cc=benkloester@gmail.com \
    --cc=jengelh@medozas.de \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox