experchange > linux.networking

T (08-25-18, 12:39 AM)
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 (08-25-18, 01:11 AM)
On 08/24/2018 03:39 PM, T wrote:
[..]
> and rebooting does not help.
> Many thanks,
> -T


Figured it out.

Reference:


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

# systemctl restart iptables.

Problem solved

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

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA HHHHHHHHHHHHHHHHHHHHHHHHHHHH !!!!!!!!!

-T
Jorgen Grahn (08-25-18, 09:23 AM)
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
T (08-26-18, 08:13 AM)
On 08/25/2018 12:23 AM, Jorgen Grahn wrote:
> On Fri, 2018-08-24, T wrote:
> 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:

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
Pascal Hambourg (08-26-18, 11:35 AM)
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 (08-26-18, 11:05 PM)
On 08/26/2018 02:35 AM, Pascal Hambourg wrote:
> Le 26/08/2018 ŕ 08:13, T a écrit :
> And here are my comments.
> 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",



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".
> 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).

> 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.
> (...)
> Can you explain why do specify different dynamic port ranges $allports
> and $unassgn ?
> The rule accepting packets in the other direction is missing.


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

> 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.

> 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 (08-27-18, 02:02 AM)
On 2018-08-26, T <T> wrote:
[..]
> (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 (08-27-18, 02:11 AM)
On 08/26/2018 05:02 PM, William Unruh wrote:
> On 2018-08-26, T <T> wrote:
> 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.


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=25991DF
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 (08-27-18, 02:43 AM)
> 3) in /etc/modprobe.d/iptables.conf add
> nf_conntrack_ftp ports=21


options nf_conntrack_ftp ports=21
T (08-27-18, 02:44 AM)
On 08/26/2018 02:05 PM, T wrote:
> 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.
William Unruh (08-27-18, 04:00 AM)
On 2018-08-27, T <T> wrote:
> On 08/26/2018 05:02 PM, William Unruh wrote:
> 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.


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 (08-27-18, 04:37 AM)
On 08/26/2018 07:00 PM, William Unruh wrote:
> On 2018-08-27, T <T> 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.


Why have a firewall at all? The answer to that is the answer to
your question.
[..]
David W. Hodgins (08-27-18, 04:59 AM)
On Sun, 26 Aug 2018 22:00:39 -0400, William Unruh <unruh> 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
T (08-27-18, 05:42 AM)
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 (08-27-18, 06:29 AM)
On Sun, 26 Aug 2018 23:42:58 -0400, T <T> 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.

Regards, Dave Hodgins

Similar Threads