Linux Passive FTP Configuration

Hello,

I am using RedHat Legacy Linux 7.2 on each of two servers.

Server A intends to invoke an FTP client to transfer a file to/from
the FTP daemon on Server B.

The FTP daemon is running proftpd 1.2.1.

The FTP file transfer must be done in passive mode, not active mode.

Passive FTP is problematic. The firewall must be opened to a
restricted range of high-numbered
ports > 1023.

Okay, here is what I have done, and passive FTP still does not work.
Why?

1. Made sure our network firewall allows access to the FTP daemon
port 21 from anywhere.
2. Made sure the FTP daemon port 21 is allowed to talk to ports >
1023.
3. Made sure FTP daemon ports > 1023 are open to use from anywhere.
4. FTP daemon ports > 1023 are allowed access to remote ports > 1023.

Actually, I cannot confirm 1 thru 4, as I have to rely on the word of
our Network Firewall Administrator, who claims these actions or their
equivalent, are in effect. Not sure what he
means by equivalent.

Reading prior postings regarding passive FTP on this group
comp.os.linux.networking, I have
learned that certain actions may need to be taken within Linux itself.

That is, does Linux implement its own firewall in software, and could
this supercede or block
the actions of the network firewall?

What is /sbin/iptables and how do I configure it? That file is in
binary.

What is /etc/sysconfig/ipchains and where can I learn about it? How
do I edit it? I have used vi.

One posting suggested adding this line to ipchains and claimed
success. Alas, not in my case.

-A input -s serverIPaddress 20 -d 0/0 -p tcp -j ACCEPT

before this ipchains statement:

-A input -s 0/0 -d 0/0 -p tcp -y -j REJECT

Did so, it had no effect.

Also, as we are using proftpd, modified /usr/local/etc/proftpd.conf to
add this statement:

PassivePorts 8000 8299

and this too has not helped.

From Server A, I logon via FTP client successfully to FTP daemon on
Server B. This is
evidenced by receiving the results of a dir command when Not in
passive mode.

Once I toggle passive mode (and in FTP debug mode this shows ---> PASV
to confirm),
get this error:

ftp> dir
---> PASV
227 Entering Passive Mode (1xx,2x,2x,3x,15,87). (*** X's added as a
mask by me, for security.***
ftp: connect: Connection refused

I am asking our Network Firewall Administrator for a sniffer trace.
This is delayed and I cannot
wait.

From another posting, I have learned that the Passive mode IP address
last two numbers
(15,87) shows the daemon's passive port number, calculated as follows:

15*256 + 87 = 3927.

Okay, so why is this not in the range 8000 - 8299 as coded in the
PassivePorts statement?

I would be much obliged for any assistance.

Thank you.

Fountain_spray

On Jul 9, 3:29*pm, Fountain_spray <fountain_sp...@yahoo.com> wrote:
> Hello,
>
> I am using RedHat Legacy Linux 7.2 on each of two servers.
>
> Server A intends to invoke an FTP client to transfer a file to/from
> the FTP daemon on Server B.
>
> The FTP daemon is running proftpd 1.2.1.
>
> The FTP file transfer must be done in passive mode, not active mode.
>
> Passive FTP is problematic. *The firewall must be opened to a
> restricted range of high-numbered
> ports > 1023.
>
> Okay, here is what I have done, and passive FTP still does not work.
> Why?
>
> 1. *Made sure our network firewall allows access to the FTP daemon
> port 21 from anywhere.
> 2. *Made sure the FTP daemon port 21 is allowed to talk to ports >
> 1023.
> 3. *Made sure FTP daemon ports > 1023 are open to use from anywhere.
> 4. *FTP daemon ports > 1023 are allowed access to remote ports > 1023.
>
> Actually, I cannot confirm 1 thru 4, as I have to rely on the word of
> our Network Firewall Administrator, who claims these actions or their
> equivalent, are in effect. *Not sure what he
> means by equivalent.
>
> Reading prior postings regarding passive FTP on this group
> comp.os.linux.networking, I have
> learned that certain actions may need to be taken within Linux itself.
>
> That is, does Linux implement its own firewall in software, and could
> this supercede or block
> the actions of the network firewall?
>
> What is /sbin/iptables and how do I configure it? *That file is in
> binary.
>
> What is /etc/sysconfig/ipchains and where can I learn about it? *How
> do I edit it? *I have used vi.
>
> One posting suggested adding this line to ipchains and claimed
> success. *Alas, not in my case.
>
> -A input -s serverIPaddress 20 -d 0/0 -p tcp -j ACCEPT
>
> before this ipchains statement:
>
> -A input -s 0/0 -d 0/0 -p tcp -y -j REJECT
>
> Did so, it had no effect.
>
> Also, as we are using proftpd, modified /usr/local/etc/proftpd.conf to
> add this statement:
>
> PassivePorts 8000 8299
>
> and this too has not helped.
>
> From Server A, I logon via FTP client successfully to FTP daemon on
> Server B. *This is
> evidenced by receiving the results of a dir command when Not in
> passive mode.
>
> Once I toggle passive mode (and in FTP debug mode this shows ---> PASV
> to confirm),
> get this error:
>
> ftp> dir
> ---> PASV
> 227 Entering Passive Mode (1xx,2x,2x,3x,15,87). *(*** X's added as a
> mask by me, for security.***
> ftp: connect: Connection refused
>
> I am asking our Network Firewall Administrator for a sniffer trace.
> This is delayed and I cannot
> wait.
>
> From another posting, I have learned that the Passive mode IP address
> last two numbers
> (15,87) shows the daemon's passive port number, calculated as follows:
>
> 15*256 + 87 = 3927.
>
> Okay, so why is this not in the range 8000 - 8299 as coded in the
> PassivePorts statement?
>
> I would be much obliged for any assistance.
>
> Thank you.
>
> Fountain_spray

This is the author again. Our proftpd is 1.2.2 not 1.2.1. Also, we
have ping disabled. Could that be disabling
passive FTP as well? How can we enable passive FTP while keeping ping
disabled (for security reasons)?

Thanks.

Fountain_spray

Hello,

Fountain_spray a écrit :
>>
>>I am using RedHat Legacy Linux 7.2 on each of two servers.
>>
>>Server A intends to invoke an FTP client to transfer a file to/from
>>the FTP daemon on Server B.
>>
>>The FTP daemon is running proftpd 1.2.2.
>>
>>The FTP file transfer must be done in passive mode, not active mode.
>>
>>Passive FTP is problematic. The firewall must be opened to a
>>restricted range of high-numbered ports > 1023.

Do you mean problematic in general or problematic in your specific
situation ? Passive and active modes are equally problematic in general,
as they are symmetric.

[...]
>>That is, does Linux implement its own firewall in software, and could
>>this supercede or block the actions of the network firewall?

Linux has IP filtering capabilities. Its actions cascade with those of
the network firewall.

>>What is /sbin/iptables and how do I configure it? That file is in
>>binary.

/sbin/iptables is the userland tool used to manage the rules enforced by
the packet filter in kernels 2.4 and 2.6. Read man iptables.

>>What is /etc/sysconfig/ipchains and where can I learn about it? How
>>do I edit it? I have used vi.

/etc/sysconfig/ stuff is RedHat specific. ipchains is the old tool used
to manage the rules enforced by the packet filter in kernel 2.2.
What is the kernel version ?

>>Also, as we are using proftpd, modified /usr/local/etc/proftpd.conf to
>>add this statement:
>>
>>PassivePorts 8000 8299
[...]
>>ftp> dir
>>---> PASV
>>227 Entering Passive Mode (1xx,2x,2x,3x,15,87). (*** X's added as a
>>mask by me, for security.***
>>ftp: connect: Connection refused
>>
>>I am asking our Network Firewall Administrator for a sniffer trace.
>>This is delayed and I cannot

Can't you do a sniffer trace on both servers ?

>>15*256 + 87 = 3927.
>>
>>Okay, so why is this not in the range 8000 - 8299 as coded in the
>>PassivePorts statement?

Did you restard proftpd so the change is taken into account ?

> Also, we have ping disabled. Could that be disabling
> passive FTP as well?

No, they are totally unrelated.

On Jul 10, 4:42*am, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
wrote:
> Hello,
>
> Fountain_spray a écrit :
>
>
>
> >>I am using RedHat Legacy Linux 7.2 on each of two servers.
>
> >>Server A intends to invoke an FTP client to transfer a file to/from
> >>the FTP daemon on Server B.
>
> >>The FTP daemon is running proftpd 1.2.2.
>
> >>The FTP file transfer must be done in passive mode, not active mode.
>
> >>Passive FTP is problematic. *The firewall must be opened to a
> >>restricted range of high-numbered ports > 1023.
>
> Do you mean problematic in general or problematic in your specific
> situation ? Passive and active modes are equally problematic in general,
> as they are symmetric.
>
> [...]
>
> >>That is, does Linux implement its own firewall in software, and could
> >>this supercede or block the actions of the network firewall?
>
> Linux has IP filtering capabilities. Its actions cascade with those of
> the network firewall.
>
> >>What is /sbin/iptables and how do I configure it? *That file is in
> >>binary.
>
> /sbin/iptables is the userland tool used to manage the rules enforced by
> the packet filter in kernels 2.4 and 2.6. Read man iptables.
>
> >>What is /etc/sysconfig/ipchains and where can I learn about it? *How
> >>do I edit it? *I have used vi.
>
> /etc/sysconfig/ stuff is RedHat specific. ipchains is the old tool used
> to manage the rules enforced by the packet filter in kernel 2.2.
> What is the kernel version ?
>
>
>
> >>Also, as we are using proftpd, modified /usr/local/etc/proftpd.conf to
> >>add this statement:
>
> >>PassivePorts 8000 8299
> [...]
> >>ftp> dir
> >>---> PASV
> >>227 Entering Passive Mode (1xx,2x,2x,3x,15,87). *(*** X's added as a
> >>mask by me, for security.***
> >>ftp: connect: Connection refused
>
> >>I am asking our Network Firewall Administrator for a sniffer trace.
> >>This is delayed and I cannot
>
> Can't you do a sniffer trace on both servers ?
>
> >>15*256 + 87 = 3927.
>
> >>Okay, so why is this not in the range 8000 - 8299 as coded in the
> >>PassivePorts statement?
>
> Did you restard proftpd so the change is taken into account ?
>
> > Also, we have ping disabled. Could that be disabling
> > passive FTP as well?
>
> No, they are totally unrelated.

Thank you, Pascal (Great name!), for the courtesy of your reply.

Now, replying to your replies:

1. Passive mode FTP is problematic in my specific situation.
2. So Linux IP filtering is effectively "AND'ed" with the network
firewall?
3. I am now reading man iptables. We also have man ipchains.
Reading both. I would rather these did not exist,
it complicates the task of enabling passive FTP immensely.
4. How can I tell what RH kernel I have?
5. I have not been able to get our Network Firewall Administrator to
do a sniffer trace on one server, let alone two.
I shall ask him to trace both Server A and Server B simultaneously.
6. Yes, I did restart proftpd on both Server A and Server B, and
still the PassivePort range is not used. Why?
I defined the same PassivePort range on both servers. Bad idea?
7. Glad to hear that a disabled Ping does is independent of enabling
passive FTP.

So, I am in a quandary.

If anyone has the magic bullet that will enable passive FTP, please
post.

Fountain_spray

Fountain_spray a écrit :
>
> 2. So Linux IP filtering is effectively "AND'ed" with the network
> firewall?

Obviously. How could it be otherwise ? If either filter drops a packet,
that packet won't get through regarless the other filter accepted or
would have accepted it.

> 3. I am now reading man iptables. We also have man ipchains.
> Reading both. I would rather these did not exist,
> it complicates the task of enabling passive FTP immensely.

iptables and ipchains being present does not mean that they are active.
iptables-save will tell if iptables is active. I do not remember about
ipchains (too old).

> 4. How can I tell what RH kernel I have?

uname -a

> 5. I have not been able to get our Network Firewall Administrator to
> do a sniffer trace on one server, let alone two.
> I shall ask him to trace both Server A and Server B simultaneously.

I meant tnat you can do it yourself If you have root access on both
servers - I guess this is required in order to setup proftpd. You do not
need the firewall administrator.

> 6. Yes, I did restart proftpd on both Server A and Server B, and
> still the PassivePort range is not used. Why?

I have no clue. Is the firewall doing NAT (address translation) ?

> I defined the same PassivePort range on both servers. Bad idea?

It does not matter.

On Jul 10, 9:34*am, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
wrote:
> Fountain_spray a écrit :
>
>
>
> > 2. *So Linux IP filtering is effectively "AND'ed" with the network
> > firewall?
>
> Obviously. How could it be otherwise ? If either filter drops a packet,
> that packet won't get through regarless the other filter accepted or
> would have accepted it.
>
> > 3. *I am now reading man iptables. *We also have man ipchains.
> > Reading both. *I would rather these did not exist,
> > it complicates the task of enabling passive FTP immensely.
>
> iptables and ipchains being present does not mean that they are active.
> iptables-save will tell if iptables is active. I do not remember about
> ipchains (too old).
>
> > 4. *How can I tell what RH kernel I have?
>
> uname -a
>
> > 5. *I have not been able to get our Network Firewall Administrator to
> > do a sniffer trace on one server, let alone two.
> > I shall ask him to trace both Server A and Server B simultaneously.
>
> I meant tnat you can do it yourself If you have root access on both
> servers - I guess this is required in order to setup proftpd. You do not
> need the firewall administrator.
>
> > 6. *Yes, I did restart proftpd on both Server A and Server B, and
> > still the PassivePort range is not used. *Why?
>
> I have no clue. Is the firewall doing NAT (address translation) ?
>
> > I defined the same PassivePort range on both servers. *Bad idea?
>
> It does not matter.

Pascal,

3. /sbin/iptables-save

returns to the command prompt with no further comment.

/sbin/iptables -save
returns this message:

iptables v1.2.5: no command specified
Try `iptables -h' or 'iptables --help' for more information.

So, then /sbin/iptables-save is the correct form of the command. What
is it telling me?

4. RH kernels:

uname -a

On Server A (where passive FTP client is running), returns:

Linux ServerA.name.masked 2.4.9-34 #1 Sat Jun 1 06:25:16 EDT 2002 i686
i686 i386 GNU/Linux


On Server B (where proftpd daemon for FTP server is running), returns:

Linux ServerB.name.masked 2.4.18-27.7.x #1 Fri Mar 14 06:44:53 EST
2003 i686 unknown

(The true domain names for each server have been masked, or typed
over, for this posting, for security reasons.)

5. Yes, I have root access to both servers.

Yet I have no clue how to do a sniffer trace.

Any suggestions? Where to read, etc.

6. Is the firewall doing Network Address Translation (NAT)?

Are you referring to the Linux kernel firewall (iptables/ipchains) or
to the Network Firewall Administrator's firewall?

In either case, I believe the answer is no.

6+. PassivePort -- why is this not working? I am sure I updated the
correct copy, in /usr/local/etc/proftpd.conf

# Set port range for passive-mode FTP
PassivePorts 8000 8299

Thank you for your valued assistance.

Fountain_spray

Fountain_spray a écrit :
>
> 3. /sbin/iptables-save
>
> returns to the command prompt with no further comment.

Then iptables is not loaded.

> On Server A (where passive FTP client is running), returns:
>
> Linux ServerA.name.masked 2.4.9-34 #1 Sat Jun 1 06:25:16 EDT 2002 i686
> i686 i386 GNU/Linux
>
> On Server B (where proftpd daemon for FTP server is running), returns:
>
> Linux ServerB.name.masked 2.4.18-27.7.x #1 Fri Mar 14 06:44:53 EST
> 2003 i686 unknown

Both 2.4 kernels, so it is unlikely that ipchains is used.

> 5. Yes, I have root access to both servers.
>
> Yet I have no clue how to do a sniffer trace.
>
> Any suggestions? Where to read, etc.

tcpdump (console)
wireshark (GUI, formerly ethereal) or tshark (console, formerly tethereal)

> 6. Is the firewall doing Network Address Translation (NAT)?
>
> Are you referring to the Linux kernel firewall (iptables/ipchains) or
> to the Network Firewall Administrator's firewall?

The network firewall. Anyway, sniffing the FTP traffic will show it.
I asked because some NAT devices are known to mangle FTP data ports.

On Jul 11, 5:02*am, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
wrote:
> Fountain_spray a écrit :
>
>
>
> > 3. */sbin/iptables-save
>
> > returns to the command prompt with no further comment.
>
> Then iptables is not loaded.
>
> > On Server A (where passive FTP client is running), returns:
>
> > Linux ServerA.name.masked 2.4.9-34 #1 Sat Jun 1 06:25:16 EDT 2002 i686
> > i686 i386 GNU/Linux
>
> > On Server B (where proftpd daemon for FTP server is running), returns:
>
> > Linux ServerB.name.masked 2.4.18-27.7.x #1 Fri Mar 14 06:44:53 EST
> > 2003 i686 unknown
>
> Both 2.4 kernels, so it is unlikely that ipchains is used.
>
> > 5. *Yes, I have root access to both servers.
>
> > Yet I have no clue how to do a sniffer trace.
>
> > Any suggestions? *Where to read, etc.
>
> tcpdump (console)
> wireshark (GUI, formerly ethereal) or tshark (console, formerly tethereal)
>
> > 6. *Is the firewall doing Network Address Translation (NAT)?
>
> > Are you referring to the Linux kernel firewall (iptables/ipchains) or
> > to the Network Firewall Administrator's firewall?
>
> The network firewall. Anyway, sniffing the FTP traffic will show it.
> I asked because some NAT devices are known to mangle FTP data ports.

Pascal,

Okay, iptables/ipchains are not active, and NAT is not used on our
Network Firewall.

I have used tcpdump for my sniffer trace and here is the deadly
message:

12:15:46.247308 ServerB.name.masked > ServerA.name.masked: icmp:
ServerB.name.masked tcp port 4070 unreachable [tos 0xc0]

The deadly tcp port 4070 listed in the tcpdump message matches the
following displayed on the client FTP session
(ServerA):

ftp> dir
ftp: setsockopt (ignored): Permission denied
---> PASV
227 Entering Passive Mode (1xx,2y,1z,3w,15,230). *** high order
octets masked by author for security purposes ***
ftp: connect: Connection refused

15 * 256 + 230 = 4070

So, the tcpdump message is saying that ServerA (client) is not allowed
to passively send data to data port 4070
on ServerB.

Strangely, PassivePorts 8000 8299 is not selected.

Our Network Firewall Administrator has told me he has allowed test
ServerA full access to ServerB through
his firewall.

We'll see about that!

The Firewall state necessary for passive FTP is:

1. Network firewall must allow access to the FTP daemon port 21 from
anywhere.
2. FTP daemon port 21 must be allowed to talk to ports > 1023.
3. FTP daemon ports > 1023 are open to use from anywhere.
4. FTP daemon ports > 1023 are allowed access to remote ports >
1023.

Of these four conditions, it appears #3 is the one that is violated.
Or is it #4? Pascal?

Regards,

Fountain_spray