Need help with iptables and ftp

[T]

Hi All,

Fedora 28

# uname -r
4.17.12-200.fc28.x86_64

Since switching from RHEL to Fedora 28, my iptables
no longer tracks the high ports used by ftp.

Aug 22 16:12:09 rn6 kernel: dsl-out Everything Else IN= OUT=eno2
SRC=192.168.xxx.yyy DST=208.106.xxx.yyy LEN=60 TOS=0x00 PREC=0x00 TTL=64
ID=25991 DF PROTO=TCP SPT=59698 DPT=21023 WINDOW=29200 RES=0x00 SYN URGP=0

I can't seem to load the need modules:


# ls /lib/modules/`uname -r`/kernel/net/netfilter | grep ftp
nf_conntrack_ftp.ko.xz
nf_conntrack_tftp.ko.xz
nf_nat_ftp.ko.xz
nf_nat_tftp.ko.xz



Inserting them into iptables-config
IPTABLES_MODULES=nf_conntrack_ftp nf_conntrack_tftp nf_nat_ftp nf_nat_tftp

and rebooting does not help.

Many thanks,
-T

[T]

Figured it out.

Reference:
https://serverfault.com/questions/887309/iptables-nf-conntrack-ftp-not-working

# vi /etc/modprobe.d/iptables.conf
options nf_conntrack_ftp ports=21

# systemctl restart iptables.

Problem solved

Talk about freaking obscure !!!!!!!!

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA HHHHHHHHHHHHHHHHHHHHHHHHHHHH !!!!!!!!!

-T

[T]

On 08/24/2018 03:43 PM, T wrote:
> Hi All,
>
> Fedora 28
>
> # uname -r
> 4.17.12-200.fc28.x86_64
>
> Since switching from RHEL to Fedora 28, my iptables
> no longer tracks the high ports used by ftp.
>
> Aug 22 16:12:09 rn6 kernel: dsl-out Everything Else IN= OUT=eno2
> SRC=192.168.xxx.yyy DST=208.106.xxx.yyy LEN=60 TOS=0x00 PREC=0x00 TTL=64
> ID=25991 DF PROTO=TCP SPT=59698 DPT=21023 WINDOW=29200 RES=0x00 SYN URGP=0
>
> I can't seem to load the need modules:
>
>
> # ls /lib/modules/`uname -r`/kernel/net/netfilter | grep ftp
> nf_conntrack_ftp.ko.xz
> nf_conntrack_tftp.ko.xz
> nf_nat_ftp.ko.xz
> nf_nat_tftp.ko.xz
>
>
>
> Inserting them into iptables-config
> IPTABLES_MODULES=nf_conntrack_ftp nf_conntrack_tftp nf_nat_ftp nf_nat_tftp
>
> and rebooting does not help.
>
> Many thanks,
> -T
>

My notes:

How to track ftp's high port with Fedora and iptables:

Problem: iptables will not automatically track ftp's high ports
(firewalld will).


Note: RHEL used
ip_conntrack_ftp, and
ip_nat_ftp

These have been superseded by
nf_conntrack_ftp
nf_conntrack_tftp
nf_nat_ftp
nf_nat_tftp


To set up ftp high port tracking.

1) in /etc/sysconfig/iptables-config add (under this first erase add)

IPTABLES_MODULES="nf_conntrack_ftp nf_conntrack_tftp nf_nat_ftp
nf_nat_tftp"


2) nf_conntrack_ftp is disabled by default. To enable it:
# echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper


3) in /etc/modprobe.d/iptables.conf add

nf_conntrack_ftp ports=21


4) restart iptables
# systemctl restart iptables

Note: you also have to reload your firewall rules after this too.


5) to check modules

# lsmod | grep ftp


Notes:
filters are part of the kernal and are located in
/lib/modules/`uname -r`/kernel/net/netfilter
to use them, remove the ".ko.xz"

manual filter adds (disappear after a reboot):
# modprobe nf_conntrack_ftp
# modprobe nf_conntrack_tftp
# modprobe nf_nat_ftp
# modprobe nf_nat_tftp


Sample passive and active ftp rules:


tbls=/sbin/iptables

if [ "$(cat /proc/sys/net/netfilter/nf_conntrack_helper)" == "0" ]; then
echo "echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper"
echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper
fi


Active:

$tbls -A dsl-out -o $eth1 -p tcp -s $eth1_addr --sport $allports
--dport ftp-data -m state --state ESTABLISHED -j ACCEPT
$tbls -A dsl-in -i $eth1 -p tcp --sport ftp-data -d $eth1_addr
--dport $unassgn -m state --state RELATED,ESTABLISHED -j ACCEPT
$tbls -A dsl-for -i $eth1 -p tcp --sport ftp-data -d
$internal_net --dport $unassgn -m state --state RELATED,ESTABLISHED -j
ACCEPT

Passive:

$tbls -A dsl-out -o $eth1 -p tcp -s $eth1_addr --sport $unassgn
--dport ftp -m conntrack --ctstate NEW,ESTABLISHED -j
ACCEPT
$tbls -A dsl-in -i $eth1 -p tcp ! --syn --sport ftp -d $eth1_addr
--dport $unassgn -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
$tbls -A dsl-for -i $eth1 -p tcp ! --syn --sport ftp -d $internal_net
--dport $unassgn -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
$tbls -A dsl-out -o $eth1 -p tcp -s $eth1_addr -d $ANY_IP
-m helper --helper ftp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
$tbls -A dsl-in -i $eth1 -p tcp ! --syn -s $ANY_IP -d $eth1_addr
-m helper --helper ftp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
$tbls -A dsl-for -i $eth1 -p tcp ! --syn -s $ANY_IP -d $internal_net
-m helper --helper ftp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

[Jorgen Grahn]

On Fri, 2018-08-24, T wrote:
> Hi All,
>
> Fedora 28
>
> # uname -r
> 4.17.12-200.fc28.x86_64
>
> Since switching from RHEL to Fedora 28, my iptables
> no longer tracks the high ports used by ftp.

This is active mode ftp, right? The one where the client says "please
contact me on port NNNNN and dump your data there"?

I'm surprised you have a need for it; it seems to me all clients have
defaulted to passive mode for at least a decade. At least, the
problem just disappeared for me some time around then, and it's not
due to configuration on my part.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[T]

On 08/25/2018 12:23 AM, Jorgen Grahn wrote:
> On Fri, 2018-08-24, T wrote:
>> Hi All,
>>
>> Fedora 28
>>
>> # uname -r
>> 4.17.12-200.fc28.x86_64
>>
>> Since switching from RHEL to Fedora 28, my iptables
>> no longer tracks the high ports used by ftp.
>
> This is active mode ftp, right? The one where the client says "please
> contact me on port NNNNN and dump your data there"?
>
> I'm surprised you have a need for it; it seems to me all clients have
> defaulted to passive mode for at least a decade. At least, the
> problem just disappeared for me some time around then, and it's not
> due to configuration on my part.
>
> /Jorgen
>

Hi Jorgen,

Both passive and active. I did figure it out.

Keep in mnd that iptables-config no longer loads
"IPTABLES_MODULES=". I will bugzilla it when their
web site comes back up.

-T


Here are my notes:

[Pascal Hambourg]

Le 26/08/2018 à 08:13, T a écrit :
>
> Here are my notes:

And here are my comments.

> How to track ftp's high port with Fedora and iptables:
>
> Problem: iptables will not automatically track ftp's high ports
> (firewalld will).

Iptables does not track anything by itself. Netfilter's connection
tracking aka "conntrack" does. Iptables just uses the resulting state.

There are no such "FTP high ports", but FTP active and passive data
connections. FTP active data connections use port 20 which is obviously
not "high".

> Note: RHEL used
>    ip_conntrack_ftp,  and
>    ip_nat_ftp
>
> These have been superseded by
>    nf_conntrack_ftp
>    nf_conntrack_tftp
>    nf_nat_ftp
>    nf_nat_tftp

nf_{conntrack|nat}_tftp modules are for the TFTP protocol, which is a
totally different protocol from FTP despite the close names. TFTP uses
UDP and a different control port.

ip_{conntrack|nat}_* are now aliases of nf_{conntrack|nat}_* modules, so
you can still use them if you want.

> 2) nf_conntrack_ftp is disabled by default.  To enable it:
>      # echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper

nf_conntrack_ftp is not disabled by default.
What has been disabled by default in recent kernels is the automatic
assignment of all conntrack helpers to connections.

Automatic assignment can also be enabled when the module is loaded with
the option nf_conntrack_helper=1.

But be aware that enabling automatic helper assignment is discouraged
(hence it was disabled by default). It is recommended to use explicit
assignment with the CT target instead.

On a client :
iptables -t raw -A OUTPUT -p tcp --dport 21 -j CT --helper ftp

On a server or router
iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp

> 3) in /etc/modprobe.d/iptables.conf add
>
>      nf_conntrack_ftp ports=21

Syntax error. You must prepend "options" to the line.

Port 21 is already the default, so you do not have to specify it.

> 4) restart iptables
>      # systemctl restart iptables
>
>    Note: you also have to reload your firewall rules after this too.

No you don't need to reload the ruleset, unless you changed it (e.g. you
added CT rules). Just loading helper modules and enabling automatic
helper assignment does not require to reload iptables rules.

> Sample passive and active ftp rules:

(...)

> Active:
>
>    $tbls -A dsl-out  -o $eth1  -p tcp  -s $eth1_addr --sport $allports
> --dport ftp-data -m state --state ESTABLISHED         -j ACCEPT
>    $tbls -A dsl-in   -i $eth1  -p tcp  --sport ftp-data -d $eth1_addr
> --dport $unassgn -m state --state RELATED,ESTABLISHED  -j ACCEPT

Can you explain why do specify different dynamic port ranges $allports
and $unassgn ?

>    $tbls -A dsl-for  -i $eth1  -p tcp  --sport ftp-data -d
> $internal_net --dport $unassgn -m state --state RELATED,ESTABLISHED  -j
> ACCEPT

The rule accepting packets in the other direction is missing.

> Passive:
>
> $tbls -A dsl-out  -o $eth1  -p tcp  -s $eth1_addr --sport $unassgn
> --dport ftp         -m conntrack --ctstate NEW,ESTABLISHED           -j
> ACCEPT
> $tbls -A dsl-in   -i $eth1  -p tcp  ! --syn --sport ftp -d $eth1_addr
> --dport $unassgn -m conntrack --ctstate RELATED,ESTABLISHED       -j ACCEPT
> $tbls -A dsl-for  -i $eth1  -p tcp  ! --syn --sport ftp -d $internal_net
>  --dport $unassgn  -m conntrack --ctstate RELATED,ESTABLISHED  -j ACCEPT

These rules allowing FTP control connections are not specific to passive
mode. They are also used in active mode.

The RELATED state should not be used in control connection rules. It
applies to data connections (replacing NEW), not control connections.

> $tbls -A dsl-out  -o $eth1  -p tcp  -s $eth1_addr       -d $ANY_IP -m
> helper --helper ftp -m conntrack --ctstate RELATED,ESTABLISHED  -j ACCEPT

> $tbls -A dsl-in   -i $eth1  -p tcp  ! --syn  -s $ANY_IP -d $eth1_addr -m
> helper --helper ftp -m conntrack --ctstate RELATED,ESTABLISHED  -j ACCEPT
> $tbls -A dsl-for  -i $eth1  -p tcp  ! --syn  -s $ANY_IP -d $internal_net
> -m helper --helper ftp -m conntrack --ctstate RELATED,ESTABLISHED  -j
> ACCEPT

On client side, the last two rules should not use the RELATED state (so
the helper match is useless).

[T]

On 08/26/2018 02:35 AM, Pascal Hambourg wrote:
> Le 26/08/2018 à 08:13, T a écrit :
>>
>> Here are my notes:
>
> And here are my comments.
>
>> How to track ftp's high port with Fedora and iptables:
>>
>> Problem: iptables will not automatically track ftp's high ports
>> (firewalld will).
>
> Iptables does not track anything by itself. Netfilter's connection
> tracking aka "conntrack" does. Iptables just uses the resulting state.
>
> There are no such "FTP high ports",

http://slacksite.com/other/ftp.html#passive
From the server-side firewall's standpoint, to support passive mode

FTP the following communication channels need to be opened:
FTP server's port 21 from anywhere (Client initiates connection)
FTP server's port 21 to ports > 1023 (Server responds to client's
control port)
FTP server's ports > 1023 from anywhere (Client initiates data
connection to random port specified by server)
FTP server's ports > 1023 to remote ports > 1023 (Server sends ACKs
(and data) to client's data port)

Basically, after the connection is established, communications in
passive mode switches to all high ports.

This is a pain in the ass to track, so nf_conntrack_ftp was
created

> but FTP active and passive data
> connections. FTP active data connections use port 20 which is obviously
> not "high".
>
>> Note: RHEL used
>>     ip_conntrack_ftp,  and
>>     ip_nat_ftp
>>
>> These have been superseded by
>>     nf_conntrack_ftp
>>     nf_conntrack_tftp
>>     nf_nat_ftp
>>     nf_nat_tftp
>
> nf_{conntrack|nat}_tftp modules are for the TFTP protocol, which is a
> totally different protocol from FTP despite the close names. TFTP uses
> UDP and a different control port.
>

You bet. I use tftp too

> ip_{conntrack|nat}_* are now aliases of nf_{conntrack|nat}_* modules, so
> you can still use them if you want.

I googled my ass off to figure that on out.

>
>> 2) nf_conntrack_ftp is disabled by default.  To enable it:
>>       # echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper
>
> nf_conntrack_ftp is not disabled by default.
> What has been disabled by default in recent kernels is the automatic
> assignment of all conntrack helpers to connections.

`lsmod | grep nf_conntrack_ftp` shows it not installed on my machine.
I am using Fedora 28. What are yo using?

>
> Automatic assignment can also be enabled when the module is loaded with
> the option nf_conntrack_helper=1.

Not on mine. I have to turn it on.

> But be aware that enabling automatic helper assignment is discouraged
> (hence it was disabled by default). It is recommended to use explicit
> assignment with the CT target instead.
>
> On a client :
> iptables -t raw -A OUTPUT -p tcp --dport 21 -j CT --helper ftp

Never got this to work.

> On a server or router
> iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp
>
>> 3) in /etc/modprobe.d/iptables.conf add
>>
>>       nf_conntrack_ftp ports=21
>
> Syntax error. You must prepend "options" to the line.
>
> Port 21 is already the default, so you do not have to specify it.

Googling it told me otherwise.

Got no error massages about the syntax.

What is the proper syntax (write it out).

>
>> 4) restart iptables
>>       # systemctl restart iptables
>>
>>     Note: you also have to reload your firewall rules after this too.
>
> No you don't need to reload the ruleset, unless you changed it (e.g. you
> added CT rules). Just loading helper modules and enabling automatic
> helper assignment does not require to reload iptables rules.
>
>> Sample passive and active ftp rules:
> (...)
>> Active:
>>
>>     $tbls -A dsl-out  -o $eth1  -p tcp  -s $eth1_addr --sport
>> $allports --dport ftp-data -m state --state ESTABLISHED         -j ACCEPT
>>     $tbls -A dsl-in   -i $eth1  -p tcp  --sport ftp-data -d $eth1_addr
>> --dport $unassgn -m state --state RELATED,ESTABLISHED  -j ACCEPT
>
> Can you explain why do specify different dynamic port ranges $allports
> and $unassgn ?
>
>>     $tbls -A dsl-for  -i $eth1  -p tcp  --sport ftp-data -d
>> $internal_net --dport $unassgn -m state --state RELATED,ESTABLISHED
>> -j ACCEPT
>
> The rule accepting packets in the other direction is missing.

It is covered in the passive rules and not duplicated om purpose.

>> Passive:
>>
>> $tbls -A dsl-out  -o $eth1  -p tcp  -s $eth1_addr --sport $unassgn
>> --dport ftp         -m conntrack --ctstate NEW,ESTABLISHED
>> -j ACCEPT
>> $tbls -A dsl-in   -i $eth1  -p tcp  ! --syn --sport ftp -d $eth1_addr
>> --dport $unassgn -m conntrack --ctstate RELATED,ESTABLISHED       -j
>> ACCEPT
>> $tbls -A dsl-for  -i $eth1  -p tcp  ! --syn --sport ftp -d
>> $internal_net   --dport $unassgn  -m conntrack --ctstate
>> RELATED,ESTABLISHED  -j ACCEPT
>
> These rules allowing FTP control connections are not specific to passive
> mode. They are also used in active mode.

On purpose, I have to support both

>
> The RELATED state should not be used in control connection rules. It
> applies to data connections (replacing NEW), not control connections.

Doesn't work without it.

>> $tbls -A dsl-out  -o $eth1  -p tcp  -s $eth1_addr       -d $ANY_IP -m
>> helper --helper ftp -m conntrack --ctstate RELATED,ESTABLISHED  -j ACCEPT
>
>> $tbls -A dsl-in   -i $eth1  -p tcp  ! --syn  -s $ANY_IP -d $eth1_addr
>> -m helper --helper ftp -m conntrack --ctstate RELATED,ESTABLISHED  -j
>> ACCEPT
>> $tbls -A dsl-for  -i $eth1  -p tcp  ! --syn  -s $ANY_IP -d
>> $internal_net -m helper --helper ftp -m conntrack --ctstate
>> RELATED,ESTABLISHED  -j ACCEPT
>
> On client side, the last two rules should not use the RELATED state (so
> the helper match is useless).

I don't get that last comment. It is the "--ctstate" where
these are called out, not the general "state".

Thank you for the help.

-T

[William Unruh]

On 2018-08-26, T <T...@invalid.invalid> wrote:
> On 08/26/2018 02:35 AM, Pascal Hambourg wrote:
>> Le 26/08/2018 à 08:13, T a écrit :
>>>
>>> Here are my notes:
>>
>> And here are my comments.
>>
>>> How to track ftp's high port with Fedora and iptables:
>>>
>>> Problem: iptables will not automatically track ftp's high ports
>>> (firewalld will).
>>
>> Iptables does not track anything by itself. Netfilter's connection
>> tracking aka "conntrack" does. Iptables just uses the resulting state.
>>
>> There are no such "FTP high ports",
>
> http://slacksite.com/other/ftp.html#passive
> From the server-side firewall's standpoint, to support passive mode
>
> FTP the following communication channels need to be opened:
> FTP server's port 21 from anywhere (Client initiates connection)
> FTP server's port 21 to ports > 1023 (Server responds to client's
> control port)
> FTP server's ports > 1023 from anywhere (Client initiates data
> connection to random port specified by server)
> FTP server's ports > 1023 to remote ports > 1023 (Server sends ACKs
> (and data) to client's data port)
>
> Basically, after the connection is established, communications in
> passive mode switches to all high ports.

Yes. So? The original connection is made on port 21.
I am not sure why you would want iptables to control those "high ports"?
If you disallow port 21, ftp cannot get started.
And there is abosolutely no way, unless it reads the inside of the
packets, and even there there is not much info, for iptables to know
this is ftp rather than something else.

>
> This is a pain in the ass to track, so nf_conntrack_ftp was
> created

What is it you want to track? And why?

[T]

21 is allowed.

I have to track these high ports as in passive mode
the server will send you a SYN on a high port and after
that you only communicate on high ports.

>
>>
>> This is a pain in the ass to track, so nf_conntrack_ftp was
>> created
>
> What is it you want to track? And why?

Take a look here. This is a passive mode ftp connection
that got bounced before I got my rules straight

kernel: dsl-out Everything Else IN= OUT=eno2 SRC=192.168.xxx.yyy
DST=208.106.xxx.yyy LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=25991 DF
PROTO=TCP SPT=59698 DPT=21023 WINDOW=29200 RES=0x00 SYN URGP=0

Source port SPT=59698
Destination port DPT=21023

All high ports. That is why you need nf_conntrack_ftp which
keeps track of them for you.

Note that it is a SYN packet

[T]

> 3) in /etc/modprobe.d/iptables.conf add
>
> nf_conntrack_ftp ports=21

options nf_conntrack_ftp ports=21

[T]

On 08/26/2018 02:05 PM, T wrote:
>
>> On a server or router
>> iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp
>>
>>> 3) in /etc/modprobe.d/iptables.conf add
>>>
>>>       nf_conntrack_ftp ports=21
>>
>> Syntax error. You must prepend "options" to the line.
>>
>> Port 21 is already the default, so you do not have to specify it.
>
> Googling it told me otherwise.
>
> Got no error massages about the syntax.
>
> What is the proper syntax (write it out).
>

My actual file had it in but my notes somehow dropped it.

> 3) in /etc/modprobe.d/iptables.conf add
>
> nf_conntrack_ftp ports=21

options nf_conntrack_ftp ports=21

[William Unruh]

Why? Why not just all them in? There is in general nothing listening on
those ports so nothing the outside world can do can get in via those
ports. So just leave you computer open on those ports.

[T]

Why have a firewall at all? The answer to that is the answer to
your question.

[David W. Hodgins]

On Sun, 26 Aug 2018 22:00:39 -0400, William Unruh <un...@invalid.ca> wrote:
> Why? Why not just all them in? There is in general nothing listening on
> those ports so nothing the outside world can do can get in via those
> ports. So just leave you computer open on those ports.

That is not a safe assumption. On my system, the following programs are
listening on high (over 1024) ports ...
synergys, ktorrent, boinc, upsd, master(postfix), and sshd.

The first three run under my user id, upsd as user ups, cups and sshd
run as root.

To see what's listening on your system, run (as root)
netstat -lnp|grep -e tcp -e udp -e Address

I've intentionally set sshd to run on a high number port to avoid having
script kiddies fill my logs with failed attempts (It's set to allow
login with a key only, not a password).

Regards, Dave Hodgins

--
Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

[T]

On 08/26/2018 07:59 PM, David W. Hodgins wrote:
> To see what's listening on your system, run (as root)
> netstat -lnp|grep -e tcp -e udp -e Address

I love it!

I have the following listening on my system:


dropbox
smbd
nmbd
named
cupsd
dnsmasq
dhclient
chronyd
avahi-daemon

What is an avahi-daemon daemon?

[David W. Hodgins]

On Sun, 26 Aug 2018 23:42:58 -0400, T <T...@invalid.invalid> wrote:

> What is an avahi-daemon daemon?

From "urpmq -i avahi" ...
Summary : Avahi service discovery (mDNS/DNS-SD) suite
Description :
Avahi is a system which facilitates service discovery on a local
network -- this means that you can plug your laptop or computer into a
network and instantly be able to view other people who you can chat
with, find printers to print to or find files being shared. This kind
of technology is already found in MacOS X (branded 'Rendezvous',
'Bonjour' and sometimes 'ZeroConf') and is very convenient.

I do not run it on my lan as all of my systems are linux, and I control
what's available between the systems with other means.

[T]

Thank you!

I bet it is a Samba thing for my Windows virtual machines

[William Unruh]

If you have purposely set up your system to listen to some high port,
then go ahead and firewall them of course. It is the blanket firewalling
of all high ports that I am confused about. That would as I have said,
make the system lexx, not more secure. Now the firewall is actively
listening to those ports and weaknesses in the firewall program become
attackable.
>

[William Unruh]

On 2018-08-27, T <T...@invalid.invalid> wrote:

No. It is a Linux thing.

[David W. Hodgins]

On Mon, 27 Aug 2018 05:44:25 -0400, William Unruh <un...@invalid.ca> wrote:

> If you have purposely set up your system to listen to some high port,
> then go ahead and firewall them of course. It is the blanket firewalling
> of all high ports that I am confused about. That would as I have said,
> make the system lexx, not more secure. Now the firewall is actively
> listening to those ports and weaknesses in the firewall program become
> attackable.

The confusion is clear, and I suspect due to a windows background where
a firewall is added to try an make things more secure after networking
is working.

In linux, iptables is the firewall. It's one of the core kernel components.
No matter where a packet comes from, a network interface, or from a program
running under that linux system, that packet is processed by iptables to
decide what to do with it.

All programs like shorewall do is try to make it easier to add rules for
iptables to follow, in an way that's easier to read than would be needed
with just loading iptables rules in the format it uses. While the config
files for shorewall may be difficult to read, try comparing them to the
output of "iptables -L" (run as root), which shows the iptables rules that
shorewall created. When the log shows a message saying shorewall dropped
a packet, the packet wasn't dropped by shorewall. It was dropped by iptables
based on a rule that was added by shorewall.

On my system, # iptables -L|grep Shorewall
LOG all -- anywhere anywhere LOG level info prefix "Shorewall:INPUT:REJECT:"
LOG all -- anywhere anywhere LOG level info prefix "Shorewall:FORWARD:REJECT:"
LOG all -- anywhere anywhere LOG level info prefix "Shorewall:OUTPUT:REJECT:"
LOG all -- anywhere anywhere LOG level info ip-options prefix "Shorewall:logflags:DROP:"

It's the above iptables rules that cause syslog messages with Shorewall
in the comments.

Even if you don't have a program like shorewall installed, iptables still
decides what to do with the packet. Shorewall does not process packets.
It just adds rules for iptables to follow. Not having a rule for a given
port just means that iptables will use whatever has been specified as
the default, not that iptables doesn't process it.

[Scott Hemphill]

"David W. Hodgins" <dwho...@nomail.afraid.org> writes:

[snip]

> I've intentionally set sshd to run on a high number port to avoid having
> script kiddies fill my logs with failed attempts (It's set to allow
> login with a key only, not a password).

Alternatively, or in addition to this, you might want to run knockd.
You can keep all ports closed, but when a particular sequence of ports
is accessed, you can dynamically open a particular port for your ssh
connection.

The default configuration file looks like:

------------------------------------------------------------------------
[OPTIONS]
UseSyslog

[opencloseSSH]
sequence = 2222:udp,3333:tcp,4444:udp
seq_timeout = 15
tcpflags = syn,ack
start_command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport ssh -j ACCEPT
cmd_timeout = 10
stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport ssh -j ACCEPT

------------------------------------------------------------------------

In my case, I have separate open and close sequences, with knockd
calling a script to run iptables with commands for port forwarding. I
then use the PortKnock app on my iPhone when I want to ssh in.

Scott
--
Scott Hemphill hemp...@alumni.caltech.edu
"This isn't flying. This is falling, with style." -- Buzz Lightyear

[T]

On 08/26/2018 07:59 PM, David W. Hodgins wrote:
> I've intentionally set sshd to run on a high number port to avoid having
> script kiddies fill my logs with failed attempts (It's set to allow
> login with a key only, not a password).

I do the same thing. When I am running an Internet facing
service, I change the port number to cause confusion for the
script kiddies.

:-)

[T]

On 08/27/2018 02:44 AM, William Unruh wrote:
> If you have purposely set up your system to listen to some high port,
> then go ahead and firewall them of course.

I do not accept SYN packets from anyone, unless that service is
deliberately opened up.

Passive mode ftp uses high ports for SYN packets. nf_conntrack_ftp
keeps track on which high port SYN packet was caused by a previous
established ftp connection and lets them through if from the right
folks.

[Dan Purgert]

T wrote:
> Hi All,
>
> Fedora 28
>
> # uname -r
> 4.17.12-200.fc28.x86_64
>
> Since switching from RHEL to Fedora 28, my iptables
> no longer tracks the high ports used by ftp.

I hope I didn't simply miss the discussion on it ... but why FTP in the
first place?

It's not like anything's encrypted (unless you're using FTP/SSL?), so
even if you're moving ports around and whatnot, it's not like someone
can't simply be watching everything that gets transferred anyway --
inclusive of username/password.


--
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281

[Jorgen Grahn]

On Tue, 2018-08-28, Dan Purgert wrote:
> T wrote:
>> Hi All,
>>
>> Fedora 28
>>
>> # uname -r
>> 4.17.12-200.fc28.x86_64
>>
>> Since switching from RHEL to Fedora 28, my iptables
>> no longer tracks the high ports used by ftp.
>
> I hope I didn't simply miss the discussion on it ... but why FTP in the
> first place?

I asked basically "why is something still using active FTP on your
systems, when mine haven't for a decade or so?" and I still wonder
about that.

> It's not like anything's encrypted (unless you're using FTP/SSL?), so
> even if you're moving ports around and whatnot, it's not like someone
> can't simply be watching everything that gets transferred anyway --
> inclusive of username/password.

There's anonymous FTP. Hard to tell if some software on some system
of yours will want to use it.

[Tauno Voipio]

For secure transfers, there is scp in the SSH suite. Plain old
FTP is pretty obsolete.

--

-TV

[Dan Purgert]

Sure, but until we get the answer of "why FTP", we're just making
assumptions, and (at least in my case) hoping we're making the wrong
ones.

[William Unruh]

On 2018-08-29, Dan Purgert <d...@djph.net> wrote:
> Jorgen Grahn wrote:
>> On Tue, 2018-08-28, Dan Purgert wrote:
>>> T wrote:
>>>> Hi All,
>>>>
>>>> Fedora 28
>>>>
>>>> # uname -r
>>>> 4.17.12-200.fc28.x86_64
>>>>
>>>> Since switching from RHEL to Fedora 28, my iptables
>>>> no longer tracks the high ports used by ftp.
>>>
>>> I hope I didn't simply miss the discussion on it ... but why FTP in the
>>> first place?
>>
>> I asked basically "why is something still using active FTP on your
>> systems, when mine haven't for a decade or so?" and I still wonder
>> about that.
>>
>>> It's not like anything's encrypted (unless you're using FTP/SSL?), so
>>> even if you're moving ports around and whatnot, it's not like someone
>>> can't simply be watching everything that gets transferred anyway --
>>> inclusive of username/password.
>>
>> There's anonymous FTP. Hard to tell if some software on some system
>> of yours will want to use it.
>
> Sure, but until we get the answer of "why FTP", we're just making
> assumptions, and (at least in my case) hoping we're making the wrong
> ones.

It sounds to me like he has put a firewall ban on all higher ports. But
that also bans all passive ftp connections. So he wants to track his
machine's ftp responses on higher ports, so as not to ban all ftp (eg he
may be allowing annonymous ftp)


>
>

[Dan Purgert]

And that's what the enquiries were about -- "what's the usecase for this
FTP server in the first place?"

[David W. Hodgins]

On Wed, 29 Aug 2018 08:27:19 -0400, Dan Purgert <d...@djph.net> wrote:

> William Unruh wrote:
>> It sounds to me like he has put a firewall ban on all higher ports. But
>> that also bans all passive ftp connections. So he wants to track his
>> machine's ftp responses on higher ports, so as not to ban all ftp (eg he
>> may be allowing annonymous ftp)

> And that's what the enquiries were about -- "what's the usecase for this
> FTP server in the first place?"

I agree that is the question. As to the questions of why use ftp instead
of something secure, there are many times where publicly shared files
have no need for security, so ftp is the lowest overhead option for
those transfers. For example, ftp://mirror.cedia.org.ec/

[Aragorn]

On Wednesday 29 August 2018 17:14, David W. Hodgins conveyed the
following to comp.os.linux.networking...

> On Wed, 29 Aug 2018 08:27:19 -0400, Dan Purgert <d...@djph.net> wrote:
>
>> William Unruh wrote:
>>
>>> It sounds to me like he has put a firewall ban on all higher ports.
>>> But that also bans all passive ftp connections. So he wants to track
>>> his machine's ftp responses on higher ports, so as not to ban all
>>> ftp (eg he may be allowing annonymous ftp)
>
>> And that's what the enquiries were about -- "what's the usecase for
>> this FTP server in the first place?"
>
> I agree that is the question.

No, no, no, to be or not to be, THAT is the question. Sir Francis
Bacon, um, I mean, William Shakespeare said so! :p

--
With respect,
= Aragorn =

[Wouter Verhelst]

On 8/29/18 5:14 PM, David W. Hodgins wrote:
> As to the questions of why use ftp instead
> of something secure, there are many times where publicly shared files
> have no need for security, so ftp is the lowest overhead option for
> those transfers.

No, HTTP is. FTP, with is two ports, incurs a high amount of overhead on
all middle boxes for no particularly good reason.

FTP must die.

[Jorgen Grahn]

Other possible points of view:
- Middle boxes must die.
- IPv4 must die.

(Not that I'm a big fan of FTP, especially not the "please dump your
data on <addr:port>" part, or the cleartext auth part.)

[Richard Kettlewell]

Jorgen Grahn <grahn...@snipabacken.se> writes:
> On Thu, 2018-08-30, Wouter Verhelst wrote:
>> On 8/29/18 5:14 PM, David W. Hodgins wrote:
>>> As to the questions of why use ftp instead of something secure,
>>> there are many times where publicly shared files have no need for
>>> security, so ftp is the lowest overhead option for those transfers.
>>
>> No, HTTP is. FTP, with is two ports, incurs a high amount of overhead on
>> all middle boxes for no particularly good reason.
>>
>> FTP must die.
>
> Other possible points of view:
> - Middle boxes must die.
> - IPv4 must die.

All three. l-)

> (Not that I'm a big fan of FTP, especially not the "please dump your
> data on <addr:port>" part, or the cleartext auth part.)

It should have been killed off some time in the 1990s. Ridiculous
protocol.

--
https://www.greenend.org.uk/rjk/

[Wouter Verhelst]

On 8/30/18 3:16 PM, Jorgen Grahn wrote:
> On Thu, 2018-08-30, Wouter Verhelst wrote:
>> On 8/29/18 5:14 PM, David W. Hodgins wrote:
>>> As to the questions of why use ftp instead
>>> of something secure, there are many times where publicly shared files
>>> have no need for security, so ftp is the lowest overhead option for
>>> those transfers.
>>
>> No, HTTP is. FTP, with is two ports, incurs a high amount of overhead on
>> all middle boxes for no particularly good reason.
>>
>> FTP must die.
>
> Other possible points of view:
> - Middle boxes must die.

Middle boxes are not just NAT machines, they're also things like routers
and firewalls. You do want the former, otherwise you just have a bunch
of LANs and no Internet. You do want the latter, because... well, reasons.

Everything which needs to inspect traffic (which definitely includes
firewalls, and sometimes also includes routers, not just for NAT) hates FTP.

Also, because of the required deep inspection, two of the three forms of
encrypted FTP are doomed (sftp isn't, because that uses SSH and thus a
single TCP connection -- but then sftp also isn't really FTP).

> - IPv4 must die.

Well, yes. But FTP "works" over IPv6 too, with similar problems.

> (Not that I'm a big fan of FTP, especially not the "please dump your
> data on <addr:port>" part, or the cleartext auth part.)

Exactly, that's my point.

[William Unruh]

Not before something equivalent replaces it. From when I have used http,
I have not beeen impressed.

But it is not clear to me what this "high overhead" is. Why is it any
higher than one port? The packets have to be routed in any case, and
only the two end machines have to keep track of how the traffic on the
two routes relates to each other.

[William Unruh]

On 2018-08-30, Wouter Verhelst <w...@uter.be> wrote:

> On 8/30/18 3:16 PM, Jorgen Grahn wrote:
>> On Thu, 2018-08-30, Wouter Verhelst wrote:
>>> On 8/29/18 5:14 PM, David W. Hodgins wrote:
>>>> As to the questions of why use ftp instead
>>>> of something secure, there are many times where publicly shared files
>>>> have no need for security, so ftp is the lowest overhead option for
>>>> those transfers.
>>>
>>> No, HTTP is. FTP, with is two ports, incurs a high amount of overhead on
>>> all middle boxes for no particularly good reason.
>>>
>>> FTP must die.
>>
>> Other possible points of view:
>> - Middle boxes must die.
>
> Middle boxes are not just NAT machines, they're also things like routers
> and firewalls. You do want the former, otherwise you just have a bunch
> of LANs and no Internet. You do want the latter, because... well, reasons.
>
> Everything which needs to inspect traffic (which definitely includes
> firewalls, and sometimes also includes routers, not just for NAT) hates FTP.

?? I would think that making it has hard as possible to inspect trafffic
After alll that is the whole point of encryption to make that impossible

>
> Also, because of the required deep inspection, two of the three forms of
> encrypted FTP are doomed (sftp isn't, because that uses SSH and thus a
> single TCP connection -- but then sftp also isn't really FTP).

>O
This soulds like speccial pleading-- " If I like it, it really isn't
that which I hate".

>> - IPv4 must die.
>
> Well, yes. But FTP "works" over IPv6 too, with similar problems.
>
>> (Not that I'm a big fan of FTP, especially not the "please dump your
>> data on <addr:port>" part, or the cleartext auth part.)
>
> Exactly, that's my point.

All protoccols say "pleaase dump your data on <addr:port>" What
difference does it make if it is the same addr:port as the request came
from or not?

Clear text auth is clearly a problem, but irrelevant to annonymous ftp.

[David W. Hodgins]

On Thu, 30 Aug 2018 20:25:11 -0400, William Unruh <un...@invalid.ca> wrote:

> But it is not clear to me what this "high overhead" is. Why is it any
> higher than one port? The packets have to be routed in any case, and
> only the two end machines have to keep track of how the traffic on the
> two routes relates to each other.

I find stream mode ftp transfers go much faster than http transfers.
https://en.wikipedia.org/wiki/File_Transfer_Protocol#Communication_and_data_transfer

[Jorgen Grahn]

On Fri, 2018-08-31, William Unruh wrote:
> On 2018-08-30, Wouter Verhelst <w...@uter.be> wrote:
>> On 8/30/18 3:16 PM, Jorgen Grahn wrote:

...

>>> (Not that I'm a big fan of FTP, especially not the "please dump your
>>> data on <addr:port>" part, or the cleartext auth part.)
>>
>> Exactly, that's my point.
>
> All protoccols say "pleaase dump your data on <addr:port>" What
> difference does it make if it is the same addr:port as the request came
> from or not?

I wrote that, but now I'm not sure why. As far as I can tell it's a
problem only if the server and client aren't "equal internet
citizens", and I was (kind of) arguing against such a setup.

I suppose it made sense for the protocol to separate the slow command
stream and the data stream.

[Dan Purgert]

William Unruh wrote:
> On 2018-08-30, Wouter Verhelst <w...@uter.be> wrote:
>> On 8/29/18 5:14 PM, David W. Hodgins wrote:
>>> As to the questions of why use ftp instead
>>> of something secure, there are many times where publicly shared files
>>> have no need for security, so ftp is the lowest overhead option for
>>> those transfers.
>>
>> No, HTTP is. FTP, with is two ports, incurs a high amount of overhead on
>> all middle boxes for no particularly good reason.
>>
>> FTP must die.
>
> Not before something equivalent replaces it. From when I have used http,
> I have not beeen impressed.

Well, there is SFTP. Other than using ssh transport, and "exit" rather
than "bye", it's pretty much identical. Need to use an sftp-capable
client though (not 100% sure if web-browsers will play well with it,
though I've never tried).

>
> But it is not clear to me what this "high overhead" is. Why is it any
> higher than one port? The packets have to be routed in any case, and
> only the two end machines have to keep track of how the traffic on the
> two routes relates to each other.

Spartknotes / pre-coffee version of the story is that you have two
sessions in conntrack (port 21 for the control session, and related-port
"whatever" for the data session). It's mainly the two endpoints
(assuming the FTP server is behind NAT) that're getting this overhead
more than "everything" in the middle though.

[Wouter Verhelst]

On 8/31/18 11:25 AM, Dan Purgert wrote:
> William Unruh wrote:
>> On 2018-08-30, Wouter Verhelst <w...@uter.be> wrote:
>>> On 8/29/18 5:14 PM, David W. Hodgins wrote:
>>>> As to the questions of why use ftp instead
>>>> of something secure, there are many times where publicly shared files
>>>> have no need for security, so ftp is the lowest overhead option for
>>>> those transfers.
>>>
>>> No, HTTP is. FTP, with is two ports, incurs a high amount of overhead on
>>> all middle boxes for no particularly good reason.
>>>
>>> FTP must die.
>>
>> Not before something equivalent replaces it. From when I have used http,
>> I have not beeen impressed.
>
> Well, there is SFTP. Other than using ssh transport, and "exit" rather
> than "bye", it's pretty much identical.

Well, yes, the command line is. The on-the-wire protocol isn't, not even
remotely.

> Need to use an sftp-capable
> client though (not 100% sure if web-browsers will play well with it,
> though I've never tried).
>
>>
>> But it is not clear to me what this "high overhead" is. Why is it any
>> higher than one port? The packets have to be routed in any case, and
>> only the two end machines have to keep track of how the traffic on the
>> two routes relates to each other.
>
> Spartknotes / pre-coffee version of the story is that you have two
> sessions in conntrack (port 21 for the control session, and related-port
> "whatever" for the data session). It's mainly the two endpoints
> (assuming the FTP server is behind NAT) that're getting this overhead
> more than "everything" in the middle though.

Everything in the middle which needs to keep state needs to have the
overhead. It's useless and painful.

[Wouter Verhelst]

On 8/31/18 2:31 AM, William Unruh wrote:
> On 2018-08-30, Wouter Verhelst <w...@uter.be> wrote:
>> On 8/30/18 3:16 PM, Jorgen Grahn wrote:
>>> On Thu, 2018-08-30, Wouter Verhelst wrote:
>>>> On 8/29/18 5:14 PM, David W. Hodgins wrote:
>>>>> As to the questions of why use ftp instead
>>>>> of something secure, there are many times where publicly shared files
>>>>> have no need for security, so ftp is the lowest overhead option for
>>>>> those transfers.
>>>>
>>>> No, HTTP is. FTP, with is two ports, incurs a high amount of overhead on
>>>> all middle boxes for no particularly good reason.
>>>>
>>>> FTP must die.
>>>
>>> Other possible points of view:
>>> - Middle boxes must die.
>>
>> Middle boxes are not just NAT machines, they're also things like routers
>> and firewalls. You do want the former, otherwise you just have a bunch
>> of LANs and no Internet. You do want the latter, because... well, reasons.
>>
>> Everything which needs to inspect traffic (which definitely includes
>> firewalls, and sometimes also includes routers, not just for NAT) hates FTP.
>
> ?? I would think that making it has hard as possible to inspect trafffic
> After alll that is the whole point of encryption to make that impossible

I should clarify.

There is inspection, and there is deep inspection.

With "inspection", I mean that a middle box looks at (and possibly
changes) the (unencrypted) IP headers: source/destination address,
source/destination port, TCP flags etc, but nothing else. With those
things, it can reliably follow the state of the connection. Machine
which do NAT, firewalls, and sometimes also routers, need to do that in
order to do their job. There is also nothing wrong with this; in fact,
if we were to encrypt the IP and TCP headers, nothing would work anymore
and things would go very very wrong.

With "deep inspection", I mean to say that you do more than just look at
those fields; you also look at the application layer data that flows
through the network in order to be able to figure out which connections
are expected. In order to be able to properly NAT an FTP connection, you
absolutely need to do deep inspection.

I agree with you that that is undesirable. I agree with you that
encryption is a good thing, and that we should encrypt as much as possible.

However, if you want encryption to not fuck up your connection, then you
cannot use FTP, because in order for it to work properly in the face of
middle boxes, you cannot combine FTP and encryption.

This is why I said that FTP should die ;-)

>> Also, because of the required deep inspection, two of the three forms of
>> encrypted FTP are doomed (sftp isn't, because that uses SSH and thus a
>> single TCP connection -- but then sftp also isn't really FTP).
>>

> This soulds like speccial pleading-- " If I like it, it really isn't
> that which I hate".

I'm not sure what you mean by that, but I suspect you misunderstood what
I meant in the first place ;-)

>>> - IPv4 must die.
>>
>> Well, yes. But FTP "works" over IPv6 too, with similar problems.
>>
>>> (Not that I'm a big fan of FTP, especially not the "please dump your
>>> data on <addr:port>" part, or the cleartext auth part.)
>>
>> Exactly, that's my point.
>
> All protoccols say "pleaase dump your data on <addr:port>" What
> difference does it make if it is the same addr:port as the request came
> from or not?

FTP says "please open a new TCP connection on <addr:port> and dump your
data there". This is awful.

> Clear text auth is clearly a problem, but irrelevant to annonymous ftp.

Sure.

[Dan Purgert]

Wouter Verhelst wrote:
> On 8/31/18 11:25 AM, Dan Purgert wrote:
>> William Unruh wrote:
>>> On 2018-08-30, Wouter Verhelst <w...@uter.be> wrote:
>>>> No, HTTP is. FTP, with is two ports, incurs a high amount of
>>>> overhead on all middle boxes for no particularly good reason.
>>>>
>>>> FTP must die.
>>>
>>> Not before something equivalent replaces it. From when I have used http,
>>> I have not beeen impressed.
>>
>> Well, there is SFTP. Other than using ssh transport, and "exit" rather
>> than "bye", it's pretty much identical.
>
> Well, yes, the command line is. The on-the-wire protocol isn't, not even
> remotely.

Of course, but then I took William's "equivalency" need in terms of
usability / features rather than on-the-wire implementation :)

[Allodoxaphobia]

On Fri, 31 Aug 2018 09:25:26 -0000 (UTC), Dan Purgert wrote:
>
> Well, there is SFTP. Other than using ssh transport, and "exit" rather
> than "bye", it's pretty much identical. Need to use an sftp-capable
> client though (not 100% sure if web-browsers will play well with it,
> though I've never tried).

konqueror : sftp://username:pas...@example.com/home/username

(The password is removed in the location bar after connect.)

Makes a GREAT inter-host file manager.

Jonesy -- Ubuntu + Trinity
--
Marvin L Jones | Marvin | W3DHJ.net | linux
38.238N 104.547W | @ jonz.net | Jonesy | FreeBSD
* Killfiling google & XXXXbanter.com: jonz.net/ng.htm

[William Unruh]

On 2018-08-31, Wouter Verhelst <w...@uter.be> wrote:
:

> FTP says "please open a new TCP connection on <addr:port> and dump your
> data there". This is awful.

Why is this awful?

[Tauno Voipio]

The address and port are inside the TCP message,
not only in the IP header. This makes it awful
to firewall and/or NAT.

--

-TV

[Pascal Hambourg]

Le 30/08/2018 à 18:42, Wouter Verhelst a écrit :
>
> but then sftp also isn't really FTP

SFTP is not FTP at all.
TFTP is not FTP either.
Any file transfer protocol is not FTP.

[Pascal Hambourg]

Indeed. It is a violation of the network layers separation.
Other protocols such as SIP (VoIP) do the same. Should it die too ?

Note that setting up separate control and data connections has
advantages. It allows to do direct transfers between two FTP servers
(FXP) controlled by a client. It allows SIP to set up direct media
streams between the two peers.

[William Unruh]

Its name begs to differ.

[Pascal Hambourg]

Le 27/08/2018 à 11:47, William Unruh a écrit :
> On 2018-08-27, T <T...@invalid.invalid> wrote:
>>>
>>>> What is an avahi-daemon daemon?
>>
>> I bet it is a Samba thing for my Windows virtual machines
>
> No. It is a Linux thing.

No. Avahi is a cross-platform software implementing Zeroconf, an IETF
standard.

[Pascal Hambourg]

Le 27/08/2018 à 21:21, T a écrit :
>
> I do not accept SYN packets from anyone, unless that service is
> deliberately opened up.
>
> Passive mode ftp uses high ports for SYN packets.

No SYN packet is sent to your client host in passive mode. All (control
and data) are sent to the server.

[Wouter Verhelst]

Yes, but its implementation doesn't. The FTP over-the-wire protocol is
not even remotely similar to the one of SFTP or TFTP.

[Wouter Verhelst]

On 9/1/18 4:14 PM, Pascal Hambourg wrote:
> Le 01/09/2018 à 08:56, Tauno Voipio a écrit :
>> On 1.9.18 01:11, William Unruh wrote:
>>> On 2018-08-31, Wouter Verhelst <w...@uter.be> wrote:
>>> :
>>>> FTP says "please open a new TCP connection on <addr:port> and dump your
>>>> data there". This is awful.
>>>
>>> Why is this awful?
>>
>> The address and port are inside the TCP message,
>> not only in the IP header. This makes it awful
>> to firewall and/or NAT.
>
> Indeed. It is a violation of the network layers separation.
> Other protocols such as SIP (VoIP) do the same. Should it die too ?

I'm well aware that SIP does that too. It has an excuse, in that for SIP
latency is everything, so I'm willing to cut it some slack there; but
for FTP, who gives a **** about latency?

> Note that setting up separate control and data connections has
> advantages. It allows to do direct transfers between two FTP servers
> (FXP) controlled by a client.

How many clients support that reliably?
How many FTP server configurations won't go coocoo when you try?
How often have you done this?

> It allows SIP to set up direct media
> streams between the two peers.

Yes, and there, because it reduces latency, it's a good idea. It causes
headache and annoyances, but the alternative is worse, so I'm willing to
ignore the annoyances.

Not so for FTP, though.

[Pascal Hambourg]

Le 04/09/2018 à 18:00, Wouter Verhelst a écrit :
> On 9/1/18 4:14 PM, Pascal Hambourg wrote:
>> Le 01/09/2018 à 08:56, Tauno Voipio a écrit :
>>>
>>> The address and port are inside the TCP message,
>>> not only in the IP header. This makes it awful
>>> to firewall and/or NAT.
>>
>> Indeed. It is a violation of the network layers separation.
>> Other protocols such as SIP (VoIP) do the same. Should it die too ?
>
> I'm well aware that SIP does that too. It has an excuse, in that for SIP
> latency is everything, so I'm willing to cut it some slack there; but
> for FTP, who gives a **** about latency?

What does latency have to do here ?

>> Note that setting up separate control and data connections has
>> advantages. It allows to do direct transfers between two FTP servers
>> (FXP) controlled by a client.
>
> How many clients support that reliably?
> How many FTP server configurations won't go coocoo when you try?
> How often have you done this?

I do not remember ever trying it. This is probably not possible any more
in the current state of the internet full of NATs and firewalls. I admit
FXP is not a essential feature of FTP, merely a side effect. If you want
to transfer files directly between two servers, just ssh into one and
start the transfer from there.

[Wouter Verhelst]

On 9/4/18 8:36 PM, Pascal Hambourg wrote:
> Le 04/09/2018 à 18:00, Wouter Verhelst a écrit :
>> On 9/1/18 4:14 PM, Pascal Hambourg wrote:
>>> Le 01/09/2018 à 08:56, Tauno Voipio a écrit :
>>>>
>>>> The address and port are inside the TCP message,
>>>> not only in the IP header. This makes it awful
>>>> to firewall and/or NAT.
>>>
>>> Indeed. It is a violation of the network layers separation.
>>> Other protocols such as SIP (VoIP) do the same. Should it die too ?
>>
>> I'm well aware that SIP does that too. It has an excuse, in that for SIP
>> latency is everything, so I'm willing to cut it some slack there; but
>> for FTP, who gives a **** about latency?
>
> What does latency have to do here ?

For FTP? Nothing. I'm willing to cut *SIP* some slack because it needs
to do those things for latency reasons, but that doesn't apply to FTP
(hence my "who cares" statement).

>>> Note that setting up separate control and data connections has
>>> advantages. It allows to do direct transfers between two FTP servers
>>> (FXP) controlled by a client.
>>
>> How many clients support that reliably?
>> How many FTP server configurations won't go coocoo when you try?
>> How often have you done this?
>
> I do not remember ever trying it. This is probably not possible any more
> in the current state of the internet full of NATs and firewalls. I admit
> FXP is not a essential feature of FTP, merely a side effect. If you want
> to transfer files directly between two servers, just ssh into one and
> start the transfer from there.

[Pascal Hambourg]

Le 05/09/2018 à 10:25, Wouter Verhelst a écrit :
> On 9/4/18 8:36 PM, Pascal Hambourg wrote:
>> Le 04/09/2018 à 18:00, Wouter Verhelst a écrit :
>>> On 9/1/18 4:14 PM, Pascal Hambourg wrote:
>>>> Le 01/09/2018 à 08:56, Tauno Voipio a écrit :
>>>>>
>>>>> The address and port are inside the TCP message,
>>>>> not only in the IP header. This makes it awful
>>>>> to firewall and/or NAT.
>>>>
>>>> Indeed. It is a violation of the network layers separation.
>>>> Other protocols such as SIP (VoIP) do the same. Should it die too ?
>>>
>>> I'm well aware that SIP does that too. It has an excuse, in that for SIP
>>> latency is everything, so I'm willing to cut it some slack there; but
>>> for FTP, who gives a **** about latency?
>>
>> What does latency have to do here ?
>
> For FTP? Nothing. I'm willing to cut *SIP* some slack because it needs
> to do those things for latency reasons, but that doesn't apply to FTP
> (hence my "who cares" statement).

Sorry for not being clear enough. I was wondering what passing address
and port information over the control channel had to do with latency ?

[Wouter Verhelst]

Ah, yes. Sorry; I wasn't clear enough in explaining that, either :-)

That in and of itself doesn't. But the ability to make the media streams
go peer-to-peer, rather than have them be routed through whatever SIP
registry you're using, does; it means you don't need a round-trip to the
registry server and then another round-trip to the party you're having a
SIP communication with, but can instead have things go directly to the
other end of the communication; and that does cut latency.