* Re: iptables 1.3.4 kernel 2.4.31 string match
[not found] <007a01c60f31$8f1eeaa0$102a2a0a@rjk>
@ 2006-01-02 14:12 ` Pablo Neira Ayuso
2006-01-03 11:40 ` Patrick McHardy
0 siblings, 1 reply; 6+ messages in thread
From: Pablo Neira Ayuso @ 2006-01-02 14:12 UTC (permalink / raw)
To: K. Jay Rogozinsky; +Cc: Netfilter Development Mailinglist
[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]
Hi,
K. Jay Rogozinsky wrote:
> I am hoping contacting you directly is not inappropriate.
No problem. I've cc'ed the reply to netfilter-devel for the record. It
could be useful for others.
> As I understand, iptables 1.3.4 *can* use the kernel string matching
> available starting in kernel 2.6.14.
>
> However, we are using kernel 2.4.31 (which iptables 1.3.4 doc says is OK).
So, I updated the manpage. Attached a patch that applies to netfilter SVN.
> However, according to our "compile guy" (Thomas):
>
> "iptables 1.3.4 does not compile when I have strings matching. That is, the
> string match patch does something that makes iptables 1.3.4 not compile."
iptables doesn't compile the string match if it's not present in the
current kernel, eg. if you compile iptables against a linux kernel <=
2.6.14, the string match won't be compiled.
> So, given that we continue to use kernel 2.4.31, is their any applicable
> patch or approach; We would like to use our kernel (2.4.31) with iptables
> 1.3.4 and still have string matching.
There's no backport available. The only existing way to add support for
string matching is upgrading your kernel at the moment.
--
Pablo
[-- Attachment #2: man.patch --]
[-- Type: text/plain, Size: 889 bytes --]
Index: trunk/iptables/extensions/libipt_string.man
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ trunk/iptables/extensions/libipt_string.man 2006-01-02 13:35:56.000000000 +0100
@@ -0,0 +1,15 @@
+This modules matches a given string by using some pattern matching strategy. It requires a linux kernel >= 2.6.14.
+.TP
+.BI "--algo " "bm|kmp"
+Select the pattern matching strategy. (bm = Boyer-Moore, kmp = Knuth-Pratt-Morris)
+.TP
+.BI "--from " "offset"
+Set the offset from which it starts looking for any matching. If not passed, default is 0.
+.TP
+.BI "--to " "offset"
+Set the offset from which it starts looking for any matching. If not passed, default is the packet size.
+.TP
+.BI "--string " "pattern"
+Matches the given pattern.
+.BI "--hex-string " "pattern"
+Matches the given pattern in hex notation.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iptables 1.3.4 kernel 2.4.31 string match
2006-01-02 14:12 ` iptables 1.3.4 kernel 2.4.31 string match Pablo Neira Ayuso
@ 2006-01-03 11:40 ` Patrick McHardy
0 siblings, 0 replies; 6+ messages in thread
From: Patrick McHardy @ 2006-01-03 11:40 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Netfilter Development Mailinglist, K. Jay Rogozinsky
Pablo Neira Ayuso wrote:
> So, I updated the manpage. Attached a patch that applies to netfilter SVN.
Thanks Pablo, applied.
^ permalink raw reply [flat|nested] 6+ messages in thread
* iptables 1.3.4 kernel 2.4.31 string match
@ 2006-01-03 13:13 Gilles Espinasse
2006-01-04 16:46 ` Pablo Neira Ayuso
0 siblings, 1 reply; 6+ messages in thread
From: Gilles Espinasse @ 2006-01-03 13:13 UTC (permalink / raw)
To: netfilter-devel
[snip]
>> As I understand, iptables 1.3.4 *can* use the kernel string matching
>> available starting in kernel 2.6.14.
>>
>> However, we are using kernel 2.4.31 (which iptables 1.3.4 doc says is OK).
>
>So, I updated the manpage. Attached a patch that applies to netfilter SVN.
>
>> However, according to our "compile guy" (Thomas):
>>
>> "iptables 1.3.4 does not compile when I have strings matching. That is, the
>> string match patch does something that makes iptables 1.3.4 not compile."
>
>iptables doesn't compile the string match if it's not present in the
>current kernel, eg. if you compile iptables against a linux kernel <=
>2.6.14, the string match won't be compiled.
>
>> So, given that we continue to use kernel 2.4.31, is their any applicable
>> patch or approach; We would like to use our kernel (2.4.31) with iptables
>> 1.3.4 and still have string matching.
>
>There's no backport available. The only existing way to add support for
>string matching is upgrading your kernel at the moment.
>
Having done a diff iptables-1.3.3 iptables-1.3.4, I extract the changes related
to string and reverse the patch against iptables-1.3.4.
It does compile and I am starting to test this solution with kernel-2.4.31 and
2.4.32.
Could something prevent this solution to work?
Gilles
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iptables 1.3.4 kernel 2.4.31 string match
2006-01-03 13:13 Gilles Espinasse
@ 2006-01-04 16:46 ` Pablo Neira Ayuso
2006-01-10 20:02 ` Gilles Espinasse
0 siblings, 1 reply; 6+ messages in thread
From: Pablo Neira Ayuso @ 2006-01-04 16:46 UTC (permalink / raw)
To: Gilles Espinasse; +Cc: netfilter-devel
Bonjour,
Gilles Espinasse wrote:
> [snip]
>
>>>As I understand, iptables 1.3.4 *can* use the kernel string matching
>>>available starting in kernel 2.6.14.
>>>
>>>However, we are using kernel 2.4.31 (which iptables 1.3.4 doc says is OK).
>>
>>So, I updated the manpage. Attached a patch that applies to netfilter SVN.
>>
>>
>>>However, according to our "compile guy" (Thomas):
>>>
>>>"iptables 1.3.4 does not compile when I have strings matching. That is, the
>>>string match patch does something that makes iptables 1.3.4 not compile."
>>
>>iptables doesn't compile the string match if it's not present in the
>>current kernel, eg. if you compile iptables against a linux kernel <=
>>2.6.14, the string match won't be compiled.
>>
>>
>>>So, g
iven that we continue to use kernel 2.4.31, is their any applicable
>>>patch or approach; We would like to use our kernel (2.4.31) with iptables
>>>1.3.4 and still have string matching.
>>
>>There's no backport available. The only existing way to add support for
>>string matching is upgrading your kernel at the moment.
>>
>
>
> Having done a diff iptables-1.3.3 iptables-1.3.4, I extract the changes related
> to string and reverse the patch against iptables-1.3.4.
>
> It does compile and I am starting to test this solution with kernel-2.4.31 and
> 2.4.32.
> Could something prevent this solution to work?
The problem is that the kernel part is missing (textsearch
infrastructure + ipt_string). So, that won't work :(
--
Pablo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iptables 1.3.4 kernel 2.4.31 string match
2006-01-04 16:46 ` Pablo Neira Ayuso
@ 2006-01-10 20:02 ` Gilles Espinasse
2006-01-12 11:29 ` Pablo Neira Ayuso
0 siblings, 1 reply; 6+ messages in thread
From: Gilles Espinasse @ 2006-01-10 20:02 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 2392 bytes --]
----- Original Message -----
From: "Pablo Neira Ayuso" <pablo@eurodev.net>
To: "Gilles Espinasse" <g.esp@free.fr>
Cc: "netfilter-devel" <netfilter-devel@lists.netfilter.org>
Sent: Wednesday, January 04, 2006 5:46 PM
Subject: Re: iptables 1.3.4 kernel 2.4.31 string match
> Bonjour,
>
> Gilles Espinasse wrote:
> > [snip]
> >
> >>>As I understand, iptables 1.3.4 *can* use the kernel string matching
> >>>available starting in kernel 2.6.14.
> >>>
> >>>However, we are using kernel 2.4.31 (which iptables 1.3.4 doc says is
OK).
> >>
> >>So, I updated the manpage. Attached a patch that applies to netfilter
SVN.
> >>
> >>
> >>>However, according to our "compile guy" (Thomas):
> >>>
> >>>"iptables 1.3.4 does not compile when I have strings matching. That
is, the
> >>>string match patch does something that makes iptables 1.3.4 not
compile."
> >>
> >>iptables doesn't compile the string match if it's not present in the
> >>current kernel, eg. if you compile iptables against a linux kernel <=
> >>2.6.14, the string match won't be compiled.
> >>
> >>
> >>>So, g
>
> iven that we continue to use kernel 2.4.31, is their any applicable
> >>>patch or approach; We would like to use our kernel (2.4.31) with
iptables
> >>>1.3.4 and still have string matching.
> >>
> >>There's no backport available. The only existing way to add support for
> >>string matching is upgrading your kernel at the moment.
> >>
> >
> >
> > Having done a diff iptables-1.3.3 iptables-1.3.4, I extract the changes
related
> > to string and reverse the patch against iptables-1.3.4.
> >
> > It does compile and I am starting to test this solution with
kernel-2.4.31 and
> > 2.4.32.
> > Could something prevent this solution to work?
>
> The problem is that the kernel part is missing (textsearch
> infrastructure + ipt_string). So, that won't work :(
>
I don't attempt to use the new 'string' code on kernel-2.4.
I just find better to use the previous 'string' version than not be able to
use iptables-1.3.4 with 2.4 kernel
You should have miss the fact I apply the reverse patch
cd $(DIR_SRC)/iptables-1.3.4 && patch -Np1 -R <
$(DIR_SRC)/src/patches/iptables-1.3.4-old-string.patch
In fact I revert to the previous string implentation with the diff
iptables-1.3.3 iptables-1.3.4 applied with -R switch
It was an answer to the original question to use iptables-1.3.4, string
extension and kernel-2.4.x
Gilles
[-- Attachment #2: iptables-1.3.4-old-string.patch --]
[-- Type: application/octet-stream, Size: 8250 bytes --]
Used to revert to old 'string' implementation as it is the only one know by pom for kernel 2.4
diff -Nru iptables-1.3.3/extensions/libipt_string.c iptables-1.3.4/extensions/libipt_string.c
--- iptables-1.3.3/extensions/libipt_string.c 2005-02-19 19:19:17.000000000 +0000
+++ iptables-1.3.4/extensions/libipt_string.c 2005-10-31 19:03:50.000000000 +0000
@@ -2,6 +2,11 @@
*
* Copyright (C) 2000 Emmanuel Roger <winfield@freegates.be>
*
+ * 2005-08-05 Pablo Neira Ayuso <pablo@eurodev.net>
+ * - reimplemented to use new string matching iptables match
+ * - add functionality to match packets by using window offsets
+ * - add functionality to select the string matching algorithm
+ *
* ChangeLog
* 29.12.2003: Michael Rash <mbr@cipherdyne.org>
* Fixed iptables save/restore for ascii strings
@@ -21,36 +26,62 @@
#include <stdlib.h>
#include <getopt.h>
#include <ctype.h>
-
#include <iptables.h>
+#include <stddef.h>
#include <linux/netfilter_ipv4/ipt_string.h>
-
/* Function which prints out usage message. */
static void
help(void)
{
printf(
"STRING match v%s options:\n"
+"--from Offset to start searching from\n"
+"--to Offset to stop searching\n"
+"--algo Algorithm\n"
"--string [!] string Match a string in a packet\n"
"--hex-string [!] string Match a hex string in a packet\n",
IPTABLES_VERSION);
}
-
static struct option opts[] = {
- { .name = "string", .has_arg = 1, .flag = 0, .val = '1' },
- { .name = "hex-string", .has_arg = 1, .flag = 0, .val = '2' },
- { .name = 0 }
+ { "from", 1, 0, '1' },
+ { "to", 1, 0, '2' },
+ { "algo", 1, 0, '3' },
+ { "string", 1, 0, '4' },
+ { "hex-string", 1, 0, '5' },
+ {0}
};
static void
+init(struct ipt_entry_match *m, unsigned int *nfcache)
+{
+ struct ipt_string_info *i = (struct ipt_string_info *) m->data;
+
+ if (i->to_offset == 0)
+ i->to_offset = (u_int16_t) ~0UL;
+}
+
+static void
parse_string(const unsigned char *s, struct ipt_string_info *info)
{
- if (strlen(s) <= BM_MAX_NLEN) strcpy(info->string, s);
- else exit_error(PARAMETER_PROBLEM, "STRING too long `%s'", s);
+ if (strlen(s) <= IPT_STRING_MAX_PATTERN_SIZE) {
+ strncpy(info->pattern, s, IPT_STRING_MAX_PATTERN_SIZE);
+ info->patlen = strlen(s);
+ return;
+ }
+ exit_error(PARAMETER_PROBLEM, "STRING too long `%s'", s);
}
+static void
+parse_algo(const unsigned char *s, struct ipt_string_info *info)
+{
+ if (strlen(s) <= IPT_STRING_MAX_ALGO_NAME_SIZE) {
+ strncpy(info->algo, s, IPT_STRING_MAX_ALGO_NAME_SIZE);
+ return;
+ }
+ exit_error(PARAMETER_PROBLEM, "ALGO too long `%s'", s);
+}
static void
parse_hex_string(const unsigned char *s, struct ipt_string_info *info)
@@ -92,7 +123,7 @@
exit_error(PARAMETER_PROBLEM,
"Bad literal placement at end of string");
}
- info->string[sindex] = s[i+1];
+ info->pattern[sindex] = s[i+1];
i += 2; /* skip over literal char */
literal_f = 0;
} else if (hex_f) {
@@ -114,22 +145,26 @@
if (! sscanf(hextmp, "%x", &schar))
exit_error(PARAMETER_PROBLEM,
"Invalid hex char `%c'", s[i]);
- info->string[sindex] = (char) schar;
+ info->pattern[sindex] = (char) schar;
if (s[i+2] == ' ')
i += 3; /* spaces included in the hex block */
else
i += 2;
} else { /* the char is not part of hex data, so just copy */
- info->string[sindex] = s[i];
+ info->pattern[sindex] = s[i];
i++;
}
- if (sindex > BM_MAX_NLEN)
+ if (sindex > IPT_STRING_MAX_PATTERN_SIZE)
exit_error(PARAMETER_PROBLEM, "STRING too long `%s'", s);
sindex++;
}
- info->len = sindex;
+ info->patlen = sindex;
}
+#define STRING 0x1
+#define ALGO 0x2
+#define FROM 0x4
+#define TO 0x8
/* Function which parses command options; returns true if it
ate an option */
@@ -143,28 +178,48 @@
switch (c) {
case '1':
- if (*flags)
+ if (*flags & FROM)
exit_error(PARAMETER_PROBLEM,
- "Can't specify multiple strings");
-
+ "Can't specify multiple --from");
+ stringinfo->from_offset = atoi(optarg);
+ *flags |= FROM;
+ break;
+ case '2':
+ if (*flags & TO)
+ exit_error(PARAMETER_PROBLEM,
+ "Can't specify multiple --to");
+ stringinfo->to_offset = atoi(optarg);
+ *flags |= TO;
+ break;
+ case '3':
+ if (*flags & ALGO)
+ exit_error(PARAMETER_PROBLEM,
+ "Can't specify multiple --algo");
+ parse_algo(optarg, stringinfo);
+ *flags |= ALGO;
+ break;
+ case '4':
+ if (*flags & STRING)
+ exit_error(PARAMETER_PROBLEM,
+ "Can't specify multiple --string");
check_inverse(optarg, &invert, &optind, 0);
parse_string(argv[optind-1], stringinfo);
if (invert)
stringinfo->invert = 1;
- stringinfo->len=strlen((char *)&stringinfo->string);
- *flags = 1;
+ stringinfo->patlen=strlen((char *)&stringinfo->pattern);
+ *flags |= STRING;
break;
- case '2':
- if (*flags)
+ case '5':
+ if (*flags & STRING)
exit_error(PARAMETER_PROBLEM,
- "Can't specify multiple strings");
+ "Can't specify multiple --hex-string");
check_inverse(optarg, &invert, &optind, 0);
parse_hex_string(argv[optind-1], stringinfo); /* sets length */
if (invert)
stringinfo->invert = 1;
- *flags = 1;
+ *flags |= STRING;
break;
default:
@@ -178,9 +233,13 @@
static void
final_check(unsigned int flags)
{
- if (!flags)
+ if (!(flags & STRING))
+ exit_error(PARAMETER_PROBLEM,
+ "STRING match: You must specify `--string' or "
+ "`--hex-string'");
+ if (!(flags & ALGO))
exit_error(PARAMETER_PROBLEM,
- "STRING match: You must specify `--string' or `--hex-string'");
+ "STRING match: You must specify `--algo'");
}
/* Test to see if the string contains non-printable chars or quotes */
@@ -237,13 +296,18 @@
const struct ipt_string_info *info =
(const struct ipt_string_info*) match->data;
- if (is_hex_string(info->string, info->len)) {
+ if (is_hex_string(info->pattern, info->patlen)) {
printf("STRING match %s", (info->invert) ? "!" : "");
- print_hex_string(info->string, info->len);
+ print_hex_string(info->pattern, info->patlen);
} else {
printf("STRING match %s", (info->invert) ? "!" : "");
- print_string(info->string, info->len);
+ print_string(info->pattern, info->patlen);
}
+ printf("ALGO name %s ", info->algo);
+ if (info->from_offset != 0)
+ printf("FROM %u ", info->from_offset);
+ if (info->to_offset != 0)
+ printf("TO %u", info->to_offset);
}
@@ -254,27 +318,33 @@
const struct ipt_string_info *info =
(const struct ipt_string_info*) match->data;
- if (is_hex_string(info->string, info->len)) {
+ if (is_hex_string(info->pattern, info->patlen)) {
printf("--hex-string %s", (info->invert) ? "! ": "");
- print_hex_string(info->string, info->len);
+ print_hex_string(info->pattern, info->patlen);
} else {
printf("--string %s", (info->invert) ? "! ": "");
- print_string(info->string, info->len);
+ print_string(info->pattern, info->patlen);
}
+ printf("--algo %s ", info->algo);
+ if (info->from_offset != 0)
+ printf("--from-offset %u ", info->from_offset);
+ if (info->to_offset != 0)
+ printf("--to-offset %u ", info->to_offset);
}
static struct iptables_match string = {
- .name = "string",
- .version = IPTABLES_VERSION,
- .size = IPT_ALIGN(sizeof(struct ipt_string_info)),
- .userspacesize = IPT_ALIGN(sizeof(struct ipt_string_info)),
- .help = &help,
- .parse = &parse,
- .final_check = &final_check,
- .print = &print,
- .save = &save,
- .extra_opts = opts
+ .name = "string",
+ .version = IPTABLES_VERSION,
+ .size = IPT_ALIGN(sizeof(struct ipt_string_info)),
+ .userspacesize = offsetof(struct ipt_string_info, config),
+ .help = help,
+ .init = init,
+ .parse = parse,
+ .final_check = final_check,
+ .print = print,
+ .save = save,
+ .extra_opts = opts
};
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iptables 1.3.4 kernel 2.4.31 string match
2006-01-10 20:02 ` Gilles Espinasse
@ 2006-01-12 11:29 ` Pablo Neira Ayuso
0 siblings, 0 replies; 6+ messages in thread
From: Pablo Neira Ayuso @ 2006-01-12 11:29 UTC (permalink / raw)
To: Gilles Espinasse; +Cc: netfilter-devel
Gilles Espinasse wrote:
> I don't attempt to use the new 'string' code on kernel-2.4.
> I just find better to use the previous 'string' version than not be able to
> use iptables-1.3.4 with 2.4 kernel
OK, but the previous code computes the Boyer-Moore shift arrays
everytime a packet is processed. So I doubt about the benefits of such
approach. I warned you.
Amicalement,
--
Pablo
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-01-12 11:29 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <007a01c60f31$8f1eeaa0$102a2a0a@rjk>
2006-01-02 14:12 ` iptables 1.3.4 kernel 2.4.31 string match Pablo Neira Ayuso
2006-01-03 11:40 ` Patrick McHardy
2006-01-03 13:13 Gilles Espinasse
2006-01-04 16:46 ` Pablo Neira Ayuso
2006-01-10 20:02 ` Gilles Espinasse
2006-01-12 11:29 ` Pablo Neira Ayuso
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.