لطفا منتظر باشید ...
FTP and Firewalls
Modern application protocols run over a single network connection. If you make a Web request your Web browser requests a connection to port 80, transmits a request for information over that channel, and receives the answer over that same channel. SSH opens a single connection over port 22 and sends all its information over that connection. Experience and experiments with older protocols taught the wisdom of this approach. FTP is an older protocol, and it provided a wealth of education on this subject.The original version of FTP (called active FTP today) required the client to send a connection to the server on TCP port 21. The server would then open a connection back to the client from port 20 to some random high-numbered port on the client. This is called a backchannel. On a network protocol level, however, no connection exists between the initial request and the backchannel. There's no way for a firewall to use stateful inspection to sort out if such a connection is allowed. Worse, if the client is behind a NAT device, there's no way to determine which actual IP an incoming FTP response should go to!On a technical level a better choice is to use passive FTP, an updated version of the protocol that only uses one TCP connection. Not all clients support passive FTP, however, and this can lead to an endless round of user education and increased help desk load. As help desk people are usually pretty close to the breaking point anyway, increasing the pressure on them isn't a good move.OpenBSD works around this by including an active FTP application proxy, ftp-proxy(8). Once configured, when a user makes a FTP request that request is redirected to the application proxy. The proxy keeps track of the FTP protocol transactions, receives the incoming active FTP data stream, and redirects it to the appropriate client. The proxy requires two parts: the proxy application and the redirect rules.
Configuring the FTP Proxy Application
Ftp-proxy(8) daemon runs out of inetd(8). We discuss inetd.conf in Chapter 14, so if you want full details on how this configuration works look there. First, be sure that inetd is running on your system. Not only should "inetd" appear in the system process list, but also you should have a line like this in /etc/rc.conf.inetd=YES
Now you'll need to add an entry to /etc/inetd.conf for this daemon.127.0.0.1:8021 1 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy 2
Here, we're running the proxy on port 1 8021 of the firewall machine. We're also running the ftp-proxy command as "ftp-proxy," without any command-line arguments. If you want to change the command-line arguments, edit them at the end of this line.For full details on ftp-proxy(8), read the man page. Here are some of the most useful features.
Anonymous FTP Only
You might want to only allow anonymous FTP, especially in situations where data theft is a possibility. (While there are other ways to get data out of a network, FTP uploads are perhaps the easiest.) The "-A" flag tells ftp-proxy to only allow FTP connections with the server logins of "anonymous" or "ftp."
NAT Mode
The proxy must run slightly differently when using NAT. The "-n" flag tells ftp-proxy that it is running in a NAT environment and to make the appropriate protocol changes.
Timeouts
By default, the proxy does not time out. On a long-running firewall with sloppy clients, this can result in a gradual increase of firewall resource use. Use the "-t" flag to specify a number of seconds after which an idle connection will be disconnected. This will only affect people who leave an FTP session open without doing anything in it. For example, to set a timeout of 300 seconds (5 minutes), you would add this to /etc/inetd.conf.127.0.0.1:8021 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy -t 300
FTP Logging
You might want to log which particular transfers your users make. The "-V" flag will log everything the users do to syslogd(8), which you can redirect as you wish using /etc/syslog.conf (see Chapter 14).
FTP Proxy PF Rules
To use the proxy, you must have three sets of rules: a redirection rule for clients, a rule to allow the proxy to speak to the desired FTP servers, and a rule to allow the backchannel connections to reach the application proxy. The client redirection rule is very similar to the example we saw for Squid.rdr on 1 fxp1 proto tcp from 2 192.168.1.0/24 to 3 any 4 port 21 -> 5 127.0.0.1 port
8021
We're redirecting all incoming traffic on our 1 internal interface from our 2 internal network that tries to go to the 4 FTP command port of 3 any server on the Internet, to the FTP proxy running on port 5 8021 of the firewall itself.Your firewall may or may not allow connections out to the world. If you have a "default deny" security stance, you will need to explicitly allow the firewall to connect to outside FTP servers.pass out of fxp0 proto tcp from fxp0 to any port 21 keep state
Now we need to allow backchannel connections to the FTP proxy itself. Presumably you're blocking all inbound connections by default. How can you possibly know which port a connection will be coming back in on? Here you can take advantage of the fact that ftp-proxy(8) runs as the user "proxy." Remember, PF has the ability to allow connections to or from particular users on the firewall itself.pass in on fxp0 proto tcp from any to fxp0 user proxy keep state
You can, of course, use any other PF features you like in combination with ftp-proxy(8): Restrict certain users from using FTP, only allow access to particular FTP sites, and so on.
