PF ftp-proxy not adding rules to PF

ucc

New Member


Messages: 10

I have fresh a server running FreeBSD 10.3-RELEASE-p11 it has a connection to the internet. The /etc/pf.conf has a rule blocking all incoming packets except my ssh connection, dns, ntp and icmp.

Now I wanted to enable outgoing ftp (e.g. for updates) and found ftp-proxy(). Then made the following adjustments to my pf.config restarted PF and fired up the ftp-proxy with /usr/sbin/ftp-proxy -D7 -v.

Code:
### ftp ###
 nat-anchor "ftp-proxy/*"
 rdr-anchor "ftp-proxy/*"
 rdr pass proto tcp from any to any port ftp -> 127.0.0.1 port 8021

### deny others ###
 no rdr

### default block ###
 block in  log on $ExtIf

### ssh, dns, ntp and icmp rules ###

### ftp anchor ###
 anchor "ftp-proxy/*"
 pass out proto tcp from any to any port 21 keep state
Then I call fetch ftp://ftp.freebsd.org/pub/FreeBSD/README.TXT and fetch() prints No route to host. Consulting /var/log/messages shows that the rdr to the proxy is working: Mar 13 21:15:11 kahless ftp-proxy[645]: #1 server refused connection. Investigating the /var/log/pf.log shows that the incoming traffic was blocked by my default block rule:

Code:
2017-03-13 21:15:44.410819 rule 1..16777216/0(match): block in on re0: 213.138.116.78.21 > [my_ip].52314: Flags [S.], seq 247602936, ack 3020026929, win 65535, options [mss 1460,nop,wscale 11,sackOK,TS val 3633337037 ecr 31690932], length 0
2017-03-13 21:15:44.639925 rule 1..16777216/0(match): block in on re0: 213.138.116.78.21 > [my_ip].52314: Flags [S.], seq 247602936, ack 3020026929, win 65535, options [mss 1460,nop,wscale 11,sackOK,TS val 3633337037 ecr 31694161], length 0
2017-03-13 21:15:47.639959 rule 1..16777216/0(match): block in on re0: 213.138.116.78.21 > [my_ip].52314: Flags [S.], seq 247602936, ack 3020026929, win 65535, options [mss 1460,nop,wscale 11,sackOK,TS val 3633337037 ecr 31694161], length 0
2017-03-13 21:15:47.846522 rule 1..16777216/0(match): block in on re0: 213.138.116.78.21 > [my_ip].52314: Flags [S.], seq 247602936, ack 3020026929, win 65535, options [mss 1460,nop,wscale 11,sackOK,TS val 3633337037 ecr 31697368], length 0
Checking for subanchors with pfctl -vv -sA returned nothing, so my guess would be, that ftp-proxy is not adding rules to my PF.

So is my ftp-proxy not adding rules or have I made the wrong assumption?
Has anybody have had similar setup and have a suggestion what I could do better?
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 9,282
Messages: 33,825

Try running ftp-proxy(8) with debug enabled on the foreground. Does that output anything interesting? It might provide clues as to what it's doing and if it succeeds or not.

Code:
     -d      Do not daemonize.  The process will stay in the foreground,
             logging to standard error.
 
OP
U

ucc

New Member


Messages: 10

root@my_svr:~ # /usr/sbin/ftp-proxy -D7 -v -d
listening on 127.0.0.1 port 8021


That gave me even less output, there was nothing in the messages log.

How do others cope with this, I mean, you cant just not block high ports, right?
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 9,282
Messages: 33,825

No, the 'problem' with FTP is the dynamic nature of the data channel. Which makes it difficult to firewall properly. Alternatively you can try switching to SFTP (basically FTP over SSH). This only requires one port (22) and doesn't use an additional dynamically created port for the data. And besides that, it's better secured (encryption and authentication).
 

diizzy

Well-Known Member

Reaction score: 83
Messages: 307

You probably want something like
Code:
 pass in quick on $ext_if inet proto tcp to ($ext_if) port ftp-data user proxy
 
OP
U

ucc

New Member


Messages: 10

No, the 'problem' with FTP is the dynamic nature of the data channel. Which makes it difficult to firewall properly.
Absolutely, that's why there is ftp-proxy() – it just isn't working properly. (Side note, the Data I'm trying to retrieve via ftp is signed, so I could detect tampering.)

You probably want something like
pass in quick on $ext_if inet proto tcp to ($ext_if) port ftp-data user proxy
Well that kinda is what ftp-proxy generates and adds to the ftp-proxy anchor. There is an Example over at https://calomel.org/ftp_proxy.html, just search for: ftp-proxy/25552.5

But a good indicator was the thing about the user proxy, he might not have the permission to add rules/anchors to my PF. I'll have a look there.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 9,282
Messages: 33,825

From ftp-proxy(8):
Code:
CONFIGURATION
     To make use of the proxy, pf.conf(5) needs the following rules.  All
     anchors are mandatory.  Adjust the rules as needed.
                 
     In the NAT section:
                                
       nat-anchor "ftp-proxy/*"         
       rdr-anchor "ftp-proxy/*"                
       rdr pass on $int_if proto tcp from $lan to any port 21 -> \
           127.0.0.1 port 8021                      
                                                      
     In the rule section:                                 
                                                            
       anchor "ftp-proxy/*"                                 
       pass out proto tcp from $proxy to any port 21
 
OP
U

ucc

New Member


Messages: 10

Yes, that's what I have in my /etc/pf.conf (I posted the contents in my first post).

I also made sure, that my securelevel(7) is below 1.

So is there any way (except patching the ftp-proxy) to find out, why the ftp-proxy is not adding rules?
 
OP
U

ucc

New Member


Messages: 10

So, weeks have gone by and the only thing I found (and yes I have finally given up) was this small sentence from the website mentioned before:
Remember, ftp connections initiated on the firewall do not use the ftp-proxy daemon; only ftp requests that go through the firewall.
This lead in me giving up on ftp-proxy() and now finding other ways to update my pkgs.


A good resource for anyone with similar problems is this thread (read till the end): https://forums.freebsd.org/threads/41575/
 
Top