On Wed, 18 Jun 2003 17:01:36 -0500 Jason Joines <[EMAIL PROTECTED]> 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 ===========
_______________________________________________ Linux-users mailing list [EMAIL PROTECTED] Unsubscribe/Suspend/Etc -> http://www.linux-sxs.org/mailman/listinfo/linux-users
