Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #4186 > unrolled thread

Need help with iptables and ftp

Back to article view | Back to comp.os.linux.networking

Contents

  Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-24 15:39 -0700
    Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-24 16:11 -0700
    Re: Need help with iptables and ftp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-08-25 07:23 +0000
      Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-25 23:13 -0700
        Re: Need help with iptables and ftp Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-08-26 11:35 +0200
          Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-26 14:05 -0700
            Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-27 00:02 +0000
              Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-26 17:11 -0700
                Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-27 02:00 +0000
                  Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-26 19:37 -0700
                  Re: Need help with iptables and ftp "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2018-08-26 22:59 -0400
                    Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-26 20:42 -0700
                      Re: Need help with iptables and ftp "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2018-08-27 00:29 -0400
                        Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-26 22:06 -0700
                          Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-27 09:47 +0000
                            Re: Need help with iptables and ftp Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-03 20:47 +0200
                    Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-27 09:44 +0000
                      Re: Need help with iptables and ftp "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2018-08-27 06:17 -0400
                      Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-27 12:21 -0700
                        Re: Need help with iptables and ftp Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-03 20:55 +0200
                    Re: Need help with iptables and ftp Scott Hemphill <hemphill@hemphills.net> - 2018-08-27 11:22 -0400
                    Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-27 12:18 -0700
            Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-26 17:44 -0700
        Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-26 17:43 -0700
    Re: Need help with iptables and ftp Dan Purgert <dan@djph.net> - 2018-08-28 11:28 +0000
      Re: Need help with iptables and ftp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-08-29 05:38 +0000
        Re: Need help with iptables and ftp Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-08-29 10:13 +0300
        Re: Need help with iptables and ftp Dan Purgert <dan@djph.net> - 2018-08-29 09:52 +0000
          Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-29 12:13 +0000
            Re: Need help with iptables and ftp Dan Purgert <dan@djph.net> - 2018-08-29 12:27 +0000
              Re: Need help with iptables and ftp "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2018-08-29 11:14 -0400
                Re: Need help with iptables and ftp Aragorn <thorongil@telenet.be> - 2018-08-29 23:15 +0200
                Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-08-30 10:35 +0200
                  Re: Need help with iptables and ftp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-08-30 13:16 +0000
                    Re: Need help with iptables and ftp Richard Kettlewell <invalid@invalid.invalid> - 2018-08-30 16:15 +0100
                    Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-08-30 18:42 +0200
                      Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-31 00:31 +0000
                        Re: Need help with iptables and ftp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-08-31 05:49 +0000
                        Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-08-31 12:48 +0200
                          Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-31 22:11 +0000
                            Re: Need help with iptables and ftp Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-09-01 09:56 +0300
                              Re: Need help with iptables and ftp Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-01 16:14 +0200
                                Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-09-04 18:00 +0200
                                  Re: Need help with iptables and ftp Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-04 20:36 +0200
                                    Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-09-05 10:25 +0200
                                      Re: Need help with iptables and ftp Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-05 20:30 +0200
                                        Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-09-06 00:03 +0200
                      Re: Need help with iptables and ftp Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-01 15:56 +0200
                        Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-09-01 19:18 +0000
                          Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-09-04 18:01 +0200
                  Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-31 00:25 +0000
                    Re: Need help with iptables and ftp "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2018-08-30 20:34 -0400
                    Re: Need help with iptables and ftp Dan Purgert <dan@djph.net> - 2018-08-31 09:25 +0000
                      Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-08-31 12:50 +0200
                        Re: Need help with iptables and ftp Dan Purgert <dan@djph.net> - 2018-08-31 11:13 +0000
                      Re: Need help with iptables and ftp Allodoxaphobia <knock_yourself_out@example.net> - 2018-08-31 12:30 +0000

Page 1 of 3  [1] 2 3  Next page →

#4186 — Need help with iptables and ftp

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

[toc] | [next] | [standalone]

#4187

On 08/24/2018 03:39 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


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

[toc] | [prev] | [next] | [standalone]

#4189

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   .

[toc] | [prev] | [next] | [standalone]

#4190

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:

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

[toc] | [prev] | [next] | [standalone]

#4191

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

[toc] | [prev] | [next] | [standalone]

#4192

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

[toc] | [prev] | [next] | [standalone]

#4193

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?

[toc] | [prev] | [next] | [standalone]

#4194

On 08/26/2018 05:02 PM, William Unruh wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#4197

On 2018-08-27, T <T@invalid.invalid> wrote:
> On 08/26/2018 05:02 PM, William Unruh wrote:
>> 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.
>
> 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.

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

[toc] | [prev] | [next] | [standalone]

#4198

On 08/26/2018 07:00 PM, William Unruh wrote:
> On 2018-08-27, T <T@invalid.invalid> wrote:
>> On 08/26/2018 05:02 PM, William Unruh wrote:
>>> 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.
>>
>> 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.

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



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

[toc] | [prev] | [next] | [standalone]

#4199

On Sun, 26 Aug 2018 22:00:39 -0400, William Unruh <unruh@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 dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#4200

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?

[toc] | [prev] | [next] | [standalone]

#4201

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.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#4202

On 08/26/2018 09:29 PM, David W. Hodgins wrote:
> 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.
> 
> Regards, Dave Hodgins
> 

Thank you!

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

[toc] | [prev] | [next] | [standalone]

#4204

On 2018-08-27, T <T@invalid.invalid> wrote:
> On 08/26/2018 09:29 PM, David W. Hodgins wrote:
>> 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.
>> 
>> Regards, Dave Hodgins
>> 
>
> Thank you!
>
> I bet it is a Samba thing for my Windows virtual machines
>

No. It is a Linux thing. 

[toc] | [prev] | [next] | [standalone]

#4248

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.

[toc] | [prev] | [next] | [standalone]

#4203

On 2018-08-27, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
> On Sun, 26 Aug 2018 22:00:39 -0400, William Unruh <unruh@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

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

[toc] | [prev] | [next] | [standalone]

#4205

On Mon, 27 Aug 2018 05:44:25 -0400, William Unruh <unruh@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.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#4208

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.

[toc] | [prev] | [next] | [standalone]

#4249

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.os.linux.networking

csiph-web