User: Password:
|
|
Subscribe / Log in / New account

FTP with Tcpcrypt vs. NAT

FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 15:50 UTC (Thu) by imitev (guest, #60045)
In reply to: FTP with Tcpcrypt vs. NAT by djao
Parent article: Transport-level encryption with Tcpcrypt

I guess what ilmari had in mind is that there are protocols which give indication of port numbers in the *payload*.
In the case of FTP passive, you usually connect to port 21 (control channel), and if you up/down something (or even ls ?) the server replies (in the payload) with "ok, connect to port 12345" ; port 12345 is random and is for the data channel.

Now in the case of NAT, if you want - say - to match RELATED packets with iptables, you need the ftp conntrack helper which will *read* the payload/data for ftp connections (control channel) so that what would be a NEW connection to the data channel on the random port supplied by the ftp server is actually matched by the connection tracking logic, and labelled as RELATED.
Having the headers clear text doesn't help here, you really need to be able to read what's in the payload.

I may be wrong though, it's been a long time I dealt with that stuff.


(Log in to post comments)

FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 16:02 UTC (Thu) by djao (guest, #4263) [Link]

Right, I didn't think about that. Thanks for the explanation.

FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 17:05 UTC (Thu) by imitev (guest, #60045) [Link]

replying to myself: I mentioned NAT but it has nothing to do with matching RELATED connections, I mixed the nat helper and the conntrack helper.
Anyway, in both case you still need to read what's in the payload.


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds