Discussion:
pf "string march"
(too old to reply)
g***@OpenBEER.it
2002-07-10 15:20:31 UTC
Permalink
Hi all,

Will exist an option "string match" like there is in iptables in the next
versions of pf?


Thank you, goony
--
goony <***@OpenBEER.it>
"Beer OpenBSD User Group" founder - http://www.OpenBEER.it
KeyID: 1024D/1CDA1B3D
Fingerprint: CDF5 5246 D424 CF61 0330 A516 93F9 4D38 1CDA 1B3D
GnuPG PubKey: http://www.OpenBEER.it/keys/goony.gpg
--
Henning Brauer
2002-07-10 15:42:09 UTC
Permalink
Post by g***@OpenBEER.it
Will exist an option "string match" like there is in iptables in the next
versions of pf?
what should that do?

lookup for some string appearing somewhere in a packet? if it's that, for
sure not.
Mike Frantzen
2002-07-10 15:58:45 UTC
Permalink
Post by g***@OpenBEER.it
Will exist an option "string match" like there is in iptables in the next
versions of pf?
A string match feature leads to a false sense of security. To correctly
implement it such that it can't be evaded by a kiddie, you have to
enable full fragment reassembly and cache the TCP segment boundarys
(where a boundary is up to 1 less byte than the length of the largest
pattern). When TCP packets arrive out of order, you have to cache all
of the packet boundarys until you have enough contiguous data to merge
and run the pattern match.

The most effecient way to do the matching is a combination of a ShiftOr
NFA and Boyer-Moore. But the length of the pattern to search for must
be less than the bits in the machine word. Multi pattern searches are
much more expensive since the worst case decays to O(nm). Or to get
O(n) you have to build a compressed DFA which tend to blow out your
cache and TLB.

I have a marker here if you want to write "DoS me" on your forehead ;-)


The other problem with it is how do you specify the strings to match?
Once a connection creates state, the ruleset isn't evaluated. But TCP
must be statefully tracked to get the segment boundaries.

.mike
Chris Kuethe
2002-07-10 16:15:06 UTC
Permalink
Post by g***@OpenBEER.it
Hi all,
Will exist an option "string match" like there is in iptables in the next
versions of pf?
i can't see the developers putting in junk "like there is in iptables".
packet filters are supposed to filter on headers. read the archives for
other things (random packet drops, etc.) that people have mentioned.

now, if you're really concerned about not having a particular string
show up on your net, go look at hogwash (http://hogwash.sourceforge.net)
that may or may not do what you want, but it's better than cluttering
up pf with garbage (like an xml parser...)

CK
--
Chris Kuethe, GCIA CISSP: Secure Systems Specialist - U of A CNS
office: 157 General Services Bldg. +1.780.492.8135
chris.kuethe@[pyxis.cns.]ualberta.ca

No trees were destroyed in the sending of this contaminant free message; we
do concede a significant number of electrons may have been inconvenienced.
Daniel Hartmeier
2002-07-10 16:23:12 UTC
Permalink
Post by g***@OpenBEER.it
Will exist an option "string match" like there is in iptables in the next
versions of pf?
I'm not familiar with that iptables feature, but if you mean substring
searches (or even regexp matching) in the data part of a packet, I think
that whole concept is flawed.

So you block all TCP packets that contain "badword" in their data
payload. The attacker just splits it into "bad" and "word" and sends
them in separate packets, possibly in reverse order. Your packet filter
sees "word" and "bad" and passes both. The destination host will get
"badword" as if it were sent in one packet. If you block "bad", too, the
attacker sends "d", "a" and "b". You can't possibly block any single
letter without breaking everything. See, it's useless.

This kind of filtering much better fits into a TCP proxy, which deals
with streams of data. Or does iptables actually serialize data before
passing it on?

Or did you mean something else?

Daniel

Loading...