[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [cobalt-users] What ports shouldn't be closed
- Subject: RE: [cobalt-users] What ports shouldn't be closed
- From: "E.B. Dreger" <eddy+public+spam@xxxxxxxxxxxxxxxxx>
- Date: Thu Feb 6 10:40:01 2003
- List-id: Mailing list for users to share thoughts on Sun Cobalt products. <cobalt-users.list.cobalt.com>
> Date: Thu, 6 Feb 2003 12:35:28 -0500
> From: BSmith
> Ftp 20/21 (TCP)
It's not quite this simple. FTP supports two modes -- passive
and active. What you suggested will break passive FTP, which one
MUST support; failure to allow passive FTP will break FTP access
for clients with properly-configured firewalls.
In active mode, a server accepts inbound 21/TCP connections. Any
such connection is used for control. Data is sent from 20/TCP to
a randomly-selected port on the client machine.
However, many users run firewalls. Accepting all traffic that
comes from 20/TCP is extremely foolish -- anyone can use a box to
which they have root access to create such a socket, thus
bypassing any TCP firewall rules. Oops.
The solution to this problem is passive mode. Rather than let
the server send 20/TCP --> ???/TCP, the server tells the client
"connect to me on this TCP port for your data"... the server then
creates a socket on some TCP port, and waits for the client to
connect to it. Assuming the client's firewall will pass any
outbound traffic (a bad idea, IMHO, but that's another topic), it
can connect to the FTP server in passive mode.
This presents another problem: On what additional ports must the
server listen for data connections? To open 1024:65535 would
allow passive FTP, but sort of defeats the purpose of having a
firewall. It would be nice to restrict the port range to, say,
12000:12999, and only allow those.
At least on newer versions, ProFTPD allows one to do just that.
Carefully select a port range for passive FTP. Configure ProFTPD
and ipchains accordingly. Again, FAILURE TO DO SO WILL BREAK FTP
ACCESS for clients with properly-configured firewalls.
This should be in the archives, but I suppose it doesn't hurt to
populate them a bit more. ;-)
It's a shame that applications use unregistered ports. If
developers had stuck to IANA-approved port numbers, we'd have
nice, tidy ranges of ports that could be filtered according to
simple policies. However, we're probably too far down the
slippery slope for this to happen. :-(
Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist@xxxxxxxxx>, or you are likely to
be blocked.