From owner-freebsd-security Thu Jun 14 10:24:53 2001
Delivered-To: freebsd-security@freebsd.org
Received: from nsmail.corp.globalstar.com (gibraltar.globalstar.com [207.88.248.142])
by hub.freebsd.org (Postfix) with ESMTP id 702B837B401
for <freebsd-security@FreeBSD.ORG>; Thu, 14 Jun 2001 10:24:47 -0700 (PDT)
(envelope-from crist.clark@globalstar.com)
Received: from globalstar.com ([207.88.153.184]) by
nsmail.corp.globalstar.com (Netscape Messaging Server 4.15) with
ESMTP id GEXKCM00.35O; Thu, 14 Jun 2001 10:24:22 -0700
Message-ID: <3B28F35D.F9B0BA04@globalstar.com>
Date: Thu, 14 Jun 2001 10:24:45 -0700
From: "Crist Clark" <crist.clark@globalstar.com>
Organization: Globalstar LP
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Marcel Dijk <nascar24@home.nl>
Cc: Evren Yurtesen <yurtesen@ispro.net.tr>,
"Antoine Beaupre (LMC)" <Antoine.Beaupre@ericsson.ca>,
"Thomas T. Veldhouse" <veldy@veldy.net>,
Jason DiCioccio <Jason.DiCioccio@Epylon.com>,
freebsd-security@FreeBSD.ORG
Subject: Re: IPFW almost works now -> stateful rules
References: <Pine.BSF.4.33.0106130001350.63354-100000@finland.ispro.net.tr> <3B2698EF.BD7EF0DB@globalstar.com> <02a201c0f415$4dad56b0$0900a8c0@windows> <3B27D344.82AEDED0@globalstar.com> <03da01c0f454$313b3d50$0900a8c0@windows> <3B27EAB5.3FE48A6C@globalstar.com> <046b01c0f4e8$a32a9200$0900a8c0@windows>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-security.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-security>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-security>
X-Loop: FreeBSD.org
Marcel Dijk wrote:
>
> > OK, we got your control connection some AIM traffic and IPX, all with
> > some hideous auto-line-wrapping, but there looks to be a data connection
> > problem in there too.
> >
> > [snip, format recovered]
> >
> > > 23:52:18.020112 MY_IP.ftp-data > qn-213-73-145-189.quicknet.nl.1626: S
> 1812366928:1812366928(0) win 16384 <mss 1460> (DF) [tos 0x8]
> > > 23:52:18.065074 qn-213-73-145-189.quicknet.nl.1626 > MY_IP.ftp-data: R
> 1812366928:1812366928(0) ack 1812366929 win 16384 <mss 1460> (DF) [tos 0x8]
> >
> > [snip]
> >
> > The client, qn-213-73-145-189.quicknet.nl, is rejecting the incoming
> > data connection attempt. This looks like a failed PORT (active FTP)
> > attempt where we have a _client_ problem, not a problem at your FTP
> > server.
>
> But no matter what FTP client I use, I get the 'can't build data connection'
> error. For example if I try to connect with putty to my FTP server I get
> this message:
>
> 220 FreeBSD FTP server (Version 6.00LS) ready.
> 331 Password required for USER.
> 230 User USER logged in.
> 425 Can't build data connection: Connection refused.
>
> I think it has something to do with the rules because on the local LAN
> everything works fine.
>
> I now have used stateful rules as sugested by someone here.
That keep-state does not do anything for you. You have broken your
loopback also.
> These are my rules:
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> add 150 divert 8668 all from any to any via ed0
> add 400 deny ip from 127.0.0.0/8 to any
>
> add 600 allow tcp from MY_IP to any out via ed0
>
> add 602 check-state
> add 603 allow log tcp from any to MY_IP 22,5617,10000 in setup keep-state
> add 635 allow udp from any to MY_IP in via ed0
> add 645 allow udp from MY_IP to any out via ed0
> add 650 allow log icmp from any to MY_IP in via ed0
> add 660 allow log icmp from MY_IP to any out via ed0
>
> add 800 allow all from 192.168.0.0/16 to any
> add 825 allow all from any to 192.168.0.0/16
>
> #add 850 allow tcp from 192.168.0.0/16 to any
> #add 860 allow tcp from any to 192.168.0.0/16 22,5617,10000
> #add 870 allow udp from any to 192.168.0.0/16
> #add 880 allow udp from 192.168.0.0/16 to any
> #add 890 allow icmp from any to 192.168.0.0/16
> #add 895 allow icmp from 192.169.0.0/16 to any
>
> add 1000 deny log logamount 10 all from any to any in frag
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OK, comparing your tcpdump(8) to your firewall rules, I notice
the tcpdump says you are using port 'ftp.' Did you edit /etc/services?
I don't see ftp being passed and I thought you were using a
non-standard port for FTP.
The problem with active FTP: Your machine can send packets out to
a client via rule 600, but the responses from the client will
be dropped since there is no rule passing the responses. _That_
is where you would want a 'keep-state,' in rule 600, not 603.
The problem with passive FTP: Your machine will never allow in
the connection attempts from a client.
Here is what I would do,
# Pass loopback traffic
add 100 allow ip from any to any via lo0
# Protect loopback address
add 200 deny ip from 127.0.0.0/8 to any
add 300 deny ip from any to 127.0.0.0/8
# Block spoofs
add 400 deny ip from MY_IP to any in via ed0
# Check dynamic rules
add 400 check-state
# Make dynamic entries for all outgoing traffic
add 500 allow tcp from MY_IP to any keep-state out via ed0
add 600 allow udp from MY_IP to any keep-state out via ed0
# Just pass ICMP
add 700 allow icmp from MY_IP to any out via ed0
# Allow ping replies and requests, and various error messages
add 800 allow icmp from any to MY_IP in via ed0 icmptypes 0,3,8,11,12
# Pass everything on private LAN (do we have another interface?
# Otherwise, these rules are dangerous)
add 1000 allow ip from 192.168.0.0/16 to any
add 1100 allow ip from any to 192.168.0.0/16
# Log the rejects that have fallen through
add 65000 deny log ip from any to any
--
Crist J. Clark Network Security Engineer
crist.clark@globalstar.com Globalstar, L.P.
(408) 933-4387 FAX: (408) 933-4926
The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above. If
the reader of this e-mail is not the intended recipient, or the employee
or agent responsible to deliver it to the intended recipient, you are
hereby notified that any review, dissemination, distribution or copying
of this communication is strictly prohibited. If you have received this
e-mail in error, please contact postmaster@globalstar.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message