Our firewall needs some changes to support this new FTP application design.
Let's check it out.
Before we dive in, I want to explain what we are changing and why.
Passive mode FTP still requires the client to initiate a control
channel with the server using TCP port 21; however,
the server tells the client which dynamic port to use for the data
session so there is no outside-to-inside TCP session.
This is generally more manageable,
and we can improve it by tightening the range of
dynamic server ports for allocation.
We will be using ports 42500 to 42599 to bound our port range.
One way to help reduce the attack surface of FTP passive
mode is to constrain the range of dynamic ports that the
server allocates for file transfers.
We need to edit the FTP server's config file for this.
I've added two new configuration options to the bottom of the file.
The pasv_max_port option identifies the upper bound for port numbers,
and the pasv_min_port option identifies the lower bound.
In this example,
the server will allocate port numbers from 42500 to 42599 inclusive.
This allows for up to 100 concurrent file transfers.
The smaller the range, the smaller the attack surface.
Try to identify a range that is sufficient to meet user demand as well.
After making changes,
be sure to restart the vsftpd service so the changes take effect.
Now that we've buttoned up the port ranges, we can craft the access list on R3.
Let's start with the inside-in policy.
The first rule is identical to FTP active mode.
Remember that regardless of the FTP flavor,
the TCP port 21 traffic always operates the same way,
as this is the signaling channel.
We always need to allow that through.
The second rule now permits traffic to ports 42500 through 42599,
which is equal to our newly configured FTP passive port range.
Remember that these are destination ports from the client's perspective,
as they are open on the FTP server, much like TCP port 20 in FTP active mode.
The outside-in policy is a little strange, but bear with me.
The first rule is, again,
identical to its equivalent in the FTP active mode policy.
Traffic sourced from TCP port 21 needs to be allowed inbound towards the client.
The second rule looks even more permissive than the FTP active rule,
and that's technically true.
Now we allow 100 different source ports versus just port 20.
Why on earth would anyone claim that passive mode is a security improvement?
The answer is that stateful firewalls wouldn't need to explicitly
permit these return flows from the outside in.
I decided not to explain stateful firewalls,
as they are more complex and would take time away from FTP.
I also wanted to highlight how the different ports and
protocols interact without taking shortcuts.
Just use these ACLs as tools in developing your own policy,
keeping in mind that different security appliances
may inspect traffic differently.
Let's quickly retest using a simplified lftp script.
Like in the FTP active mode security demo,
this script leaves debugging off and performs both a
download and an upload in sequence.
Let's run the script to ensure our firewall policy is sound.
Well, no news is good news,
but let's check to ensure R1.cfg got downloaded successfully.
To finish up, let's check for matches on our firewall policy.
We need to run the show command again to get our updated counts.
Both our inside-in and outside-in access lists report
several matches on the permit entries,
revealing that both FTP signaling and FTP data traffic
were passed through successfully.
We don't see any matches on our final deny rule,
which is great,
as it means we've correctly accounted for all legitimate FTP flows.
We've seen the FTP passive setup already,
but let's quickly verify that a port from the server's
configured range is used in the debug.
First,
the client sends the PASV message to the server to request a
data channel port from the FTP server.
The server replies with, I'm ready for your connection on port 42553,
which is within our configured range of 42500 to 42599.
I won't belabor the rest of the transmission,
but we can clearly see destination TCP port 42553 used to communicate with the FTP server.