Date: Thu, 15 Nov 2001 17:56:17 -0600 From: David Kelly <dkelly@hiwaay.net> To: Thor Legvold <tlegvold@hotmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: ipfw/natd & ftp Message-ID: <20011115175617.B49991@grumpy.dyndns.org> In-Reply-To: <F104WfiyWxZAeSQVSZe00016ba1@hotmail.com>; from tlegvold@hotmail.com on Thu, Nov 15, 2001 at 10:15:03PM %2B0000 References: <F104WfiyWxZAeSQVSZe00016ba1@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 15, 2001 at 10:15:03PM +0000, Thor Legvold wrote:
>
> Well, When I zero the values, after a few short seconds the values already
> are growing rapidly. I have the entire house wired UTP, so there's some
> other ppl on the LAN as well (not just me), making it a bit more difficult
> to debug.
A simple way to deal with that would be to insert an identical rule just
in front of the interesting spots but only the new rule logs and is
modified to special case for the inside machine you are testing with.
> >"deny" rules so that "log" is also in effect. Then when a "deny" >blocks
> >something an instant later you can see it with "tail -f
> >/var/log/security" which you had running all along.
>
> I'll give it a try. I appreciate your help, could you explain why ftp still
> doesn't work when the firewall is completely open? Why it works from the
> FBSD box but none of the client machines? This seems strange to me, and
> seems like the firewall isn't the actual problem, but I'm just thinking
> aloud.
In /etc/login.conf an environment variable is set to default most
FreeBSD ftp clients to passive mode. Your upstream ISP is doing NAT on
you and you are doing NAT on your inside users? Of what I remember of
your ipfw rules non-passive ftp is the only thing which stands a chance
of getting out unless its handled somehow in the natd config. But you
didn't have provisions for the initial non-passive ftp connect.
Am guessing your inside machines are trying non-passive ftp.
> > > >For passive to work you have to allow out most all connections
> >originating
> > > >inside.
> > >
> > > I have that - allow all established
> >
> >Not the same thing. For passive ftp to work you have to allow all
> >*connections* out. The "setup" stage. Once past setup then >"established"
> >rule above takes over.
>
> ok. back to the docs...
>
> >Here is where your rules get interesting:
>
> As you can see, I've "borrowed" & modified them from someone else.
Looks like we borrowed from the same place as I have the exact same
comments in many places.
> > > ### TCP RULES
> > >
> > > # HTTP - Allow access to our web server
> > > # ${fwcmd} add pass tcp from any to any 80 setup
> > >
> > > # SMTP - Allow access to sendmail for incoming e-mail
> > > # ${fwcmd} add pass tcp from any to any 25 setup
> > >
> > > # FTP - Allow incoming data channel for outgoing connections,
> > > # reject & log all incoming control connections
> > > ${fwcmd} add pass tcp from any 20 to any 1024-65535 setup
> > > ${fwcmd} add deny log tcp from any to any 21 in via ${oif} setup
>
> Where can I get more info about the different protocols & layers? It's been
> a *long* time since I last worked with networking and I suppose I should
> brush up on UDP/TCP/GRE and all this other stuff in order to better
> understand and tweak my ruleset.
Most of what I know comes from FreeBSD's man pages and when an RFC is
mentioned I dig it up on the net. Sometimes I actually understand a bit
of what the RFC says.
FTP is about the hardest thing to deal with in a firewall. IRC and
instant message clients are just about as hard. All because they
establish a simple connection to a known port but then follow up over
that connection and decide to open another port pair. That's what
punch_fw does in natd, watches the known port connection for negotiation
of the data link port pairs then inserts the NAT rule into itself
internally and externally writes suitable rules into ipfw.
> >The above only deals with incoming ftp.
>
> ok.
>
> > > # SSH Login - Allow & Log all incoming
> > > ${fwcmd} add pass log tcp from any to any 22 in via ${oif} setup
> > >
> > > # IDENT - Reset incoming connections
> > > ${fwcmd} add reset tcp from any to any 113 in via ${oif} setup
> > >
> > > # Reject&Log all setup of incoming connections from the outside
> > > ${fwcmd} add deny log tcp from any to any in via ${oif} setup
> >
> >Oh, my. Below is a catch-all letting everything thru not explicitly
> >denied before this rule. However this is the sort of thing passive >ftp
> >requires. I'd add "log" to this, at least until you get things working.
>
> I'll do that. So, even though this is "bad", but just the thing needed for
> passive ftp, why isn't it working?
Is not quite as bad as I make it sound. Internal users who want to
bypass your firewall could tunnel ssh over port 80 or 23 or 25 or 443
or ... Meaning if they want out they can get out. By blocking unknown
ports, or known unwanted ports, you really only protect your connection
against your stupid users and the stupid spyware makers. To lock things
down hard you would need a firewall which understands the contents of
each link and bases its action on that.
If a machine can not get out which is supposed to then 1) either the
packets are not getting to the gateway, or 2) the gateway is blocking
said packets, or 3) said packets are not getting back to the correct
system on the return.
natd has a "same ports" option. If you are not already using that then
try adding it. Have to kill and restart natd for any changes to take
effect.
> Where should I be looking when the dual
> homed host can ftp through the firewall, while none of the clients can get
> out, even when the firewall is opened up? I can open an ftp session, log in
> successfully, but cannot do a dir/ls or get any files.
That's the classic symptom of non-passive ftp breaking trying to get
thru NAT. It opened the initial connection from inside to out. Then
when you wanted data over that connection the client and server
discussed what additional port pairs to use. Non-passive ftp the
*server* opens the return link to the client to a port the client pulled
out of the barrell just a moment before and used the first link to tell
the server what to use. For passive ftp the server creates a new port
first and uses the first link to tell the client who opens the link then
the server pushes the requested data down the new link.
I think we are trying to fix your firewall with the problem is on the
client. Make sure you have passive ftp on the inside client. If you log
all outgoing connections from that host (on the ipfw "setup") then
you'll have an easy way to sniff the net to see what is happening. If
passive you will see another connection originate from inside when you
try to DIR over ftp. If non-passive then you might see a connection
attempt from outside but as I understand there is another NAT upstream
so this outside connect (setup) will probably be dropped.
> Windows is pretty new (XP), it's ftp isn't any better (although I always
> suspect MS stuff of being broken anyway when things don't work ;-)
IE's ftp appears to me to be passive-only on windows but adaptable on
MacOS.
> > > # Allow setup of any other TCP connection
> > > ${fwcmd} add pass tcp from any to any setup
>
> I'll want to change this to deny when I have everything configured
> correctly, I suppose...
No, I think this is the only way you are going to get ftp out. Punch_fw
says it can create passive rules but it hasn't worked for me.
--
David Kelly N4HHE, dkelly@hiwaay.net
=====================================================================
The human mind ordinarily operates at only ten percent of its
capacity -- the rest is overhead for the operating system.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011115175617.B49991>