string match -> new option

string match -> new option

[macadanet]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1333 bytes --]


Hi.

I'm sorry for my english

I modificated ipt_string.c and I created a new patch. This patch
acepts regular expresions.

For example:

iptables -A INPUT -m string --string '"GET"[0-9]"HTTP"' -j LOG

If some package includes the string: GET ???????8????????? HTTP
the system will write in log file.

It's a good idea, for firewalls between WAN network (Internet) and LAN
network where exists some IIS server (Internet Information Servers).
This server are great bugs when received bad requests like:

"http://www.servidor.com/msadc/..%c0%af../..%c0%af../..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\"
attack with Unicodes


GET http://<ipaddress>/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7
801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%
u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0
Red Code Virus.

this solution can be apply to diferents kind servers.


What do people think? Is a good idea?


Thanks for read this (my) email.


___________________________________________________
Yahoo! Móviles
Personaliza tu móvil con tu logo y melodía favorito 
en http://moviles.yahoo.es

Re: string match -> new option

[Patrick Schaaf]

> I modificated ipt_string.c

Sigh. Why is it that people must work on the pieces that others
already abandoned as fundamentally broken? See my point 1), below.

> This patch acepts regular expresions.

It was only a question of time...

> For example:
> 
> iptables -A INPUT -m string --string '"GET"[0-9]"HTTP"' -j LOG

> If some package includes the string: GET ???????8????????? HTTP
> the system will write in log file.

> What do people think? Is a good idea?

1) it is mostly a bad idea to use the string match at all, as it does
   not reassemble a TCP stream, and thus strings that happen to be
   broken up in two TCP segments, are not matchable. This is a
   fundamental limitation, making any security you get out of
   such a rule dubious, best-effort, only-in-good-weather pseudo
   security.
2) The string in your example, above, is not in a common form I would
   recognize as a regular expression - or your example is wrong, and the
   expression won't match that string. I assume that you invented an
   ad-hoc a-bit-similar-to-regexp matching and syntax, right?
   That's a bad idea. Yet another language to learn (or better ignore).
3) It is a bad idea to use the same --string option as before but
   totally change the interpretation of the string. See the other
   string extension proposal discussed right now. Use a new, extra
   option, or better yet, write a totally new match.
4) It is probably a bad idea, once you analyze the runtime overhead
   imposed by full packet regexp matching. But this would have to
   be quantified, it's just a feeling. It will DEFINITELY become
   really interesting to analyze when you solve points 1 (reassembly
   of TCP stream) and 2 (real regexpen), due to all the deep
   backtracking that regexpen could do. Also watch the severely
   limited kernel stack, if your implementation happens to be
   a naive recursive one! You won't want a slightly more complex
   packet to crash the kernel due to stack exhaustion!

best regards
  Patrick

Re: string match -> new option

[Michael Rash]

On Mar 01, 2003, Patrick Schaaf wrote:

> > If some package includes the string: GET ???????8????????? HTTP
> > the system will write in log file.
> 
> > What do people think? Is a good idea?
> 
> 1) it is mostly a bad idea to use the string match at all, as it does
>    not reassemble a TCP stream, and thus strings that happen to be
>    broken up in two TCP segments, are not matchable. This is a
>    fundamental limitation, making any security you get out of
>    such a rule dubious, best-effort, only-in-good-weather pseudo
>    security.

Agreed, if the expectation is that doing string matching is going to
act as a full-blown NIDS (which, as you point out, it certainly
can't).

Having string matching is nice though since allows me to detect
_some_ signatures without having to run a full-blown NIDS, and I can
do it directly within iptables itself.  Being able to reject (or at
least log) the latest Code xxx packets traversing my iptables
interfaces with a single rule is useful.

--Mike

Michael Rash
http://www.cipherdyne.com
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F

Re: string match -> new option

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

On Sat, Mar 01, 2003 at 07:39:48AM +0100, Patrick Schaaf wrote:
> > I modificated ipt_string.c
> 
> Sigh. Why is it that people must work on the pieces that others
> already abandoned as fundamentally broken? See my point 1), below.
> 
> > This patch acepts regular expresions.
> 
> It was only a question of time...

please, again:

Look at 'libqsearch' from Philipe Biondi.  (I don't have the URL here
right now, but 'libqsearch' + 'kernel' on google gives you the result).

This is the way to do pattern matching on TCP streams in the kernel...

> best regards
>   Patrick

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: string match -> new option

[Patrick Schaaf]

> Look at 'libqsearch' from Philipe Biondi.  (I don't have the URL here
> right now, but 'libqsearch' + 'kernel' on google gives you the result).

Thanks for the pointer! The homepage is at

	http://www.cartel-securite.fr/pbiondi/libqsearch.html

> This is the way to do pattern matching on TCP streams in the kernel...

Looks good at first glance, as a fast parallel pattern matcher. Really nice.

However, for full generality in application to TCP streams, one would
at least need an additional, upfront reorder step, to bring the
stream's packets into the correct order. If a packet it missing,
in the sequence, the search must be paused, with the question
of what to do with the already arrived head-of-sequence packet
(the packet after the perceived gap).

I still feel that such logic has already been implemented in the form
of the local network stack TCP layer; it would be wrong to reimplement
all of that in a separate stream matcher. That's why REDIRECT is my
preferred approach: it gets the packets through the TCP layer.

Thus, the critical question, to me, is less in the matching, than in
how to architect such a matching machinery above the TCP stack, without
paying the cost of a user level interface / application level gateway.
As occasionally mentioned, I think khttpd and the Tux web server are
the correct "role models" for a total solution to this really frequently
asked question. How to fit such a kernel daemon approach into configuration
by iptables?

Note that I don't feel like implementing anything like that, myself. No need,
no motivation.

best regards
  Patrick