another netfilter ICMP bug
Hi, I've encountered another ICMP translation problem in netfilter. This time it occurs when a process initiates a connection and it is translated on the same host. How to reproduce: Box A -- Box B 192.168.131.124 192.168.131.1 Routes back 10.0.0.0/24 using 192.168.131.124 as gateway iptables -t nat -A POSTROUTING -p tcp -s 192.168.131.124 --sport \ -j SNAT --to-source 10.0.0.1 and nc -s 192.168.131.124 -p 192.168.131.1 80 The connection works as expected if Box B accepts connections on port 80, but if I cause Box B to send an ICMP port unreachable back: (boxb was using ipchains in my case therefore the ipchains command line) boxb# ipchains -s 10.0.0.0/24 -d 0/0 80 -j REJECT The source address within the ICMP port unreachable is not rewritten as the following LOG output shows. (to trigger the LOG output I added another rule to INPUT: iptables -A INPUT -p icmp -j LOG): IN=eth0 OUT= MAC=00:50:56:bb:83:25:00:50:bf:0b:f6:2f:08:00 \ SRC=192.168.131.1 DST=192.168.131.124 LEN=88 TOS=0x00 \ PREC=0xC0 TTL=255 ID=26730 PROTO=ICMP TYPE=3 CODE=3 \ [SRC=10.0.0.1 DST=192.168.131.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=53526 DF PROTO=TCP SPT= DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 ] -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: endianess issue in newnat
Hi Roberto, On Thu, 23 May 2002, Roberto Romano wrote: I just want to report an endiannes issue found with 2.4.18+newnat running on a PPC architecture. The problem comes from a change in the definition of both ip_conntrack_manip and ip_conntrack_tuple structures. (kernel/include/linux/netfilter_ipv4/ip_conntrack_tuple.h) In old nat they both contained an union u of 16bits width. With newnat this union u is now 32bits width. Not the newnat patch but the ppt-conntrack-nat patch modifies ip_conntrack_tuple.h as you described. Thank you for reporting the problem! Regards, Jozsef - E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED] WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary
oops when conntrack entry times out
Hi, I've run into a problem, which causes an Ooops during ip_nat_cleanup_conntrack(). I call ip_nat_setup_info() from my PREROUTING hook (right after conntrack, and before nat), everything works correctly, NAT is applied to both directions. The oops occurs exactly when the conntrack entry times out (I was looking at /proc/net/ip_conntrack). The backtrace shows that a NULL pointer is dereferenced in ip_nat_cleanup_conntrack() at this line: LIST_DELETE(bysource[hash_by_src(conn-tuplehash[IP_CT_DIR_ORIGINAL] .tuple.src, conn-tuplehash[IP_CT_DIR_ORIGINAL] .tuple.dst.protonum)], info-bysource); As it seems either info-bysource-prev or info-bysource-next is NULL. Anyone with an idea why this might happen? The same code works if I call ip_nat_setup_info() from POSTROUTING. I can't see the difference between simple DNAT (which works), from my TPROXY DNAT, which works but oopses. Anyone with an idea? -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Filtering SOAP and other 'Web service' protocols
I'm sure this issue must have come up before, but I've searched the archives and haven't found anything... The issue: Traditionally different services have been exposed on different ports, and consequently a perimeter firewall has been able to shield specific services on the protected hosts simply by blocking packets destined to those ports. SOAP (and Web services generally) defeat this technique by overloading port 80 to expose a variety of services. Because SOAP has no real security model, poorly written handlers for SOAP requests represent a real security risk. Consequently it isn't sufficient to filter packets based on port. At the same time it doesn't seem to me that a proxy based approach is a sufficient response to the SOAP problem, partly because we may have legitimate reasons for allowing particular machines within our protected networks to receive particular types of SOAP messages, while blocking the same types of messages destined for other machines, and blocking other types of SOAP messages destined for the same machines. What I'm looking for is an open source (preferably GPL) project to build a proxy-type filter to interwork with netfilter so that packets addressed to selected ports can be buffered until enough information has been read to determine whether or not they are SOAP requests, and then, if they are, to filter them based on content details such as, for example, the XML namespaces declared. If there already is a project doing this, that's great, I want to join it. If there's some reason I haven't thought of why the project is either redundent or impossible, that's great, I'd like to know it. If it isn't redundent and it isn't impossible and no-one's yet doing it, that's great, I'll start one. Anybody? Cheers Simon -- [EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/ Morning had broken, and there was nothing we could do but wait patiently for the RAC to arrive.
[Fwd: Re: Filtering SOAP and other 'Web service' protocols]
Damn reply button (*mutter*) Simon Brooke said: I'm sure this issue must have come up before, but I've searched the archives and haven't found anything... The issue: Traditionally different services have been exposed on different ports, and consequently a perimeter firewall has been able to shield specific services on the protected hosts simply by blocking packets destined to those ports. When companies say works with firewalls I think they mean works *through* firewalls. It serves as a reminder that security is a process and not just a technology (like a firewall). SOAP (and Web services generally) defeat this technique by overloading port 80 to expose a variety of services. Because SOAP has no real security model, poorly written handlers for SOAP requests represent a real security risk. Consequently it isn't sufficient to filter packets based on port. At the same time it doesn't seem to me that a proxy based approach is a sufficient response to the SOAP problem, partly because we may have legitimate reasons for allowing particular machines within our protected networks to receive particular types of SOAP messages, while blocking the same types of messages destined for other machines, and blocking other types of SOAP messages destined for the same machines. What I'm looking for is an open source (preferably GPL) project to build a proxy-type filter to interwork with netfilter so that packets addressed to selected ports can be buffered until enough information has been read to determine whether or not they are SOAP requests, and then, if they are, to filter them based on content details such as, for example, the XML namespaces declared. Are you sure you want to do this at the netfilter level. Netfilter will allow you to redirect packets through a user space handler but that seems ineffiecent if your dealing with volumes of traffic. Why not just deal with it at the application level with a proxy type solution and leave netfilter out of this particular loop? Maybe there is something you could do with squid? If there already is a project doing this, that's great, I want to join it. If there's some reason I haven't thought of why the project is either redundent or impossible, that's great, I'd like to know it. If it isn't redundent and it isn't impossible and no-one's yet doing it, that's great, I'll start one. I've seen it mentioned on a GNU mailing list somewhere. Try checking out freshmeat and sourceforge first? Alex www.bennee.com/~alex/ Alex www.bennee.com/~alex/
Re: [Fwd: Re: Filtering SOAP and other 'Web service' protocols]
What I'm looking for is an open source (preferably GPL) project to build a proxy-type filter to interwork with netfilter so that packets addressed to selected ports can be buffered until enough information has been read to determine whether or not they are SOAP requests, and then, if they are, to filter them based on content details such as, for example, the XML namespaces declared. Are you sure you want to do this at the netfilter level. Netfilter will allow you to redirect packets through a user space handler but that seems ineffiecent if your dealing with volumes of traffic. Why not just deal with it at the application level with a proxy type solution and leave netfilter out of this particular loop? Maybe there is something you could do with squid? Maybe you can use apache 2.0 filters. It looked like they made something nice out of that. If there already is a project doing this, that's great, I want to join it. If there's some reason I haven't thought of why the project is either redundent or impossible, that's great, I'd like to know it. If it isn't redundent and it isn't impossible and no-one's yet doing it, that's great, I'll start one. I've seen it mentioned on a GNU mailing list somewhere. Try checking out freshmeat and sourceforge first? Alex www.bennee.com/~alex/ Alex www.bennee.com/~alex/
Re: Filtering SOAP and other 'Web service' protocols
SOAP (and Web services generally) defeat this technique by overloading port 80 to expose a variety of services. Because SOAP has no real security model, poorly written handlers for SOAP requests represent a real security risk. Consequently it isn't sufficient to filter packets based on port. Yes. This is exactly the same problem as with RPC, recast in an even more stupid setting for easy firewall piercing. I personally prefer to stay away from such protocol stupidity, but acknowledge that that's usually not concidered an option. At the same time it doesn't seem to me that a proxy based approach is a sufficient response to the SOAP problem, partly because we may have legitimate reasons for allowing particular machines within our protected networks to receive particular types of SOAP messages, while blocking the same types of messages destined for other machines, and blocking other types of SOAP messages destined for the same machines. I don't see that as a reason against a proxy based approach. Can you describe why a proxy (of course specialized to understand SOAP messages) would not be able to work? What I'm looking for is an open source (preferably GPL) project to build a proxy-type filter to interwork with netfilter so that packets addressed to selected ports can be buffered until enough information has been read to determine whether or not they are SOAP requests, and then, if they are, to filter them based on content details such as, for example, the XML namespaces declared. The general topic has been discussed here numerous times in the past, always with the same result: it is considered wasted effort. We never heard again from the proponents after their final but I'm going to do it. The main task you set out to solve, is understanding and policing SOAP messages. Your task will be tremendously easier if you attack it first in a normal userspace proxy software. Once you have a good solution there, and its performance is not good, then a kernel-based approach may be sensible. Until then, looking at the kernel side is pure procrastination. The problem to solve is another one: SOAP policing in general. I personally feel (without having looked at SOAP in too much detail) that such a policing should always be in userlevel, for security reasons. There is nothing rootish in the task, but it will be quite complex, and the resulting software pretty fragile for the first years of its life. You want such a beast in a chroot cage on an unused uid in userlevel, not right in the middle of the filtering engine in the kernel, where buffer overflows and similar things wreak havoc of the whole security of the box. See bugtrack WRT iptables vulnerabilities: they involved the easy case of simple protocol NAT helpers, which solve the same thing you ask for in a much more simplistic setting. And there were bugs. How much more would there be for such a stream-reassembling SOAP thing? BTW, it is tradition now that Fabrice MARIE will post almost the same thing on this topic as I did above. Don't be surprised. :-) best regards Patrick
Re: Filtering SOAP and other 'Web service' protocols]
On Thursday 23 May 2002 1:59 pm, [EMAIL PROTECTED] wrote: Simon Brooke said: What I'm looking for is an open source (preferably GPL) project to build a proxy-type filter to interwork with netfilter so that packets addressed to selected ports can be buffered until enough information has been read to determine whether or not they are SOAP requests, and then, if they are, to filter them based on content details such as, for example, the XML namespaces declared. Are you sure you want to do this at the netfilter level. Netfilter will allow you to redirect packets through a user space handler but that seems ineffiecent if your dealing with volumes of traffic. Why not just deal with it at the application level with a proxy type solution and leave netfilter out of this particular loop? Maybe there is something you could do with squid? I think I want to do it at user-space-handler-over-netfilter level. Reason? Suppose we have a network topology like this: A B C D | | | | +---+---+---+---+ | [firewall] | +---+---+---+---+ | | | | W X Y Z We'll suppose A, B, C and D are 'our' hosts, and W, X, Y and Z are 'their' (untrusted) hosts. Furthermore, we know our own network well enough to know that we can't absolutely guarantee that the user of node 'C', a laptop plugged in on a hot desk, hasn't loaded some godawful crap onto his machine while at home, and the user of node 'D', an accountant who fancies himself as a spreadsheet guru, hasn't played about with the 'web services' bits of the Excel scripting stuff. Meantime, host 'A' is our accounts department machine, which is allowed to send and receive billing enquiries via SOAP, and host 'B' is our warehouse server, which is allowed to send and receive stlock level enquiries via SOAP. So some types of SOAP message sent to host 'A' are valid, but all others should be blocked; and any SOAP messages sent to 'C' and 'D' may be blocked. Now I can perfectly easily see that we can require all 'our' hosts to use a proxy server, and refuse to route outward packets to port 80 unless they come from the proxy server; and I can see how we can route all inbound packets destined to port 80 to a proxy server. But I don't see how the proxy server can then discriminate which of our hosts the message (if allowed) should be routed on to. This may, of course, be because I'm stupid. If I am, please say so. So it seems to me that the best thing to do is to get netfilter to hand off port 80 (or other designated ports) to a user space handler, and for that user space handler to buffer the requests until it has enough information to make a block or pass decision. Yes, I agree that this is going to take some horsepower... I've seen it mentioned on a GNU mailing list somewhere. Try checking out freshmeat and sourceforge first? I'd already checked. Sadly, no project on either Freshmeat or Sourceforge matches both 'Firewall' and 'SOAP'. This may, of course, mean that I'm beating up the wrong tree. There is a project called 'proxy' at URL: https://sourceforge.net/projects/proxy which claims to be '...an IP filtering proxy server for Linux...' and which I'll have a look at. Anyone know anything about this? Cheers Simon -- [EMAIL PROTECTED] (Simon Brooke) http://www.jasmine.org.uk/~simon/ Morning had broken, and there was nothing we could do but wait patiently for the RAC to arrive.
Re: Filtering SOAP and other 'Web service' protocols]
I think I want to do it at user-space-handler-over-netfilter level. Reason? Suppose we have a network topology like this: A B C D | | | | +---+---+---+---+ | [firewall] | +---+---+---+---+ | | | | W X Y Z We'll suppose A, B, C and D are 'our' hosts, and W, X, Y and Z are 'their' (untrusted) hosts. Furthermore, we know our own network well enough to know that we can't absolutely guarantee that the user of node 'C', a laptop plugged in on a hot desk, hasn't loaded some godawful crap onto his machine while at home, and the user of node 'D', an accountant who fancies himself as a spreadsheet guru, hasn't played about with the 'web services' bits of the Excel scripting stuff. Meantime, host 'A' is our accounts department machine, which is allowed to send and receive billing enquiries via SOAP, and host 'B' is our warehouse server, which is allowed to send and receive stlock level enquiries via SOAP. So you have already made a fundamental design error. You did not isolate A and B from C and D, network-wise. The not-really-trusted notebook can do IP address takeover games against A and B. You are f**cked. So some types of SOAP message sent to host 'A' are valid, but all others should be blocked; and any SOAP messages sent to 'C' and 'D' may be blocked. So you block anything incoming to C and D, and seperate them from A's network, so they can't do IP takeover of A. This leaves you with protection of the SOAP application on A. Wouldn't that application server be the natural point where you control what type of message to accept? Why should it implement more SOAP functionality than intended? I don't see any requirement for a firewall based SOAP handling, here. (If this thread continues along these lines, it would be better to move it to the normal netfilter mailing list.) best regards Patrick
Re: Filtering SOAP and other 'Web service' protocols]
Simon Brooke wrote: I think I want to do it at user-space-handler-over-netfilter level. Which is supported just fine for a proxy approach by the NAT framework.. So some types of SOAP message sent to host 'A' are valid, but all others should be blocked; and any SOAP messages sent to 'C' and 'D' may be blocked. No problem, just write the needed proxy and add some access control rules to it to filter what should be allowed where. Now I can perfectly easily see that we can require all 'our' hosts to use a proxy server, and refuse to route outward packets to port 80 unless they come from the proxy server; and I can see how we can route all inbound packets destined to port 80 to a proxy server. But I don't see how the proxy server can then discriminate which of our hosts the message (if allowed) should be routed on to. This may, of course, be because I'm stupid. If I am, please say so. By running the proxy on the iptables box (or a nearby box also running iptables, and route the port80 traffic there). Then NAT the connections to the (local) address of the proxy. A proxy running on the host where you do netfilter NAT can easily query netfilter for the originally intended destination. So it seems to me that the best thing to do is to get netfilter to hand off port 80 (or other designated ports) to a user space handler, and for that user space handler to buffer the requests until it has enough information to make a block or pass decision. Entirely possible using the QUEUE approach. But I would probably recommend writing a proxy.. If using QUEUE then you would need your own TCP stream reassembly routines to be able to analyze the TCP data stream. Regards Henrik
Synchonization problem
Hi coders, I know a beter place is the the kernel-development list but its netfilter related I created my own logging system for netfilter but sometimes i run into a deadlock and i think i found it but i'm not sure... My netfilter log calls are on various places in netfilter and those funtions post messages to MyQueue this queue is threadsafe and at the otherside of MyQueue a scheduled task is active that do some processing before it sees daylight in userspace. So lets concentrate on MyQueue. On one site, the netfilter stuff (running bottom half?) and on the otherside a task that is scheduled every 100ms to process MyQueue (via schedule_task() ) I made MyQueue threadsafe with a mutex and it results in a deadlock of the complete kernel. I assume the scheduled task is in the mutex of MyQueue and than an interrupt comes that results in netfilter activity which i want to log and that hits the mutex of MyQueue that is in use by my scheduled task. Before the netfilter can go further first the schedule stask have to finish but there is no context switch since the netfilter is bottomhalf (am i right?) I tried it also with spinlocks and using spin_lock and spin_unlock calls but this make no sense for my single processor machine, it even lock faster and harder. I would use the spin_lock_bh and the spin_unlock_bh but this resulted in a compilor error undefined reference to: local_bh_disable I would like to know how to synchonize between netfilter (bottomhalf) and the scheduled task, without disabling all the interrupts. Thanx for your help, Andre _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
Re: endianess issue in newnat
On Thu, May 23, 2002 at 10:38:33AM +0200, Roberto Romano wrote: Hello, I just want to report an endiannes issue found with 2.4.18+newnat running on a PPC architecture. this turns out to be strange, since most parts of newnat have been developed on powerpc architecture. As Jozsef already pointed out, it is the PPTP patch which is the culprit. In old nat they both contained an union u of 16bits width. With newnat this union u is now 32bits width. This breaks code where the union is still initialized with 16bits values as if the whole union size was still equal to its port element. this is true, indeed. While I was aware of this, I thought I had fixed all respective code parts. Maybe something got lost before creating the final patch :( One possible fix for this chunck of code could be: exactly true. There is multiple places in newnat code having this issue. Anybody else tried newnat on a big-endian arch ? Yes, newnat is running on big-endian here - but without pptp :) Are you able to provide us with a patch fixing all respective places throughout the code? This would help a lot... If you don't have the time, please tell me an I'll see what I can do. Regards, Rob -- 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+(*)
Re: tproxy using conntrack/nat?
On Thu, May 23, 2002 at 12:56:58PM +0200, Balazs Scheidler wrote: I see two possibilities: * add a new argument to ip_nat_setup_info() to avoid helpers seems reasonable. it's only three arguments currently, having four wouldn't be a problem. add a 'int flags' argument and define a flag for 'BYPASS_HELPER'. ok, isn't this api change too intrusive to other netfilter parts? ip_nat_setup_info() is referenced 11 times on an unpatched 2.4.18. From my point of view, Linux kernel API's have always been changing. And a simple one-argument-change doesn't hurt anybody. The patch may contain a huge number of lines (since it's 11 function call changes) - but looking at it from an abstract point of view, there is nothing intrusive about it. A third solution would be to add new NFCT_ flag. Do you still prefer the flags argument? no, nfct again looks like a hack. This however wouldn't bypass the conntrack helper [which could already say INVALID because a packet doesn't match the layer5+ state of the connection, see for example the PPTP helper]. Don't forget that we have two conntrack entries if traffic is flown through a transparent proxy, and conntrack processing is done prior to NAT rewriting. Please tell me if I'm wrong, but CONNTRACK sees an unmodified PORT command assigned to a session with unmodified destination address. Oh, I didn't make myself clear. There are no bad interactions with NAT. But in case there really is an out-of-state packet, the conntrack helper would mark it INVALID - which might not be what you want in case of transparent proxying, where such state violation should be detected by the proxy itself. Bazsi -- 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+(*)
Re: another netfilter ICMP bug
On Thu, May 23, 2002 at 10:18:23AM +0200, Balazs Scheidler wrote: Hi, I've encountered another ICMP translation problem in netfilter. This time it occurs when a process initiates a connection and it is translated on the same host. are you sure this problem persists, even after applying the icmp nat fix? Bazsi -- 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+(*)
Re: another netfilter ICMP bug
On Thu, May 23, 2002 at 07:03:52PM +0200, Harald Welte wrote: On Thu, May 23, 2002 at 10:18:23AM +0200, Balazs Scheidler wrote: Hi, I've encountered another ICMP translation problem in netfilter. This time it occurs when a process initiates a connection and it is translated on the same host. are you sure this problem persists, even after applying the icmp nat fix? yes, I've forgotten to mention that I first applied the patch, and the problem persisted. (btw: a plain .diff file for the mentioned fix would make it much easier to apply the patch, I had to cut paste it from the .html) -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
