On 10/06/11 07:06, Nadeem Douba wrote:
The proxy completely controls what the client gets given. It is
breaking transparency by not reverse-mapping the response properly.
Mention it to the authors and get it fixed.
The authors (Websense) are of a different opinion of how this issue is
fixed. They recommended that we enable active FTP (significant
security risk).
Strange opinion. PORT needs the same types of handing in a relay/proxy
as PASV does. Only the control channel syntax is different.
Perhapse they meant websense accepts active FTP
(client-ACTIVE->proxy-PASV->server) or something like that.
As I see it they have two scenarios to pick from:
a) opening relay data connection themselves and setting that as the PASV
advertised port. Then "manually" as it were shuffling the bytes back and
forward there. Being websense and wanting to see inside the data this is
probably their best fix.
b) sending some port mapping details into netfilter indicating that
packets from server IP:port are going to be related to client IP:port.
A transparent proxy is equivalent to a NAT module in all respects.
Merely operates on the FTP layer in this case.
Switch "module" for "proxy" and you have a good plan for fixing the
bug.
Not really, even proxying these requests would result in the same
issue as the child proxy would relay the parent proxy's response.
huh? "even proxying these requests". The whole point of your original
post was that they *are* proxied, and the proxy is failing to NAPT the
control channel syntax on the reply.
A->B->C->D chaining of relays does not matter. Each relay hop can, and
must, do its own NAPT.
Just to clarify; what I read you asking about was this scenario:
When layer-7 software (proxy) does a NAPT mapping of text syntax
IP1:port1 -> IP2:port2 sent out on IP3:port3 (proxy->server control
control).
How to implement a layer-2 software (netfilter) to figure out this
mapping and to do the reverse IP2:port2 -> IP1:port1 mapping on the text
data inside the TCP packet body of packets returning on IP4:port4
(client->proxy control channel).
So the packet flow is:
control: client--nf_nat (DNAT/REDIRECT)-->proxy->server
data: client<--nf_nat (SNAT)----server
Keep in mind that websense proxy terminates a TCP connection and
generates a completely separate independent TCP connection from itself
to the source server. Whether that is FTP origin or other proxy.
So that the client->proxy information is in the INPUT tables. The
server->proxy response is in the OUTPUT tables. And NAT is done in a
third place the proxy normally does not have write access to.
So to me those factors all mean layer-2 where netfilter modules
operate is a very hard place to figure out what the correct mapping
should be.
(Jan, please correct me if you have some advanced magic voodoo that lets
INPUT and OUTPUT chain connections link as RELATED state)
Things get particularly nasty when, as you can see from that very first
comment I made above, the connections between proxy and server can
differ in their active/passive mode. Things like that happen at layer-7,
on some developers whim.
NOTE: If you do steps 5 and 6 in the IP layer you will be bypassing the
proxy data handling and void all your reasons for having it done by a
proxy in the first place. Instead of by the conntrack NAT module for FTP
for both outgoing and returning traffic.
The point is not to get rid of the proxy but to fix the issue that the
proxy is presenting to all FTP communications.
Which was the gist of my point.
AYJ
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
