in-kernel layer7 filtering
Hi all, regarding our recurring how do I filter based on URL thread here, and just for everybodies information, have a look here: http://www.linuxvirtualserver.org/software/ktcpvs/ktcpvs.html (I'm not involved, just saw it on freshmeat) best regards Patrick
addendum to ICMP translation problem
Hi, Last week I reported an ICMP translation problem, which occurs if the connection is initiated by a local process. I now further investigated the problem, it doesn't occur: * if the NAT box is a gateway, and the connection is initiated on another box. * if the connection is not initiated, but accepted As SNAT happens at NF_IP_POST_ROUTING, reply translation will be performed at NF_IP_PRE_ROUTING. The following DEBUG output shows what happens (enabled DEBUGP at the top of ip_nat_core.c): icmp reply translation, ct=c3617480, hooknum=0, ctinfo=4 icmp_reply_translation: translating error c396f260 hook 0 dir REPLY, num_manips=2 icmp_reply: manip 0 dir ORIG hook 4 icmp_reply: manip 1 dir REPLY hook 0 icmp_reply: outer DST - 192.168.131.124 As it seems the inner manip is not called, as it is registered to hook 4 (POST_ROUTING, ORIG) As POST_ROUTING will never be called in ORIG-inal direction for this packet, the inner packet is never translated. I see two ways of fixing the issue: * fix icmp_reply_translation() to perform all of its translation at the same time (both the inner and the outer header) * register a NAT hook at LOCAL_IN, and perform translation of packets registered at (POST_ROUTING, ORIG) The first option seems to be doable, the second is a big change, though seems to be cleaner. Opinions? -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: addendum to ICMP translation problem [PATCH]
On Mon, May 27, 2002 at 12:32:32PM +0200, Balazs Scheidler wrote:
As SNAT happens at NF_IP_POST_ROUTING, reply translation will be performed
at NF_IP_PRE_ROUTING. The following DEBUG output shows what happens (enabled
DEBUGP at the top of ip_nat_core.c):
icmp reply translation, ct=c3617480, hooknum=0, ctinfo=4
icmp_reply_translation: translating error c396f260 hook 0 dir REPLY, num_manips=2
icmp_reply: manip 0 dir ORIG hook 4
icmp_reply: manip 1 dir REPLY hook 0
icmp_reply: outer DST - 192.168.131.124
As it seems the inner manip is not called, as it is registered to hook 4
(POST_ROUTING, ORIG)
As POST_ROUTING will never be called in ORIG-inal direction for this packet,
the inner packet is never translated.
I was wrong here. The same manip is applied at different hooks (once at
PRE_ROUTING and once at POST_ROUTING)
I see two ways of fixing the issue:
* fix icmp_reply_translation() to perform all of its translation at the same
time (both the inner and the outer header)
* register a NAT hook at LOCAL_IN, and perform translation of packets
registered at (POST_ROUTING, ORIG)
The first option seems to be doable, the second is a big change, though
seems to be cleaner.
I implemented option #1, and the patch is below. However I'm not 100% sure
that I'm free to translate the inner packet at PREROUTING time. (it must
have had some reasons that it was performed at POST_ROUTING time)
Functionality wise the patch seems to work all-right.
--- ip_nat_core.c.old Mon May 27 04:53:09 2002
+++ ip_nat_core.c Mon May 27 05:00:23 2002
-843,7 +843,7
packet, except it was never src/dst reversed, so
where we would normally apply a dst manip, we apply
a src, and vice versa. */
- if (info-manips[i].hooknum == opposite_hook[hooknum]) {
+ if (info-manips[i].hooknum == hooknum) {
DEBUGP(icmp_reply: inner %s - %u.%u.%u.%u %u\n,
info-manips[i].maniptype == IP_NAT_MANIP_SRC
? DST : SRC,
-854,9 +854,9
info-manips[i].manip,
!info-manips[i].maniptype,
skb-nfcache);
- /* Outer packet needs to have IP header NATed like
- it's a reply. */
- } else if (info-manips[i].hooknum == hooknum) {
+ /* Outer packet needs to have IP header NATed like
+ it's a reply. */
+
/* Use mapping to map outer packet: 0 give no
per-proto mapping */
DEBUGP(icmp_reply: outer %s - %u.%u.%u.%u\n,
--
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: manpages updates
On Sun, May 26, 2002 at 03:48:49PM +0200, Hervé Eychenne wrote: Hi, Here are attached some small fixes for iptables(8) and ip6tables(8) manpages: - TTL target had nothing to do here, as it is in patch-o-matic. Deleted for coherence. Maybe we could have a special manpage for extra extensions, but as they are already documented in the Netfilter Extensions HOWTO, it would seem to appear as a duplicated effort. I just added a note on the existence of this HOWTO. ok. - check option (former -C in ipchains) will never exist (document this in the FAQ, if not done) ok. - owner section was duplicated in the process of merging my previous manpage patch (a bug in the patch tool? ;-) oops. - small typo fixed - some minor cosmetic changes fine. Comments: - strictly speaking, REJECT target for IPv6 is not in mainstream 2.4.18, so it should not have appeared in the ip6tables(8) manpage. I have left it though. well, I should find some time and finish the REJECTv6 and submit it. (°= Hervé Eychenne Thanks, patch applied. -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
Bug: iptables -A INPUT -p TCP --state NEW ! --syn -j DROP
Title: Message Hi, Theresult of the command: iptables -A INPUT -p TCP --state NEW ! --syn -j DROP is Out of memory: Killed process 5166 (iptables). My Linux kernel is 2.4.18, I tried with iptables 1.2.6aand1.2.7-20020525 and the result was the same. Is it a known bug ? Thanks. Jean Bel
[runme extension] Re: manpages updates
[runme patch proposal for patch-o-matic dealing with the man page attached] Hervé Eychenne wrote: - TTL target had nothing to do here, as it is in patch-o-matic. Deleted for coherence. Maybe we could have a special manpage for extra extensions, but as they are already documented in the Netfilter Extensions HOWTO, it would seem to appear as a duplicated effort. I just added a note on the existence of this HOWTO. May I propose we add manpage information to patch-o-matic. It should be possible to use the same kind of magics as for Configure.help.. patchname.man[-X] Where the first line is the existing line where the new documentation should be inserted. Having the patch-o-matic extension you have applied documented in the iptables manpage you have installed as part of the same build process has great value I think. The icky part, shared with .userspace, is that once you have applied pathes from your iptables source you will need to clean it up before patching another kernel source tree.. Regards Henrik
Re: [runme extension] Re: manpages updates
On Mon, May 27, 2002 at 03:29:02PM +0200, Henrik Nordstrom wrote: [runme patch proposal for patch-o-matic dealing with the man page attached] Hervé Eychenne wrote: - TTL target had nothing to do here, as it is in patch-o-matic. Deleted for coherence. Maybe we could have a special manpage for extra extensions, but as they are already documented in the Netfilter Extensions HOWTO, it would seem to appear as a duplicated effort. I just added a note on the existence of this HOWTO. May I propose we add manpage information to patch-o-matic. It should be possible to use the same kind of magics as for Configure.help.. patchname.man[-X] Where the first line is the existing line where the new documentation should be inserted. Having the patch-o-matic extension you have applied documented in the iptables manpage you have installed as part of the same build process has great value I think. The icky part, shared with .userspace, is that once you have applied pathes from your iptables source you will need to clean it up before patching another kernel source tree.. If we really want documentation for the extensions available as a manpage, I'm not sure it should belong to the main iptables(8) manpage. I'd rather have a separate manpage in order to avoid confusion (having a different iptables manpage on every machine on earth doesn't look very appealing from this point of view). But if one day we have an iptables_extensions(8) manpage, there should be only one source of documentation, I think. There's already SGML. Maybe it's the most generic format. So in theory every extension in p-o-m should have a .sgml file, describing the option. Each .sgml file should be used for the generation of the HOWTO and the manpage, etc. I hate duplicated information. Maybe William Stearns will have some good idea about that, considering his work on http://www.stearns.org/pomlist/pom-output.html ? Herve -- _ (°= Hervé Eychenne //) v_/_ WallFire project: http://www.wallfire.org/
[runme man extension, v2] Re: manpages updates
And here is a version of the patch that actually seems to work... (the
previous slotted in the changes slightly wrong.. didn't notice the subtle
error before sending the patch)
Regards
Henrik
Henrik Nordstrom wrote:
And here is the actual patch...
Henrik Nordstrom wrote:
[runme patch proposal for patch-o-matic dealing with the man page
attached]
Hervé Eychenne wrote:
- TTL target had nothing to do here, as it is in patch-o-matic.
Deleted for coherence. Maybe we could have a special manpage for
extra extensions, but as they are already documented in the
Netfilter Extensions HOWTO, it would seem to appear as a
duplicated effort.
I just added a note on the existence of this HOWTO.
May I propose we add manpage information to patch-o-matic. It should be
possible to use the same kind of magics as for Configure.help..
patchname.man[-X]
Where the first line is the existing line where the new documentation
should be inserted.
Having the patch-o-matic extension you have applied documented in the
iptables manpage you have installed as part of the same build process has
great value I think.
The icky part, shared with .userspace, is that once you have applied
pathes from your iptables source you will need to clean it up before
patching another kernel source tree..
Regards
Henrik
Index: patch-o-matic/NEWPATCHES
===
RCS file: /cvsroot/netfilter/userspace/patch-o-matic/NEWPATCHES,v
retrieving revision 1.6
diff -u -r1.6 NEWPATCHES
--- patch-o-matic/NEWPATCHES 12 Nov 2001 08:19:28 - 1.6
+++ patch-o-matic/NEWPATCHES 27 May 2002 13:41:00 -
-23,10 +23,10
once again, eliminate this from your patch file, and create a file
called `foo.patch.configure.help' like so:
- EXACT CONFIG OPTION TO FOLLOW
+ EXACT EXISTING CONFIG OPTION
text to paste in
- Your text will be placed after the config option you indicated
+ Your text will be placed before the config option you indicated
(with a blank line before and after). You can have more than one
of these files, to make multiple entries in different places, by
calling successive ones foo.patch.configure.help*.
-54,6 +54,23
in different places, by calling successive ones
foo.patch.ip{6}_conntrack.h*.
+6) If you have patches to existing iptables userspace files, put these in
+ foo.patch.userspace
+
+7) You should also document the userspace components of your patch in the
+ iptables(8) man page. Write the needed manpage section, and create a file
+ called `foo.patch.man' like so:
+
+ EXACT EXISTING SECTION HEADER
+ text to paste in
+
+ Your text will be placed before the section header you indicated
+ (with a blank line before and after). You can have more than one
+ of these files, to make multiple entries in different places, by
+ calling successive ones foo.patch.man*.
+
+
+
Finally, if you want to have a libipt_foo built, add it to the
Makefile. If you only want it built when the patch is applied, add a
test for your extension in the iptables userspace distribution, called
Index: patch-o-matic/runme
===
RCS file: /cvsroot/netfilter/userspace/patch-o-matic/runme,v
retrieving revision 1.25
diff -u -r1.25 runme
--- patch-o-matic/runme 10 Apr 2002 13:06:28 - 1.25
+++ patch-o-matic/runme 27 May 2002 13:41:01 -
-119,6 +119,70
return 0
}
+# Args: patch file, directory, file to patch
+apply_change_before()
+{
+PRIOR=`head -1 $1`
+LINE=`fgrep -x -n $PRIOR $2/$3 | cut -d: -f1 | head -1`
+if [ -z $LINE ]
+then
+ echo Could not find place to slot in $3 line 2
+ return 1
+fi
+rm -f $2/${3}.tmp
+
+if [ $MODE ]; then
+# Reverse patch
+
+# Need to search for previously inserted lines
+# Might not be immediately under $LINE
+BEGIN=2
+TESTLINE=$BEGIN
+NUMLINES1=`sed -n \$= $1`
+NUMLINES2=`sed -n \$= $2/$3`
+
+while [ $TESTLINE -le $NUMLINES1 ]; do
+NOMATCH=`awk NR==$LINE + $TESTLINE - 1 $2/$3|\
+fgrep -vcx \`sed -n -e ${TESTLINE}p $1\``;
+if [ $NOMATCH -ne 0 ]; then
+LINE=`expr $LINE + $TESTLINE - 1`
+TESTLINE=$BEGIN
+continue
+fi;
+
+TESTLINE=`expr $TESTLINE + 1`;
+
+done;
+
+if [ $LINE -lt $NUMLINES2 ] \
+(awk NR==1,NR==$LINE $2/$3 awk NR==$LINE + $NUMLINES1,NR=0 $2/$3) $2/${3}.tmp
+then
+mv $2/${3}.tmp $2/$3
+echo$3 updated
+return 0
+else
+echo Could not update $3 2
+rm -f $2/${3}.tmp
+return 1
+fi
+fi
+# Apply patch
+# Use awk to properly add newline if last line of code has only spaces
+# Necessary to properly remove inserted code if patch is
Re: [runme extension] Re: manpages updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Nordstrom [EMAIL PROTECTED] writes: Henrik Nordstrom wrote: [runme patch proposal for patch-o-matic dealing with the man page attached] Having the patch-o-matic extension you have applied documented in the iptables manpage you have installed as part of the same build process has great value I think. I think this is an excellent idea. Making the manual document extensions will really help reduce the noise ratio. Now I won't be out of line responding with RTFM to basic usage questions. -BEGIN PGP SIGNATURE- Comment: Keeping the world safe for geeks. iD8DBQE88kIDwBVKl/Nci0oRAsOPAKDvXh6MXGXpZv7/amWiiEnXu/ONhACgvtbI 11ecXCqc0q7t7mZVXlio4do= =Mzlp -END PGP SIGNATURE-
iptables-1.2.6(a) and gcc 3.0 problem
Hello, Compiling iptables-1.2.6a with gcc-3.0.4, I get the following errors: ... ... extensions/libipt_owner.c:23:1: directives may not be used inside a macro argument extensions/libipt_owner.c:23:1: unterminated argument list invoking macro printf ... ... Any help would be appreciated very much. Thank you. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: iptables-1.2.6(a) and gcc 3.0 problem
Compiling iptables-1.2.6a with gcc-3.0.4, I get the following errors: ... ... extensions/libipt_owner.c:23:1: directives may not be used inside a macro argument extensions/libipt_owner.c:23:1: unterminated argument list invoking macro printf As far as I know, this is a glibc + gcc3 bug. Updating to glibc 2.2.5 should solve your problem. greets -silvan
Build RELATED rules/bindings from config file at run-time?
Greetings! I've been poking around looking for any sign of a way to create RELATED bindings from a text file at run-time, and/or via command switches. The idea is that some connections involve related traffic which may originate from a different host than the stream of primary interest, e.g. a SMB file/print/whatever server vs. the PDC, or perhaps an IDENT server vs. some other service. Such a beast might also simplify/streamline the current need for specific helper modules, or allow them to be locked down a bit, e.g. narrower port ranges for ftp DATA streams. I've looked through the modules described in the netfilter-extensions-HOWTO.html as well as the threads from the last few months of this list, and from what I can see nothing quite like this exists. I'm thinking that this sort of thing might doable and useful. Perhaps some hack involving mangling and 'recent' could even work... So, my questions are: Have I missed something else I should read or consider which speaks to this concept? and, in the unlikely event that I haven't, well, how 'bout it? :) Best Regards, Pete.
Re: Build RELATED rules/bindings from config file at run-time?
For this you will currently need to build your own conntrack helper. Protocols having port numbers or IP addresses in their payload will require helpers, but any protocol where the port numbers are well defined should be fully usable with such a generic helper I suppose. IDENT presents a bit of a problem for conntrack IIRC, as it applies to all connections in parallell to the actual application protocol. From what I recall there can only be one helper per port number. On Monday 27 May 2002 22:59, Peter Hartzler wrote: Greetings! I've been poking around looking for any sign of a way to create RELATED bindings from a text file at run-time, and/or via command switches. The idea is that some connections involve related traffic which may originate from a different host than the stream of primary interest, e.g. a SMB file/print/whatever server vs. the PDC, or perhaps an IDENT server vs. some other service. Such a beast might also simplify/streamline the current need for specific helper modules, or allow them to be locked down a bit, e.g. narrower port ranges for ftp DATA streams.
