redirect outbound packets originating from localhost to locally assign address (- ftp-proxy)
Hello, i'm new on this list, so please be patient with me. Anyway - I did my homework (at least i think so) but i'm stuck nevertheless. All man pages and docs i found seem to indicate that what i want is impossible, but i hope, someone might have an idea... I want to use ftp-proxy for outgoing client-requests. The main reason for that is the automatic handling of pf rules that allow traffic on the data connection without opening up the firewall to any ip/port for outbound traffic. I'm unsing OpenBSD 5.0. I know, the ftp-proxy is purely transparent and is invoked by a divert-to rule. But - divert-to is only allowed on inbound rules - rdr-to is not supported on outbound rules, if the destination is a locally assigned address So how can i get packets to port 21 that originate from the host itself processed by the ftp-proxy. Background: I'm using squid on this host and i want it to serve ftp:// URLs via http. This usage doesnt seem to be unusual and there might be a solution i didn't think of/find... Thanks in advance Thomas
OpenBsd 4.3 PF with Reverse ftp-proxy problem
Hi,
I try to safty my ftp-server in DMZ.
FTP-CLIENT( PASS ON MODE )
|
|
INTERNET
||
ADSL_GW FIBER_GW
| |
PPPOE FIBER LINK
| |
|---Routeur---|
| |
| |
LAN DMZFTP-SERVER
*The reverse ftp-proxy :
proxy10334 0.0 0.1 340 904 ?? SsTue01PM0:14.27
/usr/sbin/ftp-proxy -v -R 192.168.100.249 -p 8022
My rules :*
..
# FTP-NAT
nat-anchor ftp-proxy/*
# RDR-FTP
rdr-anchor ftp-proxy/*
#RDR FTP-SERVER
rdr log (all) on $EXT_FIBRE_IF proto tcp from !RFC1918 to any port ftp
tag R_PROXY - 127.0.0.1 port 8022
rdr log (all) on $INT_LAN_IF proto tcp from $LAN_NET to $FIBRE_IP_NAT
port ftp - 127.0.0.1 port 8022
rdr pass log (all) on $INT_DMZ_IF proto tcp from $DMZ_NET to
$FIBRE_IP_NAT port ftp - $FTP_SERVER
...
#FTP RULES
anchor ftp-proxy/*
# FTP SERVER
pass in log (all) on $EXT_FIBRE_IF reply-to {($EXT_FIBRE_IF $FIBRE_GW)}
proto tcp from any to port ftp
pass in log (all) on $EXT_FIBRE_IF reply-to {($EXT_FIBRE_IF $FIBRE_GW)}
proto tcp from any to 127.0.0.1 port 8022
my Trace :
*87.100.21.71 is ftp-client
87.100.21.71 is my ftp-server
**10334 is pid of my reverse ftp-proxy*
*192.168.100.249 is FTP-SERVER*
*192.168.100.254 is router if ip DMZ*
tcpdump in the router:
[r...@gw root]# tcpdump -nettt -i pflog0 host client-ftp
tcpdump: listening on pflog0, link-type PFLOG
Mar 10 13:38:07.446193 rule 34/(match) pass in on em1:
87.100.21.71.51980 127.0.0.1.8022: [|tcp] (DF)
Mar 10 13:38:07.446221 rule 1/(match) rdr out on em1: 83.173.67.154.21
87.100.21.71.51980: [|tcp] (DF)
Mar 10 13:38:07.513142 rule 1/(match) rdr in on em1: 87.100.21.71.51980
127.0.0.1.8022: [|tcp] (DF)
Mar 10 13:38:07.516611 rule 1/(match) rdr out on em1: 83.173.67.154.21
87.100.21.71.51980: [|tcp] (DF)
Mar 10 13:38:07.584099 rule 1/(match) rdr in on em1: 87.100.21.71.51980
127.0.0.1.8022: [|tcp] (DF)
Mar 10 13:38:11.748531 rule 1/(match) rdr in on em1: 87.100.21.71.51980
127.0.0.1.8022: [|tcp] (DF)
Mar 10 13:38:11.749418 rule 1/(match) rdr out on em1: 83.173.67.154.21
87.100.21.71.51980: [|tcp] (DF)
Mar 10 13:38:13.247553 rule 1/(match) rdr out on em1: 83.173.67.154.21
87.100.21.71.51980: [|tcp] (DF)
Mar 10 13:38:13.323561 rule 1/(match) rdr in on em1: 87.100.21.71.51980
127.0.0.1.8022: [|tcp] (DF)
Mar 10 13:38:14.974044 rule 1/(match) rdr in on em1: 87.100.21.71.51980
127.0.0.1.8022: [|tcp] (DF)
Mar 10 13:38:14.976943 rule 1/(match) rdr out on em1: 83.173.67.154.21
87.100.21.71.51980: [|tcp] (DF)
Mar 10 13:38:15.044000 rule 1/(match) rdr in on em1: 87.100.21.71.51980
127.0.0.1.8022: [|tcp] (DF)
Mar 10 13:38:15.045999 rule 1/(match) rdr in on em1: 87.100.21.71.51980
127.0.0.1.8022: [|tcp] (DF)
Mar 10 13:38:15.046506 rule 1/(match) rdr out on em1: 83.173.67.154.21
87.100.21.71.51980: [|tcp] (DF)
Mar 10 13:38:16.537917 rule 1/(match) rdr out on em1: 83.173.67.154.21
87.100.21.71.51980: [|tcp] (DF)
Mar 10 13:38:19.538220 rule 1/(match) rdr out on em1: 83.173.67.154.21
87.100.21.71.51980: [|tcp] (DF)
Mar 10 13:38:19.601190 rule 1/(match) rdr in on em1: 87.100.21.71.51980
127.0.0.1.8022: [|tcp] (DF)
Mar 10 13:38:20.313752 rule 1/(match) rdr in on em1: 87.100.21.71.51980
127.0.0.1.8022: [|tcp] (DF)
Mar 10 13:38:20.314627 rule 1/(match) rdr out on em1: 83.173.67.154.21
87.100.21.71.51980: [|tcp] (DF)
Mar 10 13:38:20.379712 rule 1/(match) rdr in on em1: 87.100.21.71.51980
127.0.0.1.8022: [|tcp] (DF)
Mar 10 13:38:20.381231 rule 29.*10334*.8834.0/(match) pass in on em1:
87.100.21.71.63387 192.168.100.249.*32669:* [|tcp] (DF) (--- is
passive socket tp-server listen)
Mar 10 13:38:41.379298 rule 29.10334.8834.0/(match) pass in on em1:
87.100.21.71.63387 192.168.100.249.32669: [|tcp] (DF)
Mar 10 13:39:05.393980 rule 29.10334.8834.0/(match) pass in on em1:
87.100.21.71.63387 192.168.100.249.32669: [|tcp] (DF)
Mar 10 13:39:53.390413 rule 29.10334.8834.0/(match) pass in on em1:
87.100.21.71.53744 192.168.100.249.32669: [|tcp] (DF)
-
tcpdump: listening on pflog0, link-type PFLOG
Mar 10 13:38:07.513262 rule 1/(match) pass out on em2:
192.168.100.254.4267 192.168.100.249.21: [|tcp] (DF)
Mar 10 13:38:20.381226 rule 29.10334.8834.0/(match) pass in on em1:
87.100.21.71.63387 192.168.100.249.32669: [|tcp] (DF)
Mar 10 13:38:20.381246 rule 29.10334.8834.1/(match) pass out on em2:
192.168.100.254.53499 192.168.100.249.32669: [|tcp] (DF)
Mar 10 13:38:29.380587 rule 0/(match) block in on em2:
192.168.100.249.32669 192.168.100.254.53499: [|tcp] (DF)
Mar 10 13:38:41.379293 rule 29.10334.8834.0/(match) pass in on em1:
87.100.21.71.63387 192.168.100.249.32669: [|tcp] (DF)
Mar 10 13:38:41.379324 rule 29.10334.8834.1/(match) pass out on em2:
192.168.100.254.53479 192.168.100.249.32669: [|tcp] (DF)
Mar 10 13
Re: nat and ftp-proxy on ethernet bridge
On Friday 13 July 2007 21:36:13 you wrote: On 07/09/2007 07:45:58 AM, Igor Popov wrote: Bridge works, NAT works, but problems with ftp - control connection is established, but data connection is dropped. Of course, without ftp-proxy passive ftp works, but some clients need working active ftp too. I don't know FreeBSD but you might try assigning an IP address to an interface, _and_ bridging. Then you could run ftp-proxy. Yes it possible: if_bridge ported from NetBSD and pf from OpenBSD. Now ftp-proxy works and CPU load is lower and memory consumption too. Thanks for help. -- Nothing so needs reforming as other people's habits. -- Mark Twain, Pudd'nhead Wilson's Calendar
Re: nat and ftp-proxy on ethernet bridge
On 07/09/2007 07:45:58 AM, Igor Popov wrote: Bridge works, NAT works, but problems with ftp - control connection is established, but data connection is dropped. Of course, without ftp-proxy passive ftp works, but some clients need working active ftp too. I don't know FreeBSD but you might try assigning an IP address to an interface, _and_ bridging. Then you could run ftp-proxy. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: nat on ip range and ftp-proxy
On 07/04/2007 03:10:50 PM, Попов Игорь Николаевич wrote:
Hi,
I have router under OpenBSD, it main purpose is NAT.
some rules from /etc/pf.conf
#...
table nat_addr const { 80.0.0.21 80.0.0.22 80.0.0.23 80.0.0.24 }
table lan_addr const { 192.168.0.0/25 192.168.10.0/24 }
# NAT
nat pass on $ext_if inet tagged LAN_INET - nat_addr round-robin
sticky-address
#...
# nat marker
pass in on $int_if inet from lan_addr to !(self) keep state flags
S/SA \
tag LAN_INET queue q_traff
#...
There are 4 ip addresses (aliases) on $ext_if - the first is used for
controlling router, others are used for NAT.
And question is how to make ftp-proxy work in this situation?
Both source addresses for control and data connections must be the
same - many ftp servers deny data connection when control connection
has another ip.
Where are you putting your nat-anchor and rdr-anchor anchors in
the config above? I'm a bit tired but it seems to me that if
they go above your NAT section things should work.
Karl [EMAIL PROTECTED]
Free Software: You don't pay back, you pay forward.
-- Robert A. Heinlein
Re: Active failover with local Squid and ftp-proxy.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 20, 2006, at 5:53 PM, Kevin wrote: A failover will terminate any existing proxied connections, including Squid and ftp-proxy. This is an inherent limitation of a proxy firewall. While active TCP sessions are expected to abort, if you start up a new FTP or Squid session after the failover, does it succeed? Yup, the only sad thing at the moment is the death of proxied connections. I was hoping there was some magic I hadn't quite figured out to get that to work; I didn't really think it was possible. It was pure icing, however; CARP and pfsync working as they do are excellent and fulfill all my spec'd requirements for deployment. - -- Bryan Allen [EMAIL PROTECTED] http://bda.mirrorshades.net/ cyberpunk is dead. long live cyberpunk. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFEmHDp8DRlpnH/NmoRAg5CAJ0YDX6WZ9fNgSI93lfludA/7Sh2IgCfRs7c Lf9cUilqtwGXTZmLoZP/iDs= =5AbP -END PGP SIGNATURE-
Re: Active failover with local Squid and ftp-proxy.
On Jun 20, 2006, at 5:53 PM, Kevin wrote: A failover will terminate any existing proxied connections, including Squid and ftp-proxy. This is an inherent limitation of a proxy firewall. Too bad that pfsync (or something) can't sync anchors. I imagine there'd be some configuration involved, maybe to say which anchors the current box will allow to be synced, but that would take care of ftp-proxy failover. It would also make life easier for anybody using carp that dynamically changes anchors or tables for other reasons, they would not have to roll their own to ensure that the master and the failover's anchors stay in sync. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Active failover with local Squid and ftp-proxy.
On Wed, 21 Jun 2006, Karl O. Pinc wrote: Too bad that pfsync (or something) can't sync anchors. I imagine there'd be some configuration involved, maybe to say which anchors the current box will allow to be synced, but that would take care of ftp-proxy failover. It would also No, that wouldn't be enough. What would have to be synced is the state and buffers of all established TCP connections in the kernel _and_ the internal state of the ftp-proxy. I don't think that's feasible.
Active failover with local Squid and ftp-proxy.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yo.
I have two boxes set up in active failover mode. Everything works
just fine except for locally proxied connections (ftp-proxy and Squid-
transparent).
[EMAIL PROTECTED]:[~]# uname -a
OpenBSD master.example.com 3.9 GENERIC.MP#598 i386
[EMAIL PROTECTED]:[~]# pkg_info | grep squid
squid-2.5.STABLE12p1-transparent WWW and FTP proxy cache and accelerator
carp0 = ext CARP group.
carp1 = int CARP group.
a.b.c.254 = Shared CARP IP addr (the proxy address).
em0 = ext system IP.
em1 = int system IP.
10.1.1.1 (master:bge0) and 10.1.1.2 (backup:fxp0) is the crossover
for pfsync.
[EMAIL PROTECTED]:[~]# cat /etc/hostname.carp0
inet x.x.x.254 255.255.128.0 x.x.127.255 vhid 1 carpdev em0 \
pass laqmer1
[EMAIL PROTECTED]:[~]# cat /etc/hostname.carp1
inet 192.168.1.254 255.255.255.0 192.168.1.255 vhid 2 carpdev em1 \
pass laqmer1
[EMAIL PROTECTED]:[~]# cat /etc/hostname.em0
inet x.x.x.1 255.255.128.0 NONE
[EMAIL PROTECTED]:[~]# cat /etc/hostname.em1
inet 192.168.1.1 255.255.255.0 NONE
[EMAIL PROTECTED]:[~]# cat /etc/hostname.bge0
inet 10.1.1.1 255.255.255.0 NONE
[EMAIL PROTECTED]:[~]# grep -v '^#' /etc/sysctl.conf
net.inet.carp.preempt=1 # 1=Enable CARP preempt and group
failover.
net.inet.ip.forwarding=1# 1=Permit forwarding (routing) of
IPv4 packets
[EMAIL PROTECTED]:[~]# cat /etc/hostname.carp0
inet x.x.x.254 6 255.255.128.0 x.x.127.255 vhid 1 carpdev em0 \
pass laqmer1 advskew 128
[EMAIL PROTECTED]:[~]# cat /etc/hostname.carp1
inet 192.168.1.254 255.255.255.0 192.168.1.255 vhid 2 carpdev em1 \
pass laqmer1 advskew 128
[EMAIL PROTECTED]:[~]# cat /etc/hostname.em0
inet x.x.x.2 255.255.128.0 NONE
[EMAIL PROTECTED]:[~]# cat /etc/hostname.em1
inet 192.168.1.2 255.255.255.0 NONE
[EMAIL PROTECTED]:[~]# cat /etc/hostname.fxp0
inet 10.1.1.2 255.255.255.0 NONE
[EMAIL PROTECTED]:[~]# grep -v ^# /etc/sysctl.conf
net.inet.carp.preempt=1 # 1=Allow CARP preempt and group
failover.
net.inet.ip.forwarding=1# 1=Permit forwarding (routing) of
IPv4 packets
pf rules ($pfsync_if = fxp0 on backup):
#
# macros
ext_if = em0
int_if = em1
pfsync_if = bge0
carp0 = x.x.x.254
tcp_services = { 22 }
trusted_networks = { x.x.0.0/16 y.y.0.0/16 }
icmp_types = echoreq
# options
set block-policy return
set loginterface $ext_if
scrub in no-df
# ftp-proxy redirection.
nat-anchor ftp-proxy/*
rdr-anchor ftp-proxy/*
rdr pass on $int_if proto tcp to port ftp - 127.0.0.1 port 8021
# Squid proxy redirection.
rdr on $int_if inet proto tcp from any to any port www - 127.0.0.1
port 3128
nat on $ext_if from $int_if:network to any - $carp0
# filter rules
block in log all
block out log all
block in quick inet6 all
block out quick inet6 all
pass quick on lo0 all
anchor ftp-proxy/*
antispoof for $ext_if
pass quick on { $pfsync_if } proto pfsync
pass on { $ext_if $int_if } proto carp keep state
# squid
pass in on $int_if inet proto tcp from any to 127.0.0.1 port 3128
keep state
pass out on $ext_if inet proto tcp from any to any port www keep state
#
If I move the nat $int_if - $carp0 rule above the FTP rdrs, ftp-
proxy connections stop being able to connect (even though packets
leaving the wire are src addr'd with the system IP, not the CARP
addr), either via passive or active ftp. (The client can auth, but
listings get blocked.)
[EMAIL PROTECTED]:[~]# tcpdump -nnvvi pflog0 host ftp.cs.mun.ca
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: listening on pflog0, link-type PFLOG
16:03:25.031262 134.153.48.2.44567 x.x.x.1.113: [|tcp] (ttl 54, id
4404, len 60, bad cksum dab1! differs by 4000)
16:03:26.882443 192.168.1.100.58440 134.153.48.2.44568: [|tcp] (ttl
64, id 12019, len 60, bad cksum 9321! differs by 4000)
When I nat $int_if out $carp0 (and move it below the ftp rdrs),
failover works great for anything that isn't getting proxied locally
on the system (transparent Squid and ftp-proxy). SSH and scp lag for
a second or two and then come back and it's super awesome. ftp-proxy
connections stall out, and the Squid connections die.
I'm presuming this is because those connections are being routed
$ext_if as opposed to carp0, with the system IP as opposed to the
shared CARP IP.
After searching the pf@ and misc@ archives and googling around, the
only option I can seem to find is setting up CARP aliases for all
three interfaces so when failover happens, the backup will answer for
all IPs? (Some minor config changes to the above would be needed so
the backup could still be reached while the master controlled its
addr, or just fiddle with preempt, presumably.)
Is setting up a CARP group with the system IPs aliased a proper
solution or am I missing some obvious pf magic that will route
connections from Squid and ftp-proxy through the CARP IP?
- --
Bryan Allen
[EMAIL PROTECTED]
http://bda.mirrorshades.net/
cyberpunk is dead. long live cyberpunk
Re: Active failover with local Squid and ftp-proxy.
A failover will terminate any existing proxied connections, including Squid and ftp-proxy. This is an inherent limitation of a proxy firewall. While active TCP sessions are expected to abort, if you start up a new FTP or Squid session after the failover, does it succeed? Kevin
Re: pf+ftp-proxy / pf company example questions
On Sat, 8 Apr 2006, Michal Soltys wrote: I have two (unreleated) questions - the first one regarding new ftp-proxy (the one using anchors) and the other regarding company example in official obsd faq (http://www.openbsd.org/faq/pf/queueing.html#example2) 1)... This is how I understand pf + ftp-proxy functionality: First, two simple rules (one to pass traffic going from ftp-proxy, the other to redirect the internal traffic to proxy) must be added - it's all clear and they are provided as example at the bottom of the man page: rdr pass on $int_if proto tcp from $lan to any port 21 - \ 127.0.0.1 port 8021 pass out proto tcp from $proxy to any port 21 keep state Now, in case of passive connections - ftp-proxy negotiates port to which the client should connect, and installs 2 rules: - a snat rule, that rewrites internal address to proxy's one: nat from $client to $server port $port - $proxy - and a filter rule to actually allow this connection leave the firewall: pass out quick inet proto tcp \ from $proxy to $server port $port flags S/SAFR keep state And as far as I understand, that covers everything that should be done - 2 anchored rules (nat, filter) cover ftp data connection. Earlier explicitely added rdr and filter rules cover initial control connection. So why is the following rule anchored as well : pass in quick inet proto tcp \ from $client to $server port $port flags S/SAFR keep state I can't really find the situation during which it would be needed. Especially that anchored nat rule (as nat/rdr are always executed before filtering, as per faq and man pages) seems to make it never actually happen. What do I miss ? The control (port 21) connection is proxied. It is rdr'ed to ftp-proxy which makes a real TCP connection to the server itself. The data connections are not proxied. The client makes the TCP connection to the server, and it is _not_ rdr'ed to the ftp-proxy. It is subjected to nat+rdr though, so that traffic from the client to the FTP server always originates from the proxy address. In short, it's ftp-proxy's job to make sure that: - the client always thinks it's talking to the server - the server always thinks it's talking to the proxy This is why you always need the nat and rdr anchors, even if you otherwise don't use NAT. To answer your question: data connections go _through_ the firewall, so both an 'in' and 'out' pass rule are needed. On a closing note: the example rules in the manpage are a bit simplified. The proxy rewrites source and destination ports for security and to minimize collisions. (Example of a collission: Imagine two freshly booted Windows machines connecting to the same server: they would both pick port 1024 for an active transfer. If the proxy would rewrite the source address, but not the source port, and the server connects back to port 1024, the proxy cannot tell for who it is.) -- Cam
Re: pf+ftp-proxy / pf company example questions
[EMAIL PROTECTED] (Camiel Dobbelaar) wrote in To answer your question: data connections go _through_ the firewall, so both an 'in' and 'out' pass rule are needed. I think I got confused in the same way like Gabriel recently in the other thread (clarification of the NAT behaviour) - I assumed that even in a multihomed host, the filtering rules apply only once, and all translating rules happen before (therefore, if such situation was true, the anchored pass in would never happen). Now I guess it's clear - anchored pass in on $int happens before anchored nat rule - am I thinking right ? Although shouldn't nat precisely specify the interface then ? (or is it that nat rules apply *only to* outbound traffic and rdr *only to* inbound traffic ?) This leads to another question - if we have effectively two rules - one pass in, one pass out, both using keep-state, and both apply to the same packets - first coming into on some interface and then leaving on some other one, does it mean that two states will be created ? Btw, any hints on my other question (company example re: bandwidth management) ? -- [EMAIL PROTECTED] - remove X to reach me
pf+ftp-proxy / pf company example questions
Hello I have two (unreleated) questions - the first one regarding new ftp-proxy (the one using anchors) and the other regarding company example in official obsd faq (http://www.openbsd.org/faq/pf/queueing.html#example2) 1)... This is how I understand pf + ftp-proxy functionality: First, two simple rules (one to pass traffic going from ftp-proxy, the other to redirect the internal traffic to proxy) must be added - it's all clear and they are provided as example at the bottom of the man page: rdr pass on $int_if proto tcp from $lan to any port 21 - \ 127.0.0.1 port 8021 pass out proto tcp from $proxy to any port 21 keep state Now, in case of passive connections - ftp-proxy negotiates port to which the client should connect, and installs 2 rules: - a snat rule, that rewrites internal address to proxy's one: nat from $client to $server port $port - $proxy - and a filter rule to actually allow this connection leave the firewall: pass out quick inet proto tcp \ from $proxy to $server port $port flags S/SAFR keep state And as far as I understand, that covers everything that should be done - 2 anchored rules (nat, filter) cover ftp data connection. Earlier explicitely added rdr and filter rules cover initial control connection. So why is the following rule anchored as well : pass in quick inet proto tcp \ from $client to $server port $port flags S/SAFR keep state I can't really find the situation during which it would be needed. Especially that anchored nat rule (as nat/rdr are always executed before filtering, as per faq and man pages) seems to make it never actually happen. What do I miss ? 2)... My second question concerns company example in pf queuing section. It seems that this example completely ignores nat/rdr issues. Of course it's stated at the beginning, that they were left intentionally, but then let's consider two rules from the example: # filter rules for fxp0 outbound pass out on fxp0 from $int_nets to any keep state pass out on fxp0 from $boss to any keep state queue boss_ext AFAIR, those two situations would have to be nated first - to succesfully go public from fxp0, but then - according to faq - all translations happen before the filter rules, so there would be no $int_nets or $boss anymore - just firewall's external address. So what did I miss again here ?
Re: pf FTP ftp-proxy rules question for a firewall
I was able to find the solution to my problem. I'm now using pftpx instead of ftp-proxy. I think it will replace ftp-proxy in openbsd 3.9 and it works really fine on 3.8. Like ftp-proxy it's a proxy but can dynamitically alter PF rules on needs so no unwanted open ports are needed. http://www.sentia.org/downloads/pftpx-0.8.tar.gz
Best way to write FTP rule without ftp-proxy?
Hi all I'm newbie with pf, just try for a few weeks. Now I try to write ftp rule, but after reading from many book. I found that they guide to use ftp-proxy. But my production site don't allow to use that. how could I write rule for ftp? I have about 200 clients. one firewall with nat rules. All user need to use ftp to internet. Thanks so much. :D
Re: Best way to write FTP rule without ftp-proxy?
On Fri, Mar 31, 2006 at 12:41:11AM +0700, IMS wrote: Now I try to write ftp rule, but after reading from many book. I found that they guide to use ftp-proxy. But my production site don't allow to use that. how could I write rule for ftp? FTP uses more than a single TCP connection. When an FTP client on your LAN connects to an FTP server on the Internet, it opens the so-called control connection, where it authenticates and issues commands, like LS to list a directory or GET to fetch a file. The result of these commands (the directory listing itself, or the contents of a file to fetch) is not, however, sent back through the same connection. Instead, a second TCP connection is established just for the purpose of transfering that data, the so-called data connection. There are two modes of FTP, passive and active. In passive mode, the data connection is opened from client to server. The server picks a random high port to listen on, tells the client _through the control connection_ what address and port to connect to. This will work without a proxy, if you allow outgoing NATed connections to random high ports. In active mode, data connections are opened from server to client. The client picks a random high port and tells the server what address and port to connect to. This is what breaks due to NAT. The client tells the server to connect to its own unroutable address. First, the server can't connect to it at all, and even if it could reach the NATing firewall, the firewall wouldn't automatically port forward the connection. What you need, for active mode, is some piece that intercepts the advertisement of the address/port the server should connect to, replaces it with the server's external address, and sets up the port forwarding on the firewall. With pf, that's done with ftp-proxy. Other firewalls do this internally. pf doesn't, and won't. We believe this should be done in userland. And our conviction is at least as strong as your site's policy. Live with passive mode only, use the proxy, or switch firewalls :) Daniel
Re: Best way to write FTP rule without ftp-proxy?
The ftp-proxy mechanism has changed, please read the PF-faq in http://www.openbsd.org/faq for update it. Regards. --- IMS [EMAIL PROTECTED] wrote: Hi all I'm newbie with pf, just try for a few weeks. Now I try to write ftp rule, but after reading from many book. I found that they guide to use ftp-proxy. But my production site don't allow to use that. how could I write rule for ftp? I have about 200 clients. one firewall with nat rules. All user need to use ftp to internet. Thanks so much. :D Fco.Valladolid Hdez. [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Best way to write FTP rule without ftp-proxy?
On Thu, March 30, 2006 12:41 pm, IMS said: Hi all I'm newbie with pf, just try for a few weeks. Now I try to write ftp rule, but after reading from many book. I found that they guide to use ftp-proxy. But my production site don't allow to use that. how could I write rule for ftp? I have about 200 clients. one firewall with nat rules. All user need to use ftp to internet. What won't they let you do? If you are installing a new firewall, ftp-proxy is part of the base system. With NAT, there really is no other general way to get FTP working. Passive FTP can be made to pass through the firewall, assuming the clients can open connections on random high ports, but active FTP just won't work. FTP is a pain. It *needs* a proxy to go through a firewall. (Though some systems build the proxy into the filter.) Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: Best way to write FTP rule without ftp-proxy?
On 03/30/2006 03:06:42 PM, Daniel T. Staal wrote: FTP is a pain. It *needs* a proxy to go through a firewall. .. because it imbeds network information in the application's data stream. The easiest way to get FTP working is to use OpenBSD 3.9 (i.e. the current release) or install the 3.9 ftp proxy onto a earlier version (the new ftp-proxy is in ports in the older OpenBSDs, under a different name.) If you don't use the new ftp proxy you'll probably have to understand FTP. Read rfc959 selectively (www.rfc-editor.org), like sections 1 through 3. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: ftp-proxy, and one nic: oh my...
rdr pass on $extif proto tcp from any to any port 21 - 127.0.0.1 port 8021 This makes inbound packets destined to port 21 on your box go to the proxy. But they'll be blocked because you don't have a pass rule anywhere to allow them. block drop in log quick on $extif from $privnets to any This blocks all DHCP traffic, given that your ISP is using RFC 1918 addresses internally (10.x). Stop trying to drop this traffic, at least for 10/8. pass out quick log on $extif proto udp from ($extif) port 68 to $dhcp port 67 keep state pass in quick log on $extif proto udp from ($dhcp) port 67 to ($extif) port 68 keep state That's not the best way to deal with DHCP. Remember when you start up, you don't have an IP, so your packets will be coming from 0.0.0.0! And they will be sent to the local-broadcast address 255.255.255.255. When your ISP's DHCP server reponds, that will be the first real address in the exchange, and that's a 10/8. All in all, you need to just bite the bullet and put a: pass out quick on $ext_if all keep state somewhere in there, it will make life much easier. The rdr rule won't do what you want. You're trying to munge the destination IP on an outbound packet. rdr munges the destination IP on inbound packets. nat munges the source IP on outbound packets. Nothing pf can do does what you want. BTW, quick rules are fine, continue to use them. Only use non-quicks if you can't avoid it. PS: Your bridging firewall will make remotely adminstering your firewall difficult, if not impossible IIUC. For example, how would you download a program you need (answer: you can't)? How would you update the firewall rules (answer: on the console)? How would you remote-log, or keep your clock accurate, or do anything with the box? How would you read the email that gets sent to root (answer: console again). Sounds like a major PITA if you ask me. -- Security Guru for Hire http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
Re: ftp-proxy, and one nic: oh my...
thanks for writing back, i know that you're busy so... ifconfig -a vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::250:8dff:fe5a:18a0%vr0 prefixlen 64 scopeid 0x1 inet 69.205.XX.122 netmask 0xf000 broadcast 255.255.255.255 ether 00:50:8d:5a:18:a0 media: Ethernet autoselect (10baseT/UTP) status: active plip0: flags=108810POINTOPOINT,SIMPLEX,MULTICAST mtu 1500 pflog0: flags=141UP,RUNNING,PROMISC mtu 33208 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 pfsync0: flags=0 mtu 2020 i can surf and telnet; i took out the quick keyword but i'm still only logging rule 4. i'm still new at tcp/ip and services so how do i make an exception to my isp's dhcp server? you can see from above my nic's address is not a 10.mumble. i read your paper and the manpage for ftp-proxy so maybe i should roll back to a less strict ruleset. btw i really like pf, for a newbie it has an easy curve for learning. once i get this running i'll install a second nic and try to do the invisible bridge thing. i want to go into security so i need to get this right. thanks again. nikita -- frederick thomas [EMAIL PROTECTED] -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again
ftp-proxy, and one nic: oh my...
i'm running freebsd 5.4 with only one nic(single user until i get a
router) so i don't think i can do nat. i've have had no luck in getting
damn thing to ftp. i added to the /etc/inetd.conf file the line
ftp-proxy:
stream tcp nowait root/usr/libexec/ftp-proxy ftp-proxy
and my /etc/pf.conf so far:
extif = vr0
tcpservices = { 20, 21, 25, 53, 67, 68, 80, 110, 123, 546, 631 }
udpservices = { 20, 21, 25, 53, 67, 68, 80, 110, 123, 546, 631 }
dhcp = 10.118.160.1
icmptypes = echoreq
privnets = { 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
scrub in all
rdr pass on $extif proto tcp from any to any port 21 - 127.0.0.1 port
8021
block all
block drop in log quick on $extif from $privnets to any
block drop out log quick on $extif from any to $privnets
block drop in log quick on $extif proto icmp all
pass quick on lo0
pass out quick log on $extif proto udp from ($extif) port 68 to $dhcp
port 67 keep state
pass in quick log on $extif proto udp from ($dhcp) port 67 to ($extif)
port 68 keep state
pass out quick on $extif proto tcp from ($extif) to any port
$tcpservices keep state
pass out quick on $extif proto udp from ($extif) to any port
$udpservices keep state
pass out inet proto icmp all icmp-type $icmptypes keep state
pass out quick on $extif inet proto udp from any to any port 22:23 keep
state
pass in quick on $extif inet proto udp from any to any port 22:23 keep
state
pass out quick on $extif inet proto tcp from any to any port 22:23 keep
state
pass in quick on $extif inet proto tcp from any to ($extif) user proxy
keep state
i really hate asking for help but i've exhausted every site and faq on
web and it all
points to nat so do i have to install a dummy card to get this to work
or can i just
adjust the rule set? lastly as you can see from my conf i'm trying to
log all rfc 1918
addresses and my isp's dhcp server in bound but so far i only get rule
four(4) to log
the expansion of the privnets macro any help would be appreciated
greatly. peace
*is this the door where i came in?
--
frederick thomas
[EMAIL PROTECTED]
--
http://www.fastmail.fm - Faster than the air-speed velocity of an
unladen european swallow
Re: ftp-proxy, and one nic: oh my...
frederick thomas [EMAIL PROTECTED] writes: i've have had no luck in getting damn thing to ftp. not trying to be rude or anything, are you getting it to do anything at all? That is with dhcp = 10.118.160.1 does this mean your IP address is in the 10.mumble range too? if so, block drop in log quick on $extif from $privnets to any block drop out log quick on $extif from any to $privnets means you are dropping your own traffic. also, if you make every rule a quick rule, you are not making debugging any easier. you could try my tutorial at http://www.bgnett.no/~peter/pf/ for a gentle walkthrough. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ First, we kill all the spammers The Usenet Bard, Twice-forwarded tales 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.
Re: ftp-proxy vs. ftpsesame
On Mon, Jul 18, 2005 at 12:10:41PM -0400, Daniel T. Staal wrote: I'm not to interested in exact rules at this point; I can figure those out. I'm just looking for what people think is the best way to use the tools to do the job: least ports opened, least hassle, least resources, etc. From a scan of the man pages, ftpsesame looks to be able to handle just about everything except active client connections, and ftp-proxy seems to be able to handle everything major, but requires a lot of ports open. as far as Just Work, i'ven't had any issues with ftp-proxy over the past years. i use just two rules in pf.conf (one for the rdr, the other because i don't rdr pass). the 'pass on...' rule is specific to 'inet proto tcp blahblah user proxy'. i use '-M' and '-m' to limit the range of ports that the proxy will attempt to use, but in actuality that doesn't provide me much value, so i'm going to get rid of that after i send this out (was one of those things i twiddled early on because i thought i had some reason to do it)... i also use '-n'. active and passive both work. took me a little bit to digest the practical meaning of '-n', and i didn't know of ftpseasame prior to getting ftp-proxy to work. ftpseasame has come up several times on the lists, but in my topology, if don't have any compelling reason to convert from a util in base to a util in ports, it's easier to just leave good-enough alone. one less thing to worry about. jared - [ openbsd 3.7 GENERIC ( jun 25 ) // i386 ]
ftp-proxy vs. ftpsesame
I'm in the middle of updating my firewall and was wondering if I could get opinions on the relative merits of ftp-proxy and ftpsesame for passing connections through pf. I've read through the man pages for both, and they obviously both have advantages, but I'm trying to figure out how they compare for different jobs. My setup is fairly simple: I have a NATed home network with several users and a web host that I serve a couple of websites off of. Ideally, of course, I'd like everything to Just Work: active and passive, both from all the clients and to the server. I'm just wondering what parts should be delegated to which handler, or if some direction/connection should be left off. I'm not to interested in exact rules at this point; I can figure those out. I'm just looking for what people think is the best way to use the tools to do the job: least ports opened, least hassle, least resources, etc. From a scan of the man pages, ftpsesame looks to be able to handle just about everything except active client connections, and ftp-proxy seems to be able to handle everything major, but requires a lot of ports open. What else should I consider? Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
Re: ftp-proxy vs. ftpsesame
On Mon, 18 Jul 2005, Daniel T. Staal wrote: My setup is fairly simple: I have a NATed home network with several users and a web host that I serve a couple of websites off of. Ideally, of course, I'd like everything to Just Work: active and passive, both from all the clients and to the server. I'm just wondering what parts should be delegated to which handler, or if some direction/connection should be left off. From a scan of the man pages, ftpsesame looks to be able to handle just about everything except active client connections, and ftp-proxy seems to be able to handle everything major, but requires a lot of ports open. What else should I consider? Warning: I wrote two of the three available proxies... There are 3 options (in order of age): 1) ftp-proxy 2) ftpsesame 3) pftpx (but now available in OpenBSD _cvs_ in usr.sbin/ftp-proxy) ftp-proxy is a real proxy. With the help of pf rdr it intercepts the control connection and opens real (tcp) data connections on the users behalf. Except if you use the -n mode, where it assumes that passive connections are allowed globally by the pf ruleset. ftpsesame use bpf to sniff the control connections. To allow the data connections it commits rules into a special anchor. Advantages: totally passive, works on a bridge as well. Disadvantages: can not handle NAT situations well, since it cannot rewrite commands in the control connection. It can also be racy, eg. that rules are not commited in time, but that does not seem be a problem in practice. pftpx uses a combination. It intercepts the control connection with rdr like ftp-proxy does, but commits rules into an anchor to allow data connections like ftpsesame does. It can handle all types of NAT, IPv6 and all types of FTP. I guess the last one is best for your situation. While it is available at: http://www.sentia.org/downloads/pftpx-0.8.tar.gz the last and best version is in OpenBSD cvs in src/usr.sbin/ftp-proxy It's not connected to the build yet though, so it's not available in snapshots. I can also not tell if it will make OpenBSD 3.8 or not. Hope that sheds some light in the already confusing world of FTP. :-) -- Cam
Re: ftp-proxy vs. ftpsesame
--As of Monday, July 18, 2005 7:28 PM +0200, Camiel Dobbelaar is alleged to have said: On Mon, 18 Jul 2005, Daniel T. Staal wrote: My setup is fairly simple: I have a NATed home network with several users and a web host that I serve a couple of websites off of. Ideally, of course, I'd like everything to Just Work: active and passive, both from all the clients and to the server. I'm just wondering what parts should be delegated to which handler, or if some direction/connection should be left off. From a scan of the man pages, ftpsesame looks to be able to handle just about everything except active client connections, and ftp-proxy seems to be able to handle everything major, but requires a lot of ports open. What else should I consider? Warning: I wrote two of the three available proxies... There are 3 options (in order of age): 1) ftp-proxy 2) ftpsesame 3) pftpx (but now available in OpenBSD _cvs_ in usr.sbin/ftp-proxy) I wondered what had happened to pftpx. The last I'd seen of it was the initial announcement on this list. I followed that address to your site, and found out about ftpsesame, but I couldn't find pftpx. ftp-proxy is a real proxy. With the help of pf rdr it intercepts the control connection and opens real (tcp) data connections on the users behalf. Except if you use the -n mode, where it assumes that passive connections are allowed globally by the pf ruleset. ftpsesame use bpf to sniff the control connections. To allow the data connections it commits rules into a special anchor. Advantages: totally passive, works on a bridge as well. Disadvantages: can not handle NAT situations well, since it cannot rewrite commands in the control connection. It can also be racy, eg. that rules are not commited in time, but that does not seem be a problem in practice. pftpx uses a combination. It intercepts the control connection with rdr like ftp-proxy does, but commits rules into an anchor to allow data connections like ftpsesame does. It can handle all types of NAT, IPv6 and all types of FTP. I guess the last one is best for your situation. Thank you muchly. That is just what I was looking for. While it is available at: http://www.sentia.org/downloads/pftpx-0.8.tar.gz the last and best version is in OpenBSD cvs in src/usr.sbin/ftp-proxy It's not connected to the build yet though, so it's not available in snapshots. I can also not tell if it will make OpenBSD 3.8 or not. Is it in -current, so that if I upgraded from source I would get it? (I assume so, or at least that I could pull it down an put it into such a build.) Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
ftp-proxy rules for an external ftp server
Man ftp-proxy (8) (obsd 3.7) says this: ftp-proxy accepts the redirected control connections and forwards them to the server. The proxy replaces the address and port number that the client sends through the control connection to the server with its own address and proxy port, where it listens for the data connection. When the server opens the data connection back to this port, the proxy for- wards it to the client. The pf.conf(5) rules need to let pass connec- tions to these proxy ports (see options -u, -m, and -M above) in on the external interface. The following example allows only ports 49152 to 65535 to pass in statefully: block in on $ext_if proto tcp all pass in on $ext_if inet proto tcp from any to $ext_if \ port 49151 keep state Alternatively, rules can make use of the fact that by default, ftp-proxy runs as user proxy to allow the backchannel connections, as in the fol- lowing example: block in on $ext_if proto tcp all pass in on $ext_if inet proto tcp from any to $ext_if \ user proxy keep state These examples do not cover the connections from the proxy to the foreign FTP server. If one does not pass outgoing connections by default addi- tional rules are needed. I have ports 5500:5700 opened for the data channel, what additional rules are needed? I've tried the rules in http://cvs.openbsd.org/faq/pf/ftp.html#natserver but they do not work. I cannot connect to my ftp server from outside the network. Thanks, -- -Christopher
ftp-proxy(8) issues ...
Hi all,
I have set up ftp-proxy(8) as per recommendations from the PF FAQ. I
have used the following to set it up:
rdr on $INT_IF proto tcp from any to any port 21 - 127.0.0.1 port 8021
pass in log quick on $EXT_IF proto tcp from port 20 to ($EXT_IF) user
proxy flags S/SA keep state
inetd(8) is set up correctly.
I have gone down the road of explicitly allowing connections _both_ in
and out. This is causing the folllowing problem:
# ftp hostname.some.domain
Connected to hostname.some.domain
421 Service not available, remote server has closed connection.
ftp
From /var/log/messages:
May 25 17:01:33 gateway ftp-proxy[5528]: accepted connection from
10.0.0.30:25499 to 192.231.203.130:21
May 25 17:02:48 gateway ftp-proxy[5528]: cannot connect to
192.231.203.130:21 (Operation timed out)
However, I have explicitly allowed:
pass out on $EXT_IF inet proto tcp from ($EXT_IF) to any port {20,21}
I'm not sure what is happening here. It looks like ftp-proxy(8) is
being blocked when trying to connect _out_ to port 21.
Can anyone suggest anything here ?
Cheers
- Alex
Re: ftp-proxy(8) issues ...
alex wilkinson wrote:
# ftp hostname.some.domain
Connected to hostname.some.domain
421 Service not available, remote server has closed connection.
ftp
Do you get the same message from all FTP servers?
Service not available might mean there's trouble with that specific
server.
Other than that, I can't immediately see anything wrong with your setup.
(It has been a while since I set up ftp-proxy and PF. But at least you
can take consolation in knowing it's possible. I'm failing to set up
p3scan with PF, and I've no idea if anyone has ever succeeded.)
My setup does seem slightly different to yours, however. Such as, in my
external interface rules, I have this:
# Allow ftp-proxy to contact FTP servers
pass out on $ext_intfc proto tcp from any port 49152:65535 to any
port { 20, 21, 49152:65535 } user ftp-proxy modulate state
queue(default_out, ack_out)
For my redirect rule, I have the very similar:
# Redirect FTP traffic from local network to ftp-proxy
# (Note: ftp-proxy needs to use the INTERNAL interface address so
that the local network is
# permitted to talk to it - the local network cannot talk to the
external interface address.
# Make sure this is specified as an argument to ftp-proxy in
inetd.conf)
#
rdr on $int_intfc proto tcp from $int_intfc:network to any port 21
tag $ftp_traffic - $int_intfc port 8021
If you're using NAT, you also need to use the -n switch in your
inetd.conf line for ftp-proxy.
--
Bob
ftp-proxy queue
hi all, i have openbsd 3.6 as nat gateway. i create several queue to handle ftp traffic (download). each queue is assigned to specific ftp server. the goal is something like: traffic from ftpserver_1 goes to queue_1 traffic from ftpserver_2 goes to queue_2 below is my pf.conf: -- ext_if = fxp0 int_if = xl0 alt on $int_if cbq queue (q_int_def, q_int_ftp1, q_int_ftp2 } queue q_int_def bandwidth 512Kb cbq (default,ecn) queue q_int_ftp1 bandwidth 128Kb cbq(ecn) queue q_int_ftp2 bandwidth 64Kb cbq(ecn) nat on $ext_if from $int_if:network to any - $ext_if # ftp-proxy rdr on $int_if inet proto tcp from $int_if:network to any \ port 21 - 127.0.0.1 port 8021 pass in on $ext_if inet proto tcp from $ftpserver_1 port 20 to ($ext_if) \ user proxy flags S/SA keep state tag FTP_1 pass in on $ext_if inet proto tcp from $ftpserver_2 port 20 to ($ext_if) \ user proxy flags S/SA keep state tag FTP_2 pass out on $int_if user proxy keep state queue_1 tagged FTP_1 pass out on $int_if user proxy keep state queue_2 tagged FTP_2 it doesn't work. all traffic goes to default queue. is it possible using ftp-proxy and altq to assign queue based on ftp server ip_address? any help would be appreciated. thanks adisola -- +++ NEU: GMX DSL_Flatrate! Schon ab 14,99 EUR/Monat! +++ GMX Garantie: Surfen ohne Tempo-Limit! http://www.gmx.net/de/go/dsl
Re: reverse ftp proxy using binat fails
[EMAIL PROTECTED] wrote: I have now placed my proftp server (normal ftp port) on my private DMZ, I do a binat on pf..conf and edited my inetd.conf file again to add this line. http://www.openbsd.org/faq/pf/ftp.html#natserver Not exactly what you're doing, but very close. You can skip the rdr rules (since you're doing binat); just make sure you're passing traffic appropriately in your filter rules. .joel
Re: ftp-proxy and pf
On Mon, Feb 07, 2005 at 10:08:24AM -0500, Peter Fraser wrote: After reading the ftp rfc's (959 and 1123) I don't understand how ftp-proxy can work without support of pf, and any ftp client that works in active mode with the current ftp-proxy is in violation of these rfc's. In particular section 3.2 of rfc949 and 4.1.2.12 of rfc1123 together say that the data from an active ftp connection must come from port ftp-data and the IP address of the control channel( i.e. the IP address the ftp open command) The requirement that the data connection must come from port ftp-data is commonly relaxed. In order for the ftp server to use port 20 (which is privileged, 1024), the server would have to run as root permanently. Most server operators prefer their daemon to drop privileges and violate the RFC (if it is indeed a violation, I haven't checked), and most clients have to relax to interoperate. The second requirement, that the data connection source must match the control connection peer, is also often violated. For instance, the OpenBSD ftp(8) client does not enforce it. The reverse also happens regularly, a ftp server getting data connection from a client having a different source address than the one used by the control connection (see -P in ftpd(8)). It's not just NAT that causes these cases. If you're doing a server-to-server transfer (aka FXP), you connect a client to two different servers concurrently. You tell the first one that you want to upload a file and that it should tell you what address:port to connect to for that data. Once you have that information, you tell the second server you want to download a file, and that it should connect to the address:port obtained from the first server. The servers will then transfer the file among themselves, without going through your client at all. This is particularly useful if the servers have higher bandwith between themselves than your client has to either of them. In short, most sufficiently-advanced ftp clients (and servers) have options to enable or disable these restrictions. It might be true that a strictly RFC compliant ftp client will not work with ftp-proxy. But that client will then also not work with a significant number of real ftp servers out there, either. Daniel
Re: [Fwd: Re: ftp-proxy and pf]
On Tue, Feb 08, 2005 at 10:29:04AM +, Marcos Biscaysaqu - ThePacific.net wrote: I tried all the ftp-proxy versions and all the possible options in inetd.conf. ftp-proxy and PF Doesn't not work with Restrict FTP clients in Active mode. please if someone has a options to make restricted FTP clients behind NAT with pf please let me know. You can try Camiel Dobbelaar's pftpx as an alternative to ftp-proxy, see http://www.monkey.org/openbsd/archive/misc/0411/msg03474.html It does not intercept and proxy (rewrite) the data connection, but instead inserts a temporary rdr rule into an anchor, so data connections will retain their original (external) source addresses. Daniel
Re: ftp-proxy and pf
The requirement that the data connection must come from port ftp-data is commonly relaxed. In order for the ftp server to use port 20 (which is privileged, 1024), the server would have to run as root permanently. Most server operators prefer their daemon to drop privileges and violate the RFC (if it is indeed a violation, I haven't checked), and most clients have to relax to interoperate. The second requirement, that the data connection source must match the control connection peer, is also often violated. For instance, the OpenBSD ftp(8) client does not enforce it. The reverse also happens regularly, a ftp server getting data connection from a client having a different source address than the one used by the control connection (see -P in ftpd(8)). In short, most sufficiently-advanced ftp clients (and servers) have options to enable or disable these restrictions. It might be true that a strictly RFC compliant ftp client will not work with ftp-proxy. But that client will then also not work with a significant number of real ftp servers out there, either. Daniel This might all be true, but the trouble is Microsoft (with Windows XP Service Pack 2, I haven't tried any others) is inforcing these rules.
Re: ftp-proxy and pf
On Tue, 8 Feb 2005 23:22:15 +0100, Daniel Hartmeier [EMAIL PROTECTED] wrote: On Mon, Feb 07, 2005 at 10:08:24AM -0500, Peter Fraser wrote: After reading the ftp rfc's (959 and 1123) I don't understand how ftp-proxy can work without support of pf, and any ftp client that works in active mode with the current ftp-proxy is in violation of these rfc's. In particular section 3.2 of rfc949 and 4.1.2.12 of rfc1123 together say that the data from an active ftp connection must come from port ftp-data and the IP address of the control channel( i.e. the IP address the ftp open command) The requirement that the data connection must come from port ftp-data is commonly relaxed. In order for the ftp server to use port 20 (which is privileged, 1024), the server would have to run as root permanently. Systrace can enable specific operations as root without running the daemon under the root UID. The ftp-proxy process currently uses root to access /dev/pf for the DIOCNATLOOK ioctl; that also could be handled by systrace. Would it be reasonable to modify ftp-proxy to attempt to bind the source port to ftp-data (port 20) even when not running as root, then fallback to a socket in the designated range only if binding ftp-data fails? Looking at ftp-proxy.c, the change to handle this would be minor, I can submit a diff if there is interest. Kevin Kadow
pf and ftp-proxy
Being I cannot get ftp-proxy to work for active connections. I thought (hopefully for a short time to write rules to allow just those clients to use ftp to just those servers where I had problems. So I wrote up rdr pass proto tcp from Clients to $Server1 port ftp - $Server1 port ftp rdr pass proto tcp from Clients to $Server2 port ftp - $Server2 port ftp rdr pass proto tcp from Clients to $Server3 port ftp - $Server3 port ftp rdr pass on $Inside_ifs proto tcp from any to any port ftp - 127.0.0.1 port 8021 and further down pass quick proto tcp from Clients to Servers keep state pass quick proto tcp from Servers port ftp-data to Clients port 999 keep state I expected this to work but it didn't. I expected the pass on the rdr, to skip the following rdr. PS: I did find a method that works and it is probably better rdr pass proto tcp from Clients to !Servers port ftp - 127.0.0.1 port 8021 rdr pass proto tcp from !Clients to anyport ftp - 127.0.0.1 port 8021
[Fwd: Re: ftp-proxy and pf]
Hi there. I tried all the ftp-proxy versions and all the possible options in inetd.conf. ftp-proxy and PF Doesn't not work with Restrict FTP clients in Active mode. please if someone has a options to make restricted FTP clients behind NAT with pf please let me know. Thanks Marcos Biscaysaqu ThePacific.net Peter Fraser wrote: After reading the ftp rfc's (959 and 1123) I don't understand how ftp-proxy can work without support of pf, and any ftp client that works in active mode with the current ftp-proxy is in violation of these rfc's. In particular section 3.2 of rfc949 and 4.1.2.12 of rfc1123 together say that the data from an active ftp connection must come from port ftp-data and the IP address of the control channel( i.e. the IP address the ftp open command) pf needs to be involved because ftp-proxy could rewrite the IP address and port of the data connection before sending it on the ftp client, but with out pf redirecting the return packets, ftp proxy would not see answering packets from the client on the data connection.
Re: ftp-proxy and pf
Peter Fraser wrote: I realize that this is not a pf problem, but I also believe that readership here has the expertise to solve this problem. I am trying to use ftp-proxy with pf, it works for passive mode, but fails for active mode. What follows (slightly edited) is a conversation from a Windows XP machine (source.thinkage.ca) using the cygwin ftp which logs on anonymous by its self. (I get the same using Microsoft's ftp) Try from a machine not running Windows XP or with the built-in firewall disabled. We had similar results with Windows XP machines with the firewall from SP2. If that doesn't help, try to add debug-info from ftp-proxy. Cheers, Martin
ftp-proxy, active ftp and authpf
Does anyone have a small snippet of /etc/authpf/authpf.rules that shows how
to let client machines behind a firewall do both authenticated network
access to an ftp server (using ftp-proxy) and use active FTP?
This doesn't quite seem to work properly under authpf.rules
wlan_if = fxp0
rdr on $wlan_if proto tcp from $user_ip to any port 21 - 127.0.0.1 port 8021
Here's my pf.conf and authpf.rules -- any comments on this are appreciated.
--
#; /etc/pf.conf
#; variables
###
# interfaces
loopbk = lo0
ext_if = de0
wlan_if = fxp0
wire_if = tx0
ipsec_if= enc0
broadcast = 255.255.255.255
# service definitions
tcp_wlanif = { ftp, ssh, http, https }
tcp_wireif = { ftp, ssh, http, https }
# tables
table bogon persist file /etc/bogon.txt
# administrative aliases
aspf = antispoof log
bi= block in
bo= block out
bil = block in log
biq = block in quick
bol = block out log
boq = block out quick
bilq = block in log quick
bolq = block out log quick
blk = block
pqk = pass quick
pi= pass in
po= pass out
pil = pass in log
piq = pass in quick
pol = pass out log
poq = pass out quick
pilq = pass in log quick
polq = pass out log quick
ks= keep state
ms= modulate state
ss= synproxy state
#; behavior options
###
set loginterface $ext_if
set timeout { interval 9, frag 27 }
set limit { frags 45000, states 35000 }
set optimization normal
set block-policy return
set state-policy if-bound
set debug urgent
#; network translations and redirection
###
scrub out all no-df random-id max-mss 1440
scrub in all no-df fragment reassemble min-ttl 2
# nat hosts on each internal interface
#nat on $ext_if from $wlan_if:network to any - ($ext_if)
# redirect for ftp-proxy
rdr on $wire_if proto tcp from any to any port 21 - 127.0.0.1 port 8021
#; anchors
###
nat-anchor authpf/*
rdr-anchor authpf/*
binat-anchorauthpf/*
anchor authpf/*
#; rules
###
# default block-all
$blk log \
label $if-block-log
# pass everything on loopback
$pqk on lo0 all \
label $if-pass
# drop bogon tables from /etc/bogon.txt
$bilqon $ext_if from bogon \
to any label $if-bogon
$bil on $wlan_if from { !$wlan_if:network, bogon } \
to any label $if-bogon
$bil on $wire_if from { !$wire_if:network, bogon } \
to any label $if-bogon
# prevent spoofing from this host
$bolqon $ext_if from !$ext_if \
to any label $if-block-out
# block broadcast noise, but dont log
$biq on $ext_if from any to $broadcast \
label $if-broadcast
# prevent spoofing of all interfaces
antispoof log for { $ext_if, $loopbk, $wlan_if, $wire_if } \
label $if-antispoof
# pass out packets on any interface
$poq inet proto tcp all flags S/SA label $if-pass-synack-out $ms
$poq inet proto udp alllabel $if-pass-udp-out$ks
$poq inet proto icmp alllabel $if-pass-icmp-out $ks
$poq alllabel $if-pass-ip-out
# allow bootp, dns lookups and ntp access (including
# sntp) to wlan_if
$pi on $wlan_if inet proto udp from any \
to any port bootps label $if-bootps-in $ks
$pi on $wlan_if inet proto udp from $wlan_if:network \
to $wlan_if port domain label $if-domain-udp-in $ks
$pi on $wlan_if inet proto udp from $wlan_if:network \
to $wlan_if port ntplabel $if-ntp-in$ks
# allow bootp, dns lookups and ntp access (including
# sntp) to wire_if
$pi on $wire_if inet proto udp from any \
to any port bootps label $if-bootps-in $ks
$pi on $wire_if inet proto udp from $wire_if:network \
to $wire_if port domain label $if-domain-udp-in $ks
$pi on $wire_if inet proto udp from $wire_if:network \
to $wire_if port ntplabel $if-ntp-in$ks
# allow users to ssh into this host for authpf
$pilq on { $wlan_if $wire_if } inet proto tcp from any \
to any port ssh label $if-$srcaddr-ssh-authpf $ks
# icmp controls; log anything to our interfaces; pass everything else
$pil on $wlan_if inet proto icmp from any \
to $wlan_if icmp-type echoreq label $if-icmp-echo $ks
$pil on $wire_if inet proto icmp from any \
to $wire_if icmp-type echoreq label $if-icmp-echo $ks
$pil on $ext_if inet proto icmp from any \
to $ext_if icmp-type echoreq label $if-icmp-echo $ks
# ssh access to ext_if
$pi on $ext_if inet proto tcp from nxious \
to $ext_if port ssh label $if-nxious-ssh-in $ms
$pil on $ext_if inet proto tcp from dpu \
to $ext_if port ssh label $if-dpu-ssh-in $ms
$pil on $ext_if inet proto tcp from
Re: new ftp proxy: pftpx
hi, I've put up the latest version at http://www.sentia.org/downloads/pftpx-0.5.tar.gz many thanks, works great. i´m planning on trying pftpx on our main firewall, as we have some mac users with picky ftp clients and also pasv ftp for everyone would be cool. so it would be really nice if you could post possible updates on your website (or maybe on this list?) thanks again! tobias
Re: new ftp proxy: pftpx
hi, Ok, bleeding edge pf people... I wrote a new FTP proxy called pftpx and I'd like to solicit some feedback from the community... it´s great! running it for a few days now and it works just fine. and i was able to tighten my ruleset (i.e. no more outgoing and wide open pasv ftp rules) hope it doesn´t have any severe exploitable bugs, though. ;-) Sorry, no manpage yet, this is bleeding edge after all. would be great to know what all the address options mean, as i wasn´t able to figure out all of them. btw. the queue option is what i was about to ask for before i found it was already there :-) because some queue option like anchor pftpx/* queue ftp won´t be complained about but is simply ignored by 3.6 pfctl´s parser... All feedback welcome many thanks for sharing this! tobias
Re: new ftp proxy: pftpx
On Tue, 14 Dec 2004, Tobias Wigand wrote: hope it doesn´t have any severe exploitable bugs, though. ;-) Peer review would be good... but it already does some mitigation: check the security section below. I've put up the latest version at http://www.sentia.org/downloads/pftpx-0.5.tar.gz it includes a manpage as well, which is pretty short so I'll paste it below. -- Cam PFTPX(8)OpenBSD System Manager's Manual PFTPX(8) NAME pftpx - FTP proxy SYNOPSIS pftpx [-6d] [-b address] [-c port] [-D level] [-f address] [-g port] [-m maxsessions] [-p address] [-q queue] [-t timeout] DESCRIPTION pftpx is a proxy for the Internet File Transfer Protocol. FTP control connections should be redirected into the proxy using the pf(4) rdr com- mand, after which the proxy connects to the server on behalf of the client. The proxy allows data connections to pass, rewriting and redirecting them so that the right addresses are used. All connections from the client to the server have their source address rewritten so they appear to come from the proxy. Consequently, all connections from the server to the proxy have their destination address rewritten, so they are redirected to the client. The proxy uses the pf(4) anchor facility for this. Assuming the FTP control connection is from $client to $server, the proxy connected to the server using the $proxy source address, and $port is ne- gotiated, then pftpx adds the following rules to the various anchors. (These example rules use inet, but the proxy also supports inet6.) In case of active mode (PORT or EPRT): rdr from $server to $proxy port $port - $client pass log quick inet proto tcp \ from $server to $client port $port flags S/SAFR keep state In case of passive mode (PASV or EPSV): nat from $client to $server port $port - $proxy pass log quick inet proto tcp \ from $client to $server port $port flags S/SAFR keep state pass log quick inet proto tcp \ from $proxy to $server port $port flags S/SAFR keep state The options are as follows: -6 IPv6 mode. The proxy will expect and use IPv6 addresses for all communication. Only the extended FTP modes EPSV and EPRT are al- lowed with IPv6. The proxy is in IPv4 mode by default. -b address Address where the proxy will listen for redirected connections. The default is 127.0.0.1, or ::1 in IPv6 mode. -c port Port where the proxy will listen for redirected connections. The default is port 8021. -d Do not daemonize. The process will stay in the foreground, log- ging to stderr. -D level Debug level, ranging from 0 to 7. Higher is more verbose. The default is 5. (These levels correspond to the syslog(3) levels.) -f address Fixed server address. The proxy will always connect to the same server, regardless of where the client wanted to connect to (be- fore it was redirected). Use this option to proxy for a server behind NAT, or to forward all connections to another proxy. -g port Fixed server port. Only used in combination with the previous option. The default is port 21. -m maxsessions Maximum number of concurrent FTP sessions. When the proxy reach- es this limit, new connections are denied. The default is 100. -p address Proxy source address. The proxy will use this as the source ad- dress to connect to servers. -q queue Create rules with queue queue appended, so that data connections can be queued. -t timeout Number of seconds that the control connection can be idle, before the proxy will disconnect. The default is 24 hours. Do not set this too low, because the control connection is usually idle when large data transfers are taking place. CONFIGURATION To make use of the proxy, pf.conf(5) needs the following rules. All an- chors are mandatory. The rdr pass rule can be adjusted as needed. In the NAT section: nat-anchor pftpx/* rdr-anchor pftpx/* rdr pass on $int_if proto tcp from $lan to any port 21 - 127.0.0.1 port 8021 In the rule section: anchor pftpx/* SECURITY Negotiated data connection ports below 1024 are not allowed. The negotiated IP address for active modes is ignored for security rea- sons. This makes third party file transfers impossible. pftpx chroots to /var/empty and changes to user proxy to drop privi- leges. SEE ALSO ftp(1), pf(4), pf.conf(5),
new ftp proxy: pftpx
Ok, bleeding edge pf people... I wrote a new FTP proxy called pftpx and I'd like to solicit some feedback from the community... Why should you try it? What advantages does pftpx offer? 1) it handles all ftp modes: PORT, PASV, EPRT, EPSV 2) it handles ipv6 3) it should scale: one process handles all sessions using libevent 4) it works with strict ftp clients (clients that want data connections to the same IP as the control connection) Quick guide: - you need libevent-0.8 (OpenBSD 3.6 has it) - download http://www.sentia.org/downloads/pftpx-0.3.tar.gz - untar, make - add this to pf.conf in the nat section: nat-anchor pftpx/* rdr-anchor pftpx/* rdr pass on $if proto tcp from any to any port 21 - 127.0.0.1 port 8021 - add this to pf.conf in the rule section: anchor pftpx/* - run the proxy in debug mode: sudo pftpx -d -D7 - ready to go... Sorry, no manpage yet, this is bleeding edge after all. Don't run this in production if your job depends on it. :-) All feedback welcome, also if you want to suggest a better name. :-) Regards, Cam
Re: new ftp proxy: pftpx
Hi There. This is a great news!!! Do you know if work on freebsd? Thanks Marcos Biscaysaqu Camiel Dobbelaar wrote: Ok, bleeding edge pf people... I wrote a new FTP proxy called pftpx and I'd like to solicit some feedback from the community... Why should you try it? What advantages does pftpx offer? 1) it handles all ftp modes: PORT, PASV, EPRT, EPSV 2) it handles ipv6 3) it should scale: one process handles all sessions using libevent 4) it works with strict ftp clients (clients that want data connections to the same IP as the control connection) Quick guide: - you need libevent-0.8 (OpenBSD 3.6 has it) - download http://www.sentia.org/downloads/pftpx-0.3.tar.gz - untar, make - add this to pf.conf in the nat section: nat-anchor pftpx/* rdr-anchor pftpx/* rdr pass on $if proto tcp from any to any port 21 - 127.0.0.1 port 8021 - add this to pf.conf in the rule section: anchor pftpx/* - run the proxy in debug mode: sudo pftpx -d -D7 - ready to go... Sorry, no manpage yet, this is bleeding edge after all. Don't run this in production if your job depends on it. :-) All feedback welcome, also if you want to suggest a better name. :-) Regards, Cam
Re: new ftp proxy: pftpx
On Thu, 25 Nov 2004, Marcos Biscaysaqu - ThePacific.net wrote: Do you know if work on freebsd? Not sure. The two most important parts are: - recursive anchors (appeared in OpenBSD 3.6). Maybe Max knows when those when into FreeBSD? - libevent 0.8 (from ports/devel/libevent) Anything else that crops up should be easily fixable. -- Cam
Re: new ftp proxy: pftpx
Hi there. Great work my friend!. Working on it to make it work on freebsd as sonner as possible. thanks Marcos Biscaysaqu Camiel Dobbelaar wrote: On Thu, 25 Nov 2004, Marcos Biscaysaqu - ThePacific.net wrote: Do you know if work on freebsd? Not sure. The two most important parts are: - recursive anchors (appeared in OpenBSD 3.6). Maybe Max knows when those when into FreeBSD? - libevent 0.8 (from ports/devel/libevent) Anything else that crops up should be easily fixable. -- Cam
Re: new ftp proxy: pftpx
On Wednesday 24 November 2004 21:32, Camiel Dobbelaar wrote: On Thu, 25 Nov 2004, Marcos Biscaysaqu - ThePacific.net wrote: Do you know if work on freebsd? Not sure. The two most important parts are: - recursive anchors (appeared in OpenBSD 3.6). Maybe Max knows when those when into FreeBSD? They will not come to the 5-STABLE branch, as we don't do user visible changes in the STABLE branch. So it will not be until 6-STABLE before we have recursive anchors in a FreeBSD Release. Do you really *need* recursive anchors? I'd guess one could work around this requirement. - libevent 0.8 (from ports/devel/libevent) Anything else that crops up should be easily fixable. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpO0l2ExgkBE.pgp Description: PGP signature
Re: RDR rule for ftp-proxy
Steve,
Sorry about giving you an answer which was a bit off.
Of course Daniel Hartmeier is right with regard to the negation.
I also just noticed that your pflog0 dump actually says pass instead of
block.
Must have been the effects of a slight flu I'm suffering from.
Good that you have it working now.
Regards,
Daniel
Original message from Daniel Polak at 9-11-2004 0:04
Original message from Maat, Steve at 8-11-2004 23:21
Some internal ftp clients do not appear to be working through a new
OpenBSD (3.6) pf firewall configured with ftp-proxy.
I am trying prevent several clients from being redirected by the
ftp-proxy since they can't seem to handle the way ftp-proxy takes over
the ftp-session. I am not sure if they cannot handle the change in the
tcp/ip address or if it's a port issue (XP with SP2 firewall = BAD, XP
without SP2 firewall = good)
Anyway, is this a valid rule for the ftp-proxy rdr rule:
rdr on em0 proto tcp \ from { !152.12.29.195 , 152.12.0.0/16 } \
to any port 21 - 127.0.0.1 port 8021
I've made the change to pf.conf, flushed rules, state nat and reloaded
pf.conf, but when monitoring pflog0 during the ftp session I still see
the following:
Nov 08 17:03:21.009015 rule 1008/0(match): pass in on em0:
152.12.29.195.2514 127.0.0.1.8021: S 1646188028:1646188028(0) win
64512 mss 1460,nop,nop,sackOK
Steve,
A rdr rule is not the same as a pass rule.
You probably also need a rule like:
pass in quick on em0 proto tcp from { !152.12.29.195 , 152.12.0.0/16
} to 127.0.0.1 port 8021
Check what rule 1008 is with pfctl -v -v -s rules | grep @ | more.
That should help you find out what rule is blocking the FTP transfer.
Daniel
RE: RDR rule for ftp-proxy
Clears things up. Moved list to a table and all works as expected.
Thanks
SM
-Original Message-
From: Daniel Hartmeier [mailto:[EMAIL PROTECTED]
Sent: Monday, November 08, 2004 8:43 PM
To: Maat, Steve
Cc: [EMAIL PROTECTED]
Subject: Re: RDR rule for ftp-proxy
On Mon, Nov 08, 2004 at 05:21:46PM -0500, Maat, Steve wrote:
rdr on em0 proto tcp \
from { !152.12.29.195 , 152.12.0.0/16 } \
to any port 21 - 127.0.0.1 port 8021
This is a frequently asked question, which the FAQ didn't answer so far,
the following paragraph was just added:
Beware of constructs like the following, dubbed negated lists,
which
are a common mistake:
pass in on fxp0 from { 10.0.0.0/8, !10.1.2.3 }
While the intended meaning is usually to match any address within
10.0.0.0/8, except for 10.1.2.3, the rule expands to:
pass in on fxp0 from 10.0.0.0/8
pass in on fxp0 from !10.1.2.3
which matches any possible address. Instead, a table should be used.
Let me know if this doesn't clear things up completely, as in that case
the FAQ needs adjusting, too ;)
Daniel
RDR rule for ftp-proxy
Some internal ftp clients do not appear to be working through a new
OpenBSD (3.6) pf firewall configured with ftp-proxy.
I am trying prevent several clients from being redirected by the
ftp-proxy since they can't seem to handle the way ftp-proxy takes over
the ftp-session. I am not sure if they cannot handle the change in the
tcp/ip address or if it's a port issue (XP with SP2 firewall = BAD, XP
without SP2 firewall = good)
Anyway, is this a valid rule for the ftp-proxy rdr rule:
rdr on em0 proto tcp \
from { !152.12.29.195 , 152.12.0.0/16 } \
to any port 21 - 127.0.0.1 port 8021
I've made the change to pf.conf, flushed rules, state nat and reloaded
pf.conf, but when monitoring pflog0 during the ftp session I still see
the following:
Nov 08 17:03:21.009015 rule 1008/0(match): pass in on em0:
152.12.29.195.2514 127.0.0.1.8021: S 1646188028:1646188028(0) win
64512 mss 1460,nop,nop,sackOK
Thanks...
SM
Re: RDR rule for ftp-proxy
Original message from Maat, Steve at 8-11-2004 23:21
Some internal ftp clients do not appear to be working through a new
OpenBSD (3.6) pf firewall configured with ftp-proxy.
I am trying prevent several clients from being redirected by the
ftp-proxy since they can't seem to handle the way ftp-proxy takes over
the ftp-session. I am not sure if they cannot handle the change in the
tcp/ip address or if it's a port issue (XP with SP2 firewall = BAD, XP
without SP2 firewall = good)
Anyway, is this a valid rule for the ftp-proxy rdr rule:
rdr on em0 proto tcp \
from { !152.12.29.195 , 152.12.0.0/16 } \
to any port 21 - 127.0.0.1 port 8021
I've made the change to pf.conf, flushed rules, state nat and reloaded
pf.conf, but when monitoring pflog0 during the ftp session I still see
the following:
Nov 08 17:03:21.009015 rule 1008/0(match): pass in on em0:
152.12.29.195.2514 127.0.0.1.8021: S 1646188028:1646188028(0) win
64512 mss 1460,nop,nop,sackOK
Steve,
A rdr rule is not the same as a pass rule.
You probably also need a rule like:
pass in quick on em0 proto tcp from { !152.12.29.195 , 152.12.0.0/16 }
to 127.0.0.1 port 8021
Check what rule 1008 is with pfctl -v -v -s rules | grep @ | more. That
should help you find out what rule is blocking the FTP transfer.
Daniel
Re: RDR rule for ftp-proxy
On Mon, Nov 08, 2004 at 05:21:46PM -0500, Maat, Steve wrote:
rdr on em0 proto tcp \
from { !152.12.29.195 , 152.12.0.0/16 } \
to any port 21 - 127.0.0.1 port 8021
This is a frequently asked question, which the FAQ didn't answer so far,
the following paragraph was just added:
Beware of constructs like the following, dubbed negated lists, which
are a common mistake:
pass in on fxp0 from { 10.0.0.0/8, !10.1.2.3 }
While the intended meaning is usually to match any address within
10.0.0.0/8, except for 10.1.2.3, the rule expands to:
pass in on fxp0 from 10.0.0.0/8
pass in on fxp0 from !10.1.2.3
which matches any possible address. Instead, a table should be used.
Let me know if this doesn't clear things up completely, as in that case
the FAQ needs adjusting, too ;)
Daniel
Re: Carp Ftp-proxy address translation
On Sun, Oct 17, 2004 at 08:21:56PM -0700, Yuri wrote: Heyo I have a failover firewall setup with 2 boxes using CARP. Everything works ok, but i have a question about ftp-proxy... Box #1 has external ip: 100.100.100.2 and internal ip: 10.0.0.2 Box #2 has external ip: 100.100.100.3 and internal ip: 10.0.0.3 They both share external CARP address 100.100.100.1 and internal CARP: 10.0.0.1 All requests that come from internal network, go out on CARP address so from outside you see that all requests are coming from 100.100.100.1: nat on $ext_if from $internal_net to any - $external_carp All active ftp requests that use ftp-proxy are taken care of by this: 1) rdr on $carp_int proto tcp from any to any port 21 - 127.0.0.1 port 8021 2) pass in on $ext_if inet proto tcp from any to $carp_ext user proxy keep state But when i do that, the ftp requests are coming from Box's #1 external interface ( 100.100.100.2) and not the CARP address ( 100.100.100.1 ), and when the second box takes over they're coming from 100.100.100.3 Is there any ways i can force all the outgoing active ftp requests come from CARP address (100.100.100.1) instead? If so, what changes to i need to make in pf/carp/ftp-proxy setup...? man 8 ftp-proxy says: -a address Specify the local IP address to use in bind(2) as the source for connections made by ftp-proxy when connecting to destination FTP servers. -j -- Jason Opperisano [EMAIL PROTECTED]
Re: Carp Ftp-proxy address translation
I'm not sure what benefit you think you're getting from forcing the ftp to come from the carp address. If the machines swap state (master fails), the ftp will fail also as it's relying on a userland process to facilitate it. You might want to check out ftpsesame (http://www.sentia.org/projects/ftpsesame/) - it might work a little better for you. --Bill On Sun, 17 Oct 2004 20:21:56 -0700, Yuri [EMAIL PROTECTED] wrote: Heyo I have a failover firewall setup with 2 boxes using CARP. Everything works ok, but i have a question about ftp-proxy... Box #1 has external ip: 100.100.100.2 and internal ip: 10.0.0.2 Box #2 has external ip: 100.100.100.3 and internal ip: 10.0.0.3 They both share external CARP address 100.100.100.1 and internal CARP: 10.0.0.1 All requests that come from internal network, go out on CARP address so from outside you see that all requests are coming from 100.100.100.1: nat on $ext_if from $internal_net to any - $external_carp All active ftp requests that use ftp-proxy are taken care of by this: 1) rdr on $carp_int proto tcp from any to any port 21 - 127.0.0.1 port 8021 2) pass in on $ext_if inet proto tcp from any to $carp_ext user proxy keep state But when i do that, the ftp requests are coming from Box's #1 external interface ( 100.100.100.2) and not the CARP address ( 100.100.100.1 ), and when the second box takes over they're coming from 100.100.100.3 Is there any ways i can force all the outgoing active ftp requests come from CARP address (100.100.100.1) instead? If so, what changes to i need to make in pf/carp/ftp-proxy setup...? Thanky in advance :) P.S. Assignments are: internal_net=10.0.0.0/24 external_addr=100.100.100.2 external_carp=100.100.100.1 carp_int=carp0 (10.0.0.1) carp_ext=carp1 (100.100.100.1)
Re: simple ftp-proxy problems.
On Sep 11, 2004, at 8:37 AM, Mipam wrote: Hi, I was trying to make ftp'ing from my inside nw to internet possible. So in pf.conf (state-policy is floating): rdr pass on $int_if proto tcp to port ftp - 127.0.0.1 port 8021 pass in on $ext_if inet proto tcp from any to $ext_if user proxy keep state pass out on $int_if inet proto tcp from any to $ext_if user proxy keep state You are proxying connections from your _internal_ network, right? EZ in inetd.conf 127.0.0.1:8021 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy I do use natting though cause inside i have a 10.x.y.z network. However, connection cannot be set up succesfully, not passive and not active. I dont see any drops either. (as example to ftp.openbsd.org): I do see this (fstat | grep internet | grep proxy): proxy ftp-proxy 1300 0* internet stream tcp c19ad9e0 127.0.0.1:8021 - 10.1.1.12:1316 proxy ftp-proxy 1300 1* internet stream tcp c19ad9e0 127.0.0.1:8021 - 10.1.1.12:1316 proxy ftp-proxy 1300 2* internet stream tcp c19ad9e0 127.0.0.1:8021 - 10.1.1.12:1316 proxy ftp-proxy 1300 4* internet stream tcp c19adc58 82.161.169.153:57731 - 129.128.5.191:21 proxy ftp-proxy 1300 5* internet stream tcp c19d627c *:56551 proxy ftp-proxy 480 0* internet stream tcp c19ad62c 127.0.0.1:8021 - 10.1.1.12:1298 proxy ftp-proxy 480 1* internet stream tcp c19ad62c 127.0.0.1:8021 - 10.1.1.12:1298 proxy ftp-proxy 480 2* internet stream tcp c19ad62c 127.0.0.1:8021 - 10.1.1.12:1298 proxy ftp-proxy 480 4* internet stream tcp c19add94 82.161.169.153:58786 - 129.128.5.191:21 proxy ftp-proxy 480 5* internet stream tcp c19d6004 *:59574 proxy ftp-proxy 1087 0* internet stream tcp c19ad8a4 127.0.0.1:8021 - 10.1.1.12:1296 proxy ftp-proxy 1087 1* internet stream tcp c19ad8a4 127.0.0.1:8021 - 10.1.1.12:1296 proxy ftp-proxy 1087 2* internet stream tcp c19ad8a4 127.0.0.1:8021 - 10.1.1.12:1296 proxy ftp-proxy 1087 4* internet stream tcp c19ad768 82.161.169.153:59791 - 62.243.72.50:21 proxy ftp-proxy 1087 5* internet stream tcp c19ad4f0 *:5 What did i configure wrong? How can i fix it? Bye, Mipam.
Re: simple ftp-proxy problems.
On Sat, 11 Sep 2004, Mipam wrote: Hi, I was trying to make ftp'ing from my inside nw to internet possible. So in pf.conf (state-policy is floating): rdr pass on $int_if proto tcp to port ftp - 127.0.0.1 port 8021 pass in on $ext_if inet proto tcp from any to $ext_if user proxy keep state in inetd.conf 127.0.0.1:8021 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy I do use natting though cause inside i have a 10.x.y.z network. [SNIP] It's fixed now: The only thing i changed is adding a -n to ftp-proxy in /etc/inetd.conf Bye, Mipam.
ftp-proxy pfsync
Hi ppl! I set up a firewall cluster with OpenBSD snapshot (the first 3.6). Now I can consider as highly available every connection through the cluster *but* FTP(using ftp-proxy at application level). Is out there a sort of workaround for this? I need to switch without loosing ftp connections. Is it possible? thank you in advance, -- GHERdO, happy GNU/linux user. ... Boys don't Cry!
RE: ftp-proxy on a bridging firewall
My understanding of the ftp proxy is that you only need it on systems running NAT. If you're running a bridging firewall, then I'm assuming that all the machines behind it have public IP addresses? Cheers, Mattias Lindgren I'm Mattias Lindgren, and I've approved the contents of this message -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Hodges Sent: Monday, August 23, 2004 3:30 PM To: [EMAIL PROTECTED] Subject: Re: ftp-proxy on a bridging firewall I have been pointed at FTPSesame by two people, and it looks pretty much ideal to me (I'm not using NAT), and philosophically a preferable solution. However, I would also like to understand why my present solution doesn't work. I know that an IP address is required, but as I said, my bridge has one. Daniel said in a response to another questioner that this required IP addresses on both interfaces - why should this be so, when the one IP address I have is accessible from all legs of the bridge? I already use it for SSH access for control of the firewall from different places. I also note that the redirection for ftp-proxy is conventionally to 127.0.0.1, and that this might require forwarding to be enabled. Is there any reason not to use the IP address of the bridge, given that I have set inetd up to respond to 8021 on all local IPs? If I knew the answers to these questions, I could doubtless solve my original problem directly - but I don't, and have been unable to find them in the archive. Paul -- Paul Hodges IT Support Manager Dept of Clinical Pharmacology Oxford University 01865-224418
ftp-proxy on a bridging firewall
My configuration is that I have a (four-legged) bridge, and the EXT interface was assigned an IP address which I can access from anywhere for managing the firewall. I am trying to set up the ftp-proxy. I have defined the port in /etc/services and then enabled the proxy in /etc/inetd.conf using the port name, and specifying -u proxy so that I can filter the active port connections using that. I have added rules in pf.conf to redirect to port 8021 at the firewall address (I didn't use 127.0.0.1 because I wasn't sure it would work without routing enabled). I have logged the first packet being directed to port 8021 on the firewall address, but then... nothing. What should I be checking at this stage, as all the lines I have typed match the books and manuals as far as I can see. Can anyone suggest what I have missed, or how I can diagnose this further? Thanks, Paul In my pf.conf: rdr on $INT proto tcp from any to any port 21 - $FW port 8021 [...] # Allow FTP in from local for proxying, and from remote for data pass in log quick on $INT proto tcp from $INTip to $FW port 8021 \ flags S/SA keep state pass in log quick on $EXT proto tcp from any port 20 to $FW \ user proxy flags S/SA keep state block in quick from any to $FW pass out log quick from $FW to any modulate state In my inetd.conf: ftp-proxy stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy -u proxy -t 300 (I haven't defined the user proxy - it seems to be there already) -- Paul Hodges IT Support Manager Dept of Clinical Pharmacology Oxford University 01865-224418
Re: ftp-proxy on a bridging firewall
On Tue, 2004-08-24 at 04:55, Paul Hodges wrote: My configuration is that I have a (four-legged) bridge, and the EXT interface was assigned an IP address which I can access from anywhere for managing the firewall. I am trying to set up the ftp-proxy. My understanding is that you can not run ftp-proxy on a bridge, you must have IP addresses on all interfaces. THe proxy breaks the bridge's transparency. I am using ftpsesame on my bridge and it works just fine. I don't have the url to hand but there are references to it in the archive. -- Russell Fulton, Information Security Officer, The University of Auckland New Zealand
Re: ftp-proxy on a bridging firewall
I have been pointed at FTPSesame by two people, and it looks pretty much ideal to me (I'm not using NAT), and philosophically a preferable solution. However, I would also like to understand why my present solution doesn't work. I know that an IP address is required, but as I said, my bridge has one. Daniel said in a response to another questioner that this required IP addresses on both interfaces - why should this be so, when the one IP address I have is accessible from all legs of the bridge? I already use it for SSH access for control of the firewall from different places. I also note that the redirection for ftp-proxy is conventionally to 127.0.0.1, and that this might require forwarding to be enabled. Is there any reason not to use the IP address of the bridge, given that I have set inetd up to respond to 8021 on all local IPs? If I knew the answers to these questions, I could doubtless solve my original problem directly - but I don't, and have been unable to find them in the archive. Paul -- Paul Hodges IT Support Manager Dept of Clinical Pharmacology Oxford University 01865-224418
ftp-proxy on a non NAT'ing firewall - can it work?
Hey there all Well, after a little hiccup with a RAID failing (gotta love hardware), I have had a few minutes to revisit my ftp/ftp-proxy problem. Unfortunately, the time away has not provided adequate clarity and I am posting to the list for some help on that front! ;) SETUP OpenBSD 3.5 firewall setup for a border firewall NOT doing any NAT (just routing packets for one NIC to the next) with a PC on each side of it. ie: Test PC/ftp client OBSD BOXTest FTP Server 192.168.1.2 -192.168.1.1 (int) 192.168.2.1 (ext) - 192.168.2.2 CURRENT STATE OF PLAY With the test ruleset at the end of this email, I get the following: - Internal client using an ACTIVE FTP connection. Connection and control channel work fine. Data connection is there but is _way_ slow when uploading a file to the external test server. Only getting a transfer of 103KB/s when uploading whereas I am getting 9,000KB/s when downloading the same file. - Internal client using a PASV FTP connection - Connects and control connection established fine. No data connection made. TCPDUMPS * Active FTP connection from 192.168.1.2 to 192.168.2.2 If I do a tcpdump I can see the FTP proxy doing its job. Packets are heading for port 21 on the external server, the redirection kicks in and the ftp-proxy then connects to the external server. The server then responds, the ftp-proxy gets the response and forwards it to the internal client (with IP address of 192.168.2.2 still intact - according to a tcpdump on the internal machine). When a download or upload occurs however the IP is changed to the OBSD internal address. Is that supposed to happen? That is, a dump on the internal machine shows: Control connection: 192.168.1.2.51446 192.168.2.2.21 192.168.2.2.21 192.168.1.2.51446 Data connection: 192.168.1.1.51126 192.168.1.2.3293 192.168.1.2.3293 192.168.1.1.51126 * Passive FTP connection from 192.168.1.2 to 192.168.2.2 I think the ftp-proxy is missing the data connection all together; I have tried with the -n option in inetd.conf as well. Does ftp-proxy assumes masquerading will take care of it?. The control connection works fine. The redirection occurs, ftp-proxy grabs the control connection then connects to the external server. When it comes time for the data connection to start, the internal machine sends its packets to the external machines BUT ftp-proxy does nothing. As such, the ftp server on the other side gets a connection from an incorrect IP and, quite correctly, sends a RESET back and the ftp client reports Connection Refused. TCPDump from the internet client machine: Control connection (no problems, ftp-proxy is changing the addresses on each side and all is well): 192.168.1.2.3332 192.168.2.2.21: S 192.168.2.2.21 192.168.1.2.3332: S 192.168.1.2.3332 192.168.2.2.21: . ack 192.168.2.2.21 192.168.1.2.3332: P Data connection attempt (external ftp server is receiving packets from 192.168.1.2 instead of 192.168.2.2 where the connection was originally made): 192.168.1.2. 192.168.2.2.61689: S ... 192.168.2.2.61689 192.168.1.2.: R ... QUESTIONS 1. Am I just beating my head against a wall here? Is getting active and passive from internal FTP clients even possible when pf is used in a border firewall type situation with no NAT going on? Is ftp-proxy the correct option? 2. If ftp-proxy is the correct option, pointers please. And why is the upload in active ftp going so slowly? 3. Failing the use of ftp-proxy, is the best course of action to just allow traffic in for =1024 ports to clients using active ftp? (I don't really want to do this and it would be a last resort) Any help would be greatly appreciated please guys! Thanks, Andrew TEST RULESET (using two private addresses for now) ext_if = xl0 ext_ip = 192.168.2.1 ext_net = 192.168.2.1/24 int_if = xl1 int_ip = 192.168.1.1 int_net = 192.168.1.1/24 rdr on $int_if proto tcp from any to any port 21 - 127.0.0.1 \ port 8021 block in log all block out log all # FTP-PROXY rules (for internal ftp clients connecting to external FTP servers) # Allow redirections to the proxy server on this machine pass in quick log on $int_if proto tcp from $int_net \ to 127.0.0.1 port 8021 keep state # Outbound connections owned by ftp-proxy (user proxy) are ok on int card (to # clients) and ext card (to ext servers) pass out quick log on $ext_if proto tcp from any to any \ user proxy keep state pass out quick log on $int_if proto tcp from any to any \ user proxy keep state # FTP connections coming back to ftp-proxy (user proxy) owned processes are ok pass in quick log on $ext_if proto tcp from any to any \ user proxy keep state pass in quick log on $int_if proto tcp from any to any \ user proxy keep state # LOOPBACK - Pass traffic on the loopback interface in either direction pass quick on lo0 all # SSH - Inbound from internal network only pass in quick on $int_if proto tcp from $int_net to $int_ip \ port 22 keep
reverse ftp-proxy in the source tree?
For quite some time now Daniel Hartmeier has provided a reverse ftp patch at http://www.benzedrine.cx/ftp-proxy-reverse.diff. Unfortunately that patch doesn't work with OpenBSD 3.5 anymore. Is there a reason why this patch has never made it into the source tree? Daniel
Re: reverse ftp-proxy in the source tree?
On Wed, Jun 02, 2004 at 09:37:21PM +0200, Daniel Polak wrote: Unfortunately that patch doesn't work with OpenBSD 3.5 anymore. I split the patch into a 3.4 and 3.5 version: http://www.benzedrine.cx/ftp-proxy-reverse-34.diff MD5 (ftp-proxy-reverse-34.diff) = b9e50720d39d922cdc9a5c024f009ad1 http://www.benzedrine.cx/ftp-proxy-reverse-35.diff MD5 (ftp-proxy-reverse-35.diff) = a765a960d7f2907daf451df2036eece1 Is there a reason why this patch has never made it into the source tree? Due negligence, I guess. You'd have to spam Bob (that is [EMAIL PROTECTED]) with heart-breaking stories like this is really important to me because and I have tested it really, really well, until he surrenders :) Daniel pgpGKC3RvlELF.pgp Description: PGP signature
Re: ftp-proxy problem
I don't want to have to install SQUID on my firewall box. I don't
necessarily need or want a full-blown proxy.
I wonder how dificult it would be to patch ftp-proxy to support
specifying an IP address VIA the command line..
Guess I'll have to investigate
Daniel Corbe wrote:
Hey,
I'm having difficulty getting ftp-proxy working right with very simple
settings. Is there any way to tell ftp-proxy whay IP address to use
for outgoing connections? Because in my setup it's using the wrong IP
address (146.82.194.227) as opposed to my NAT IP (208.178.226.254)
Any help would be appriciated
Thanks
inetd.conf entry:
# FTP proxy
208.178.226.254:8021 stream tcp nowait root /usr/libexec/ftp-proxy -D
3 ftp-proxy
Firewall rules:
int = fxp0
# scrub in on $int all
# Don't want to translate private
no nat on $int from any to { 10/8, 172.16/12, 192.168/16,
208.178.226.254/29, 146.82.194.224/27 }
rdr proto tcp from any to any port 21 - 208.178.226.254 port 8021
nat on $int from 10.64.14.0/24 to any - 208.178.226.254
# Packet Filter
pass in all
pass out all
pass in proto ospf all
pass out proto ospf all
Here's the interface config:
fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
address: 00:0b:cd:4d:5c:e9
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet6 fe80::20b:cdff:fe4d:5ce9%fxp0 prefixlen 64 scopeid 0x1
inet 146.82.194.227 netmask 0xfff0 broadcast 146.82.194.239
inet 10.64.14.1 netmask 0xff00 broadcast 10.64.14.255
inet 146.82.194.231 netmask 0xfff0 broadcast 146.82.194.239
inet6 2001:450:b:0:20b:cdff:fe4d:5ce9 prefixlen 64
inet6 2001:450:b::beef prefixlen 64
inet 10.64.14.40 netmask 0xff00 broadcast 10.64.14.255
inet 208.178.226.254 netmask 0xfff8 broadcast 208.178.226.255
Re: Reverse ftp-proxy patch and active FTP
Daniel Hartmeier wrote: Passive/active can be ambiguous, for the client passive mode means the clients connects to the server for data connections. But from your further description I think you mean data connections from the server to the client, right? Yes, that is correct. As I understand your setup, you have a dedicated external address which you binat to the ftp server's local address, as in binat on $ext_if from 10.1.2.3 to any - 62.65.145.30 where 10.1.2.3 would be the ftp server's internal address, and 62.65.145.30 the dedicated external address of the firewall. You run ftp-proxy in reverse mode from inetd.conf, like 62.65.145.30:8021 stream tcp nowait root /usr/libexec/ftp-proxy \ ftp-proxy -R 10.1.2.3:21 and redirect incoming ftp control connections from external clients to the proxy using rdr on $ext_if from any to 62.65.145.30 port 21 \ - 62.65.145.30 port 8021 While ftp-proxy in reverse mode doesn't usually need a redirection, in the binat case I think you need one to prevent the incoming control connection from simply getting forwarded to the internal address, bypassing the proxy. Try following a control connection with tcpdump, it should come in on $ext_if to 62.65.145.30:21, get redirected to port 8021, where inetd starts an ftp-proxy process. The proxy connects to 10.1.2.3:21, and the proxied control connection should work both ways (login should work). I will try this later. For now, I don't have any nat rules on the IP address that I am trying to use as an external address for the FTP server - I am just trying to get the proxy to work by having it listen on one of the firewalls addresses and bouncing inside (where the server's IP address that the FTP server is running on as well doesn't have any NAT rules). When the client requests a data connection from the server to the client, follow that with tcpdump. You should see the data connection come in on $int_if of the firewall, then leave $ext_if. One possible problem is that ftp-proxy doesn't bind to the right external address (in the presence of multiple aliases), and the external client refuses or ignores a data connection from an unexpected source. This should be visible in a tcpdump on the external interface. This is exactly the problem just confirmed with tcpdump. The firewall/proxy is trying to establish the data connection back to the client from its primary IP address, rather than the address that I configured xinetd to listen to. I'm no network programming guru, so I don't even know if its possible to see what address [x]inetd was listening on, but I quickly coded up a new argument to specify which IP address data connections come from, and so far it seems to work. I was going down this path last night, and did verify that I could establish connections from any IP on the server just in case, but both FTP clients I was using to test are behind NAT's, so of course if we don't establish the data connection from the same IP it is never going to get past the NAT on the client side .. duh. Daniel Thanks a lot, I really appreciate it. I am still testing the ramifications of my patch, and like I said, I'm not really a network programming guru, but if anyone wants it, they are free to have it. Tim
Re: Reverse ftp-proxy patch and active FTP
On Mon, Mar 15, 2004 at 11:23:53AM -0700, Tim Pushor wrote: I am still testing the ramifications of my patch, and like I said, I'm not really a network programming guru, but if anyone wants it, they are free to have it. If it solves your problem, please send me a patch. I'll review it if you're unsure and try to add it, if not to the tree then at least to the reverse patch. Thanks for the feedback! Daniel
problem with ftp proxy rule
Hi All, I am getting errors from a rule I copied from the ftp-proxy manpage to handle data connections: pass in quick on $ext_if inet proto tcp from any to $ext_if user proxy \ keep state the error I get is: rule expands to no valid combination. I am unsure what this actually means. $ext_if is defined and used in many other rules. User proxy is defined. I am a little puzzled as to exactly how this rule works particularly since $ext_if occurs on both sides of the rule. The box is currently configured as a bridge and I suspect that this may be the problem -- I'm aware that proxies break the bridge model. Cheers and thanks, Russell. -- Russell Fulton/~\ The ASCII Network Security Officer \ / Ribbon Campaign The University of Auckland X Against HTML New Zealand / \ Email!
Re: binat and ftp proxy
I'm new to PF so I'm sure this has been talked to death, but one thing I
really don't like about these proxyies is the fact that they seem to
come from the firewall.
I am all for the firewall understanding a bit about the applications
behind it - it makes rule writing much easier.
But thanks for your patch - its always nice to have other options.
Tim
Scott L. Burson wrote:
Hi,
I also wanted a reverse FTP proxy. Not being aware of the existing patch to
`ftp-proxy', I developed my own. I think it is better in two ways:
(1) It supports EPSV in reverse mode (though I haven't tested it with v6
addresses).
(2) It is better documented.
I hope we can get one of these patches integrated into the official sources.
It's kindof a drag finding out I didn't need to do this in the first place.
Well, I sent my patch to the OpenBSD gods -- we'll see if they accept it.
-- Scott
*** ftp-proxy.c.~1~ 2003-08-22 14:50:34.0 -0700
--- ftp-proxy.c 2003-12-29 14:35:18.0 -0800
***
*** 128,133
--- 128,134
struct sockaddr_in real_server_sa;
struct sockaddr_in client_listen_sa;
struct sockaddr_in server_listen_sa;
+ struct sockaddr_in proxy_sa;
int client_listen_socket = -1; /* Only used in PASV mode */
int client_data_socket = -1; /* Connected socket to real client */
***
*** 138,147
int AnonFtpOnly;
int Verbose;
int NatMode;
char ClientName[NI_MAXHOST];
char RealServerName[NI_MAXHOST];
! char OurName[NI_MAXHOST];
char *User = proxy;
char *Group;
--- 139,151
int AnonFtpOnly;
int Verbose;
int NatMode;
+ int Reverse;
+ char *RevServer;
char ClientName[NI_MAXHOST];
char RealServerName[NI_MAXHOST];
! char OurNameForServer[NI_MAXHOST];
! char OurNameForClient[NI_MAXHOST];
char *User = proxy;
char *Group;
***
*** 573,579
--- 577,587
if (connect(client_data_socket, (struct sockaddr *) client_listen_sa,
sizeof(client_listen_sa)) != 0) {
+ unsigned a = ntohl(client_listen_sa.sin_addr.s_addr);
syslog(LOG_INFO, cannot connect data channel (%m));
+ debuglog(1, connect failed to %d.%d.%d.%d:%d,
+ a 24, (a 16) 0xFF, (a 8) 0xFF, a 0xFF,
+ ntohs(client_listen_sa.sin_port));
exit(EX_NOHOST);
}
***
*** 727,737
j += rv;
} while (j = 0 j i);
}
! } else if (!NatMode (strncasecmp((char *)client-line_buffer,
! epsv, strlen(epsv)) == 0)) {
/*
! * If we aren't in NAT mode, deal with EPSV.
* EPSV is a problem - Unlike PASV, the reply from the
* server contains *only* a port, we can't modify the reply
* to the client and get the client to connect to us without
--- 735,746
j += rv;
} while (j = 0 j i);
}
! } else if (!NatMode !Reverse
! (strncasecmp((char *)client-line_buffer,
! epsv, strlen(epsv)) == 0)) {
/*
! * If we aren't in NAT or reverse mode, deal with EPSV.
* EPSV is a problem - Unlike PASV, the reply from the
* server contains *only* a port, we can't modify the reply
* to the client and get the client to connect to us without
***
*** 740,745
--- 749,757
* so this will wait until we have the right solution for rule
* additions/deletions in pf.
*
+ * EPSV is not a problem in reverse mode, since the address
+ * the client has for the server is that of the proxy.
+ *
* in the meantime we just tell the client we don't do it,
* and most clients should fall back to using PASV.
*/
***
*** 925,934
new_dataconn(0);
connection_mode = PASV_MODE;
! iap = (server-sa.sin_addr);
debuglog(1, we want client to use %s:%u, inet_ntoa(*iap),
! htons(client_listen_sa.sin_port));
snprintf(tbuf, sizeof(tbuf),
227 Entering Passive Mode (%u,%u,%u,%u,%u,%u)\r\n,
--- 937,946
new_dataconn(0);
connection_mode = PASV_MODE;
! iap = (proxy_sa.sin_addr);
debuglog(1, we want client to use %s:%u, inet_ntoa(*iap),
! ntohs(client_listen_sa.sin_port));
snprintf(tbuf, sizeof(tbuf),
227 Entering Passive Mode (%u,%u,%u,%u,%u,%u)\r\n,
***
*** 938,943
--- 950,995
((u_char *)client_listen_sa.sin_port)[1]);
debuglog(1, to client (modified): %s, tbuf);
sendbuf = tbuf;
+ } else if (Reverse code == 229) {
+ char *tailptr, delim[4];
+ int port;
+
+ debuglog(1, Got an EPSV reply);
+ debuglog(1, {%s}, (char *)server-line_buffer);
+
+ tailptr = (char *)strchr((char *)server-line_buffer, '(');
+ if (tailptr == NULL) {
+ syslog(LOG_NOTICE, malformed 227 reply);
+ exit(EX_DATAERR);
+ }
+
+ tailptr++; /* skip past space or ( */
+ if (sscanf(tailptr, %c%c%c%d%c, delim[0], delim[1],
+ delim[2], port, delim[3]) != 5 ||
+ delim[0] != delim[1] || delim[0] != delim[2] ||
+ delim[0] != delim[3]) {
+ syslog(LOG_INFO, malformed EPSV reply (%s),
+ client-line_buffer);
+ exit(EX_DATAERR
Re: binat and ftp proxy
Daniel, I'm sorry - I meant to reply this morning. I did try to apply the patch and other than failing on the manpage, it worked fine. I'm sorry to have wasted your time and bandwidth. Tim Daniel Hartmeier wrote: On Fri, Jan 23, 2004 at 07:18:03PM -0700, Tim Pushor wrote: I did see that patch already, as well as a newer one, but both of those are not against my current version of ftp-proxy (currently version 1.33 2003/08/22). Does it fail to apply? The revision doesn't have to match exactly, as there were no large changes between revisions lately. If the patch applies (maybe with increased fuzz), it will work fine. If it doesn't, and you can't apply it manually, I'll try to provide a patch specifically for the FreeBSD port. Daniel
binat and ftp proxy
Hi all, I am trying out pf on a new environment I'm building and I must say that I'm impressed. I have come from the ipfilter world .. One difference though is the lack of the in kernel proxy/translation, specifically for ftp. For various reasons, I have a network that uses unregistered addresses that I expose to the internet via static nat. I need to allow ftp from the ouside in, which works as long as its active, but of course passive mode doesn't work. I know that some don't agree with this approach (using static NAT), but its convenient for me for various reasons, and I'd really like to get inbound ftp working via ftp-proxy. Has anyone done this? Care to share your ruleset? I am running pf 2.02 on FreeBSD 5.2. Thanks, Tim
Re: binat and ftp proxy
On Fri, Jan 23, 2004 at 11:32:32AM -0700, Tim Pushor wrote: I know that some don't agree with this approach (using static NAT), but its convenient for me for various reasons, and I'd really like to get inbound ftp working via ftp-proxy. Has anyone done this? Care to share your ruleset? Try the reverse proxy patch for ftp-proxy, it adds a switch for just this purpose, and the man page is patched to document it as well. http://www.benzedrine.cx/ftp-proxy-reverse.diff Daniel
Re: ftp-proxy ALTQ
On Thursday 06 November 2003 12:05, Henning Brauer wrote: I'm wondering if there's a way to let ftp-proxy set the priority queue for every state it creates. this boils down to create an opportunity for userland apps to set mbug tags, either generalized or specialized for altq and/or tagging. we thought about doing this through socket options, but it's not really nice. Is there any news ? Ed
Re: HTTP/FTP Proxy not working
Ok, figured out the problem. I finally noticed that packets with destination 127.0.0.1 were being routed out my main external interface. Why? Don't ask me. So I added this rule: pass in quick on xl2 route-to lo0 from any to 127.0.0.1 keep state Maybe this has something to do with the fact that I've got two external interfaces (xl0 goes to our old frac. T1, xl1 goes to our new full T1). We use xl0 to service our WAN, with all the large traffic from our main support center going out xl1. Anyone have some forensic analysis as to why I had to add this rule? James Cammarata [EMAIL PROTECTED] www.sngx.net home: 314-835-1122 work: 314-872-2426 cell: 314-409-0583 __ Out the Ethernet, through the router, down the fiber, off another router, down the T1, past the fire-wall ...nothing but Net
Re: HTTP/FTP Proxy not working
On Thursday, Jan 1, 2004, at 13:59 US/Pacific, James Cammarata wrote: I finally noticed that packets with destination 127.0.0.1 were being routed out my main external interface. Why? Don't ask me. So I added this rule: pass in quick on xl2 route-to lo0 from any to 127.0.0.1 keep state Maybe this has something to do with the fact that I've got two external interfaces (xl0 goes to our old frac. T1, xl1 goes to our new full T1). We use xl0 to service our WAN, with all the large traffic from our main support center going out xl1. Anyone have some forensic analysis as to why I had to add this rule? netstat -nrf inet can verify that the right interface is being used by the routing tables. But route-to bypasses that, so if you're using it in other pf rules, I would look there first. Perhaps you have something like pass in on xl2 route-to xl1 from $support to any?
Re: HTTP/FTP Proxy not working
At 11:33 AM 12/31/2003 +0100, you wrote:
Do you have 'pass on lo0 keep state' ? Forwarding enabled?
yep forwarding enabled, these are the first rules I have following my
NAT/RDR rules:
# block everything by default
block return-rst in log proto tcp from any to any
blockin log from any to any
# block in spoofs
# log these in case we want to analyze an attack
block in log quick on {xl0,xl1} from $spoof_ips to any
block in log quick on xl0 from anyto $frsmurf_ips
block in log quick on xl1 from anyto $t1smurf_ips
# the local interface is wide open
pass in quick on lo0 all
pass out quick on lo0 all
# no ip6 pls...
block in quick inet6 all
block out quick inet6 all
#
I did comment out the spoof blocking lines above (one of the spoof IP's in
the list is 127.0.0.0/8), and it did not make a difference.
What does 'tcpdump -i pflog0 -env' say when you start an FTP session?
# tcpdump -env -i lo0
tcpdump: listening on lo0
# ifconfig lo0
lo0: flags=8149UP,LOOPBACK,RUNNING,PROMISC,MULTICAST mtu 33224
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
James Cammarata
[EMAIL PROTECTED]
www.sngx.net
home: 314-835-1122
work: 314-872-2426
cell: 314-409-0583
__
Out the Ethernet, through the router,
down the fiber, off another router,
down the T1, past the fire-wall
...nothing but Net
Re: HTTP/FTP Proxy not working
On Wed, 31 Dec 2003, James Cammarata wrote: # the local interface is wide open pass in quick on lo0 all pass out quick on lo0 all You really want the lo0 rules before any block rules, just to be sure. right, normally i'd agree but I doubt it makes a difference here. I've got the global blocks first, followed by very specific blocking on the two external interfaces (which should not affect a 127.0.0.1 address at all) and then the pass quick for the loopback. it wouldn't hurt to move the loopback stuff up first of course, but i'm sure that's not the problem. What does 'tcpdump -i pflog0 -env' say when you start an FTP session? # tcpdump -env -i lo0 tcpdump: listening on lo0 pflog0, not lo0. I'm an idiot :| I did answer this in the first email though, pflog0 was not showing any activity while the ftp program was trying to connect. The command ftp ftp.openbsd.org on my test server caused this on xl2: 192.168.10.11.52157 129.128.5.191.21: tcp 0 (DF) (192.168.10.11 being the internal computer i ran that command on). Nothing appeared on lo0, pflog0, xl1, or xl0 after this packet came into xl2. James Cammarata [EMAIL PROTECTED] www.sngx.net home: 314-835-1122 work: 314-872-2426 cell: 314-409-0583 __ Out the Ethernet, through the router, down the fiber, off another router, down the T1, past the fire-wall ...nothing but Net
Re: Impossible ftp-proxy problem
On Tuesday, Dec 30, 2003, at 14:25 US/Pacific, Ghazan Haider wrote: I am running OpenBSD 3.4 as firewall on one machine, and have tried for weeks to get ftp-proxy to run. Ive tried evey example in the howtos. I can use the ftp sites from the OpenBSD itself, but not from an internal computer. I dont get error messages except a rare pf nat lookup failed 127.0.0.1:48711 (No such file or directory), when ftp-proxy has -D3 and -V Ive tried tcpdumping.. and I see no port 21 connections leaving the ext_if but seen them come in from int_if. A telnet localhost 8021 connects then quickly disconnects, so ftp-proxy does exist. Heres my pf.conf: rdr on $int_if proto tcp from $internal_net to any port 21 - 127.0.0.1 port 8021 block in all # ftp proxy pass in on $int_if proto tcp from any to any port 21 keep state Have to keep in mind that filter rules happen after translation by nat/rdr. Thus, you need to reference port 8021 here.
ftp-proxy ALTQ
Hi, I'm wondering if there's a way to let ftp-proxy set the priority queue for every state it creates. I would like to be able to have ftp downloads at full speed until I start using higher priority queues. The idea is that my ftp downloads should drop speed if I browse the web or check mailbox, but soon restart to get the whole bandwidth when I finished. The problem is that _passive_ ftp download tcp connections have not fixed points: no IP and no ports. Thanks. Ed
Re: ftp-proxy ALTQ
On Thu, Nov 06, 2003 at 10:36:12AM +0100, Ed White wrote: Hi, I'm wondering if there's a way to let ftp-proxy set the priority queue for every state it creates. I would like to be able to have ftp downloads at full speed until I start using higher priority queues. The idea is that my ftp downloads should drop speed if I browse the web or check mailbox, but soon restart to get the whole bandwidth when I finished. The problem is that _passive_ ftp download tcp connections have not fixed points: no IP and no ports. this boils down to create an opportunity for userland apps to set mbug tags, either generalized or specialized for altq and/or tagging. we thought about doing this through socket options, but it's not really nice. what you can do in your situation is filtering on the user - the socket should be owned by use proxy. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: ftp-proxy ALTQ
On Thu, Nov 06, 2003 at 10:36:12AM +0100, Ed White wrote: Hi, I'm wondering if there's a way to let ftp-proxy set the priority queue for every state it creates. [snip] The problem is that _passive_ ftp download tcp connections have not fixed points: no IP and no ports. you can always use 'user proxy' to match connections related to ftp-proxy Can
Correct place to post a patch to ftp-proxy
Is this the right list to post a patch to ftp-proxy? I asked [EMAIL PROTECTED] if it was the right place last night but haven't gotten an answer. Sorry to bug y'all. Please ignore this if you like. Thanks. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein P.S. Patch allows explicit assignment of ip address to be used for proxying, as is needed if the default route is on a private/unroutable network.
ftp-proxy + binat: Here is a patch
Oh dear, I'm just getting wised up to the fact that this is the place to
discuss pf issues -- I've been posting on openbsd.org mailing lists.
I've been working under OpenBSD 3.2, but I think the same issues go all
the way to current -- someone please correct me if I'm wrong. The
problem: ftp-proxy does not work correctly with binat. Consider a
situation where you have an interface that I'll describe as being on the
left, and an interface that I'll describe as being on the right. On
the right network is an ftp server. Hosts on the left network access
hosts on the right network via binat rules. Out of the box, ftp-proxy is
trying to connect to the *translated* (left-side) address instead of
the actual address (right-side).
Enclosed is a patch to util.c that specifically looks up binat rules and
replaces the real server address with its actual address. This makes
active ftp work.
When I got this working, I discovered that of all things *passive* ftp
was not working. If I am proxying passive ftp, with the client on the
left and the server on the right, the client should get passed the
IP address of the interface on the *left* as the IP address to connect
to for the data port. Instead, it was getting the IP address of the
interface on the *right* -- to which it has no route. (And this is a
right-side address, which left-side hosts are never supposed to use.)
Enclosed is a patch to ftp-proxy.c which fixes this problem. In order to
get the patch to work, you need to change your rdr rule from the usual
examples. In the man pages the rdr for ftp-proxy redirects to the IP
address for localhost. With the patch installed, this is the IP address
that gets passed back to the client, and of course that doesn't work.
But it works fine if you change your rdr rule to redirect to the IP
address of the interface facing the client.
E.g. instead of something like
rdr on $mis_if proto tcp from any to any port 21 - 127.0.0.1 port 8081
you would have something like
rdr on $mis_if proto tcp from any to any port 21 - $mis_ip port 8081
I believe quite strongly that ftp-proxy should honor binat rules, so I'm
hopeful that these patches can get worked into cvs; but these patches
need to be reviewed by those with more experience with the code than I
have. I will certainly defer to those with more experience if there's a
better way to do this.
A couple of caveats. The util.c patch works unconditionally. I have
this little birdie telling me that there might be circumstances where
you wouldn't want to do this, though I can't think of what they might
be. It *does* change the behavior of ftp-proxy, so maybe it should be
governed by a command-line option. If the patch to ftp-proxy.c is
accepted, then the man pages should probably also be updated, and I
didn't do any patches for the man pages. Again: these patches were done
against OpenBSD 3.2 stable, so apologies in advance if they don't apply
cleanly against 3.3 or current.
Comments welcome!!
-
Patch for util.c:
*** util.c.orig Wed Jul 24 04:42:52 2002
--- util.c Fri Sep 26 18:02:46 2003
***
*** 77,83
struct sockaddr_in *client_sa_ptr)
{
struct pfioc_natlook natlook;
! int slen, fd;
slen = sizeof(*real_server_sa_ptr);
if (getsockname(connected_fd, (struct sockaddr *)real_server_sa_ptr,
--- 77,84
struct sockaddr_in *client_sa_ptr)
{
struct pfioc_natlook natlook;
! struct pfioc_binat pb;
! int slen, fd, nr, mnr, dev_pf;
slen = sizeof(*real_server_sa_ptr);
if (getsockname(connected_fd, (struct sockaddr *)real_server_sa_ptr,
***
*** 134,139
--- 135,172
real_server_sa_ptr-sin_addr.s_addr = natlook.rdaddr.addr32[0];
real_server_sa_ptr-sin_len = sizeof(struct sockaddr_in);
real_server_sa_ptr-sin_family = AF_INET;
+
+ /*
+* WART: If the real server is binatted, we will have the
+* untranslated address. Look it up (the hard way) and substitute
+* the translated address.
+*/
+ dev_pf = open(/dev/pf, O_RDWR);
+ if (dev_pf = 0 ioctl(fd, DIOCGETBINATS, pb) == 0) {
+ mnr = pb.nr;
+ for (nr = 0; nr mnr; ++nr) {
+ pb.nr = nr;
+ if (ioctl(fd, DIOCGETBINAT, pb)) {
+ syslog(LOG_INFO,
+ get binat failed (%m), connection from %s:%hu,
+ inet_ntoa(client_sa_ptr-sin_addr),
+ ntohs(client_sa_ptr-sin_port));
+ close(fd);
+ return(-1);
+ }
+ if (pb.binat.raddr.addr_dyn != NULL)
+ continue;
+ if (pb.binat.raddr.addr.addr32[0] ==
+ real_server_sa_ptr-sin_addr.s_addr
Re: ftp proxy prob
I had similar problem recently this is how I fixed it...
in /etc/inetd.conf
127.0.0.1:8021 stream tcp nowait root/usr/libexec/ftp-proxy
ftp-proxy -n -u proxy -m 6 -M 65534 -t 300
and in /etc/pf.conf
# rdr outgoing FTP requests to the ftp-proxy
rdr on $int_if proto tcp from any to any port 21 - 127.0.0.1 port 8021
#lets allow ftp through
pass in quick on $ext_if proto tcp from any to $ext_if user proxy keep
state
HTH.
Cheers,
CH
On Oct 20, 2003, at 7:42 PM, Wayne wrote:
Hi Tiago, thank you for your help. I have an IIS5 ftp server behind an
OpenBSD 3.3 PF box.
I tried your suggested rule change but without success.
pass in quick log on $outside proto tcp from any to \
$ftp_server port 10235000 flags S/SA keep state
When I look at my logs I see the initial incoming connection on port
21,
and then a reply back to the client. The client can log in fine, and I
get an ftp prompt ftp
Doing a ftp dir command gets me
200 port command successful.
150 Opening ASCII mode data connection for /bin/ls
_
and then it hangs and eventually times out. It does the same if I
change
to binary mode and try a dir command.
This is becoming very frustrating...as it was working previously
without a problem.
Cheers,
Wayne
-Original Message-
From: Tiago Pierezan Camargo [mailto:[EMAIL PROTECTED]
Sent: Monday, October 20, 2003 6:58 PM
To: [EMAIL PROTECTED]
Cc: Wayne
Subject: Re: ftp proxy prob
I am a bit confused about your setup.. I guess your are talking
about a firewalled ftp server. Please, correct me if I am wrong..
#FTP rules
pass in quick log on $outside proto tcp from any to $ftp_server port {
20, 21 } keep state
pass out quick log on $outside proto tcp from $ftp_server port 1023
5000 to any flags S/SA keep state
(MS ftp uses ports 1023-5000 for passive ftp by default)
Humm.. IMO, the correct rule should be:
pass in quick log on $outside proto tcp from any to \
$ftp_server port 1023-5000 flags S/SA keep state
In a passive session, the remote party stabilishes the data
connection, so you have to change the rule direction. Take a look at
http://openbsd.org/faq/pf/ftp.html#natserver for more info.
I've now upgraded to 3.3, and I am still experiencing the same issue.
Aside from help with the above, does 3.3 need the ftp-reverse-proxy
patch?
Probably not.. I have a working ftp server behind a nat box.. :)
Tiago
--
Tiago Pierezan Camargo elessar at matrix dot com dot br
VI VI VI The editor of the beast.
Re: ftp proxy prob
When I look at my logs I see the initial incoming connection on port 21, and then a reply back to the client. The client can log in fine, and I get an ftp prompt ftp Doing a ftp dir command gets me 200 port command successful. 150 Opening ASCII mode data connection for /bin/ls Try to enter passive before the dir/ls. It seems that you are using active mode: 200 port command successful - hint! Tiago -- Tiago Pierezan Camargo elessar at matrix dot com dot br VI VI VI The editor of the beast.
Re: Passive FTP Proxy?
On Thu, Jul 10, 2003 at 10:44:10PM -0400, Jason Dixon wrote: Is there any way to ftp-proxy an outgoing passive ftp connection through a default block policy on the internal interface? yeah, i'm using the user proxy thing like this : === i=fxp1 e=fxp0 nat on $e from $i:network to !$i:network - ($e) rdr on $i inet proto tcp from $i:network to any port ftp - lo0 port ftp-proxy block return log all # so i don't borf my ssh into the firewall while pfutzing with this: pass in on $i inet proto tcp from $i:network to ($i) port ssh keep state # so i can still resolve names : pass in on $i inet proto udp from $i:network to ($i) port domain keep state pass out on $e inet proto udp from ($e) to any port domain keep state # to let ftp-proxy do its work : pass in on $i inet proto tcp from $i:network to lo0 port ftp-proxy keep state pass out on $e inet proto tcp from ($e) to any port ftp user proxy keep state # to allow output of 'ls' and whatnot to come back : pass in on $e inet proto tcp from any port ftp-data to ($e) user proxy keep state pass out on $i inet proto tcp from ($i) to $i:network user proxy keep state = so i suppose only the last two blocks would matter for you? btw, my ftp-proxy line in inetd.conf : 127.0.0.1:ftp-proxy stream tcp nowait root/usr/libexec/ftp-proxy ftp-proxy -m 52000 -M 55000 if i add the '-n' mode to it, i also need to add a pass rule that would allow connections in on the internal interface at seemingly any port, to the destination ftp server ( so, like, 'any', i guess ), at any port there too... as before i put that in, when i was testing this, i got a line in the logs looking like: Jul 13 01:40:20.759747 rule 0/0(match): block in on fxp1: \ 192.168.7.1.28283 66.133.130.13.14573: S 420171832:420171832(0) ( etc etc etc ) so it seems that both of those are below the userhi and userlow ports that you can set in sysctl 192.168.7.1 being an openbsd desktop PC; and the sysctl output on him says: net.inet.ip.porthifirst = 49152 net.inet.ip.porthilast = 65535 so, perhaps passive ftp doesn't care about that ( more clearly, the ftp client i was using ) so i'm just not worrying about the '-n' thing at the moment. but those four bottom pass rules in the pf.conf up there might be the money. jared -- [ openbsd 3.3 current/GENERIC ( jul 5 ) // i386 ]
ftp-proxy without inetd
Reposting here after not hearing anything on [EMAIL PROTECTED] [Original post 7/7/2003] With some goofing around this holiday weekend I was helping my oldest teenager with some things and we noticed that his windows machines where unable to ftp. ( Damn thjings do not support PASSV ). So went and looked at the man page and fouond that ftp-proxy still needs inetd to run. My firewall is a soekris running OpenBSD ( http://www.opensoekris.com) and the opensoekris needs no or has no inetd installed. So are there any plans to add this functionality to ftp-proxy.. I did find the tar.gz of what someone has done on the marc mailing list archives (http://marc.theaimsgroup.com/?l=openbsd-miscm=104387606807393w=2) but would like something in tree if possible. -Ron -- -- Ron Rosson... and a UNIX user said ... The InSaNe Onerm -rf * [EMAIL PROTECTED]and all was /dev/null and *void() --
ftp-proxy-reverse.diff
Does anyone know if the ftp-proxy-reverse.diff patch has been committed yet? I installed a new box with 3.2 today to move my PF to and when I run patch -p0 ftp-proxy-reverse.diff It prompts for what file to patch. Last time I ran this it did it all without further intervention. I am running it out of /usr/src Thanks, Wayne
Re: Passive FTP Proxy?
On Thursday, Jul 10, 2003, at 19:44 US/Pacific, Jason Dixon wrote: Is there any way to ftp-proxy an outgoing passive ftp connection through a default block policy on the internal interface? The man page suggests that if you don't use -n, ftp-proxy will proxy passive connections. You could filter based on ftp-proxy's user account then. I haven't tried this.
ftp-proxy without nat
I'm running PF as a routing firewall without NAT. Unless I'm mistaken, ftp-proxy should work in either direction without having the reverse patch in this situation. Am I wrong in this assumption? It works fine for local ftp clients, but I can't seem to get it to work in the other direction.
Re: ftp-proxy without nat - fixed
Nevermind, I got it. Had to add some rules to pass traffic from the external interface to 127.0.0.1 On Mon, 2003-06-09 at 13:22, Nick Lomonte wrote: I'm running PF as a routing firewall without NAT. Unless I'm mistaken, ftp-proxy should work in either direction without having the reverse patch in this situation. Am I wrong in this assumption? It works fine for local ftp clients, but I can't seem to get it to work in the other direction.
ftp-proxy
Hi, I need to enable ftp in the following to machines across a PF box doing NAT but cant get my head around it at all :-( 130.177.x.x 10.25.x.x public network private network ftp server (10.25.10.10) I want people on the private network (130.177.x.x) to be able to ftp to the ftp server on 10.25.10.10 I guess I need to set up ftp-proxy for this ? I enabled ftp-proxy in inetd running on port 8081 and added the rdr rule from any to any as per the man page but I cant seem to get a data connection established, I can log in authenticate via ftp and when I do an ls it breaks Im sure im missing something realy obvious can someone point it out to me please ? Regards Dan
Re: ftp-proxy reverse question
On Wed, Jan 15, 2003 at 04:03:31PM -0700, Ken Gunderson wrote: Anyhow, I patched ftp-proxy for reverse and have it up and running. Question is, how robust is this? (am wondering why it was not merged into 3.2). Can anyone comment on security/performance comparison between ftp-proxy reverse and alternative solutions such as jftpgw? I haven't used jftpgw myself, but it serves about the same purpose, I'd say. It also supports sftp, which ftp-proxy doesn't. $ wc -l /usr/ports/net/jftpgw/w-*/jftpgw*/*.c 9531 total $ wc -l /usr/libexec/ftp-proxy/*.c 1909 total Having carefully read ftp-proxy but not jftpgw, I trust ftp-proxy more. That is not to imply that jftpgw is insecure, I just haven't studied it. jftpgw has its own access controls, ftp-proxy doesn't. I'd rather have my pf.conf do that, myself. jftpgw by default blocks data connections to reserved ports, ftp-proxy doesn't. So if your internal ftp server can be tricked into asking the client to connect to a reserved port for a passive data connection, ftp-proxy will allow that. If there are vulnerable services running on the ftp server, you'd have to block connections to them with pf (on the internal interface). Otherwise the two are similar. With either proxy, you should only allow the proxy to establish connections that are expected and needed, blocking by default using pf. As to why the reverse proxy patch is not in the tree, ask beck@. If he doesn't reply, there's your answer :) Daniel
Re: ftp-proxy reverse question
On Thu, Jan 16, 2003 at 12:08:04PM +0100, Daniel Hartmeier wrote: On Wed, Jan 15, 2003 at 04:03:31PM -0700, Ken Gunderson wrote: Anyhow, I patched ftp-proxy for reverse and have it up and running. Question is, how robust is this? (am wondering why it was not merged into 3.2). Can anyone comment on security/performance comparison between ftp-proxy reverse and alternative solutions such as jftpgw? I haven't used jftpgw myself, but it serves about the same purpose, I'd say. It also supports sftp, which ftp-proxy doesn't. pureftpd has the required feature to use the external address in-band. I use it here heavily, and I have checked the chunks of code I use (base and ldap-auth; didn't bother to check mysql auth and the other stuff I don't even compile in; I trust it. Well, as long as you don't use the virtual chroot stuff. Didn't check it, but that gives me a bad feeling. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: ftp-proxy reverse question
On Thursday 16 January 2003 04:51 am, Henning Brauer wrote: On Thu, Jan 16, 2003 at 12:08:04PM +0100, Daniel Hartmeier wrote: On Wed, Jan 15, 2003 at 04:03:31PM -0700, Ken Gunderson wrote: Anyhow, I patched ftp-proxy for reverse and have it up and running. Question is, how robust is this? (am wondering why it was not merged into 3.2). Can anyone comment on security/performance comparison between ftp-proxy reverse and alternative solutions such as jftpgw? I haven't used jftpgw myself, but it serves about the same purpose, I'd say. It also supports sftp, which ftp-proxy doesn't. pureftpd has the required feature to use the external address in-band. I use it here heavily, and I have checked the chunks of code I use (base and ldap-auth; didn't bother to check mysql auth and the other stuff I don't even compile in; I trust it. Well, as long as you don't use the virtual chroot stuff. Didn't check it, but that gives me a bad feeling. i've typically used proftp, but pure ftp was looking actractiveto me and i was planning to take it for a test drive. thanks for the recommendation. presently this guy's ftp server is still on windoze, and he doesn't know how/if to restrict ftp-data port range, so it looks like i may have to opt for jftpgw until we can get a unix server deployed. -- Regards, Ken Gunderson
ftp-proxy reverse question
Greetings: Thanks for the replies to my previous post. Normally I would have done more leg work before posting to a list, but I had a full plate and this was a freebie rapid deployment for a java developer who has contributed a lot to open source, sees the light, and is transitioning away from m$ platform. Anyhow, I patched ftp-proxy for reverse and have it up and running. Question is, how robust is this? (am wondering why it was not merged into 3.2). Can anyone comment on security/performance comparison between ftp-proxy reverse and alternative solutions such as jftpgw? Tia-- Ken
Re: FTP proxy problem to ipf host
On Sun, 5 Jan 2003, Seth Robertson wrote: This is using IP Filter: v3.4.31 (328) on OpenBSD 3.2 i386 I am using IPF to protect a workstation which both FTPs to remote hosts, and which itself is a FTP server. The firewall rules can for the purposes of this problem perhaps be reduced to: -- pass in quick proto tcp from any to any port = 21 keep state keep frags pass out quick proto tcp from any to any port = 21 keep state keep frags block return-rst in quick proto tcp from any to any block out quick proto tcp from any to any map rl0 0/0 - 0/0 proxy port 21 ftp/tcp -- (only interfaces rl0 and lo0 are defined) Thus no NATing is going on, and no packets are being allowed except involving ftp, and all ftp data connections will be denied unless permitted by the FTP proxy. Without the map rule, I cannot transfer data in either direction, using passive or active FTP, as expected. With the map rule, outgoing ftp works great (in either mode). It creates the expected state rules and life is wonderful (ipfstat output below). With the map rule, inbound ftp does not work (in either mode). Only the ftp control connection state entry is created, no data connection state entries are created for either PORT or PASV. The passive mode data connection gets a RST, the active mode gets a 425 Can't build data connection: No route to host. which I can only presume is the result of a RST on the reverse connection. I tried using bimap and rdr in place of map just for kicks, but I couldn't seem to get a valid syntax (can I ask for a update ipnat.5 manual page which gives the proxy BNF)? Sure, I could do things to allow outbound (PORT) data connections without much pain especially since it involves a privileged port, but I have little interest in allowing vast ranges of inbound ports to be open all of the time (which is why I switched to ipf from pf). I don't know how to realise this setup using IP Filter, but with PF is dead simple. As described in ftp-proxy(8) to let internal ftp connections through, use the following pf.conf rdr on $int_if proto tcp from any to any port 21 - 127.0.0.1 port 8021 pass in on $ext_if inet proto tcp from any to $ext_if user proxy keep state And in your inetd.conf 127.0.0.1:8021 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy Allowing connections to your internal ftp server is a bit tricky. You need a patch for ftp-proxy to do this: http://www.benzedrine.cx/ftp-proxy-reverse.diff http://marc.theaimsgroup.com/?l=openbsd-pfm=104092386711162w=2 describes how your configuration should look like. Of course you need to add the necessary rules to pf.conf to filter these incoming ftp connection, but this shouldn't be that difficult. And I don't understand the motivation for your switch to IP Filter: where do you need to allow vast ranges of inbound ports to be open all of the time? Are you referring to the pass in port 49151 rule? Of course this can be solved by using the pass in user proxy rule, as I described above. I think a lot of misinformation let you to an unnecessary switch to IP Filter. Next time just mail your problems to appropiate OpenBSD mailing list ([EMAIL PROTECTED]) or PF mailing list ([EMAIL PROTECTED]). Cheers, Dries -- Dries Schellekens email: [EMAIL PROTECTED]
ftp-proxy transparency
Hello, everybody! I wonder if I can make ftp-proxy(8) transparent for my internal clients. I have a SQUID proxy inside my network and I want it to make active FTP-connections to the world (instead of, default, passive). And SQUID refuses to accept the data connection from the ftp-proxy process, stating that the connection comes from an unexpected address (from the proxying machine, but not the target server). And it's not without reason, IMHO. Every other FTP client I've tried works, provided that they ignore the above simple fact. Is my wish legal? I just wish to be able to connect to more FTP servers from my SQUID proxy, knowing that it's much much more simple for server administrators to setup active mode FTP services. Respect, Michael.
Re: ftp-proxy transparency
On Sun, Dec 08, 2002 at 12:21:36AM +0600, Michael O. Boev wrote: I have a SQUID proxy inside my network and I want it to make active FTP-connections to the world (instead of, default, passive). And SQUID refuses to accept the data connection from the ftp-proxy process, stating that the connection comes from an unexpected address (from the proxying machine, but not the target server). And it's not without reason, IMHO. To make ftp-proxy transparent like that, the data connections would have to appear to come from the external ftp server. So pf would have to translate the source address of the data connection from ftp-proxy to the ftp client (squid, in your case). For that, ftp-proxy would have to either insert and remove a temporary nat rule on the internal interface for each data connection, or use something like 'embryionic states' (search the list archive for a discussion of that). Neither is currently implemented. But you can relax squid's checking of the source address of active data connections, using the 'ftp_sanitycheck' configuration option: ftp_sanitycheck, default: on For security and data integrity reasons Squid by default performs sanity checks of the addresses of FTP data connections ensure the data connection is to the requested server. If you need to allow FTP connections to servers using another IP address for the data connection then turn this off. Assuming that the firewall prevents external hosts from connecting to the squid box directly (not through ftp-proxy), I'd say it's safe to turn that check off. You could also patch the check to allow connections from either the expected server or the ftp-proxy address (src/ftp.c, grep for sanitycheck). Daniel
