Odd FTP Problems

[Jason Joines]

David A. Bandel wrote:

>On Wed, 18 Jun 2003 17:01:36 -0500
>Jason Joines <joines at bus.okstate.edu> wrote:
>
>[snip]
>  
>
>>$ipchains -A input -s $anyhost -d $thishost 1024:65535 -p tcp -i eth0
>>! -y -j ACCEPT
>>
>>  The users have IE x.x on win2k.  I had one of them try to retrieve a
>>  
>>file via the win2k command line and that worked just fine.  So, I
>>tried Mozilla 1.4rc1 on my SuSE box.  Then I had the same problem as
>>the users and the log showed rejections from my box to arbitrary high
>>tcp ports on the server.
>>
>>  It looks like the ftp in the browser's is doing something odd.  The 
>>server is running wu-ftpd 2.60.
>>    
>>
>
>The FTP server isn't doing anything (odd or otherwise).
>Command line ftp uses active FTP (works).
>Browsers use passive FTP (doesn't work).
>
>I'll bet you can't use ncftp from a command line in passive mode either.
>
>Active FTP works by your client contacting the FTP server on port 21. 
>You log in.  Then, all requests for data (ls, get, but not cd) cause the
>server to open port 20 back to the client.
>
>In passive FTP, the server is told _not_ to do this, but to use port 21
>and a negotiated upper port (1024+) for the other half of the
>connection.  This is failing.  
>
>Take down your firewall, run tcpdump like this:
>tcpdump -ni eth0 host $otherhost
>(you can use either name or IP number for $otherhost)
>
>connect via IE and transfer something.  This will show you what's going
>on.
>put your firewall back in place and do this again.
>
>You haven't posted enough of your firewall to say where the problem is. 
>What is policy and rules for input and output?
>
>Also, if you really need a firewall, why use an ancient kernel? 
>IPTables really is worth the effort for the stateful matching.  If you
>want to go this route and need help, post here.
>
>Ciao,
>
>David A. Bandel
>

  Ah, I din't know what the difference in passive and active FTP was or 
that browsers behaved differently.

  The box has only one NIC and their is no masquerading going on.  The 
policies are DENY for INPUT and FORWARD and ACCEPT for OUTPUT.  There 
are no rules FORWARD or OUTPUT.
  The last rule in the INPUT chain is '$ipchains -A input -l -j DENY' so 
I log everything coming in that hasn't been explicity dealt with by an 
earlier rule.  That's how I could tell that the browsers were trying to 
connect on high ports, I just had no idea why.  The INPUT chain looks 
like this:

#*****************************************************************************#
# INPUT CHAIN 
****************************************************************#
#*****************************************************************************#
#
# Allow all internal connections (loopback)
$ipchains -A input -i lo -j ACCEPT
#
# Minimize logging of nuisance traffic
$ipchains -A input -d $allhosts -i eth0 -j DENY
$ipchains -A input -d $multicast -i eth0 -j DENY
$ipchains -A input -d $broadcast -i eth0 -j DENY
$ipchains -A input -d $thishost 137 -p udp -j DENY
#
# Allow ftp connections
$ipchains -A input -s $thislan -d $thishost 20 -p tcp -i eth0 -l -j ACCEPT
$ipchains -A input -s $thislan -d $thishost 21 -p tcp -i eth0 -l -j ACCEPT
#
# Allow telnet connections
$ipchains -A input -s $thislan -d $thishost 23 -p tcp -i eth0 -j ACCEPT
#
# Allow sendmail connections
$ipchains -A input -s $anyhost -d $thishost 25 -p tcp -i eth0 -j ACCEPT
#
# Allow apache connections
$ipchains -A input -s $thislan -d $thishost 80 -p tcp -i eth0 -j ACCEPT
#
# Allow samba connections
$ipchains -A input -s $thislan -d $thishost 139 -p tcp -i eth0 -j ACCEPT
#
# Allow replies to queries from external hosts
#
$ipchains -A input -s $anyhost -d $thishost 1024:65535 -p tcp -i eth0 ! 
-y -j ACCEPT
$ipchains -A input -s $anyhost -d $thishost 1024:65535 -p udp -i eth0 -j 
ACCEPT
#
# Catch all and log it
$ipchains -A input -l -j DENY

  When the browser's connect you'll get a sequence like this in the log:
Jun 19 20:08:48 kernel: Packet log: input ACCEPT eth0 PROTO=6 
172.16.0.31:40551 172.16.0.105:21 L=58 S=0x10 I=36665 F=0x4000 T=64 (#6)
Jun 19 20:08:48 kernel: Packet log: input DENY eth0 PROTO=6 
172.16.0.31:40552 172.16.0.105:5345 L=60 S=0x00 I=36666 F=0x4000 T=64 
SYN (#37)
so it seems the firewall is doing just what it's supposed to do.

  The whole box is slated to go away with a replacement application 
running one our 11 kernel 2.4.x boxes.  All of them run iptables 
firewalls and I would love to have that option.  Unfortunately, it's way 
down the priority list of the app/dev guys.  I was just tasked with 
securing the "as-is" system as much as possible in the meantime.  The 
person who originally put it up went way out of their way to make it as 
insecure as possible, no firewall, unencrypted smb passwords, mysql open 
to the world with a blank password for root, ..., the list goes on and 
on.  I can't wait to get rid of this thing.

  Thanks for the help.

Jason
===========