Thorbjørn Ravn Andersen wrote:
> Glenn Møller-Holst <nomail@xx.dk> writes:
>
>> Brug i stedet Mac OS X indbyggede sftp-server:
>
> ....
>
>> Preferences) FTP Server (enable FTP Access) and SFTP Server (enable
>> Remote Access)..."
>
> <pernittengryn>
> Remote Access er ssh-adgang, denne kan så understøtte en ftp-lignende
> tingest som kaldes sftp, og som er ganske praktisk.
> </pernittengryn>
>
> Til hobbybrug er ftp udmærket.
Hej Thorbjørn
Her er mere argumentation, til det gamle indlæg, om at det ikke kan
anbefales at anvende ftp. Selv til hobbybrug.
Argumenterne er bl.a. sikkerhed for alle mellemliggende firewalls mellem
klient og server - udover selve klient og server programmernes sikkerhed.
Herudover er der også passiv/aktiv ftp valget hvor det anbefales at
anvende passiv, hvis man absolut skal anvende ftp alligevel. Faktisk er
der mange klienter hvor ftp-passiv/aktiv mulighedens betydning som var
byttet rundt. Det har jeg oplevet på mindst to klienter:
That sad old FTP thing:
http://home.nuug.no/~peter/pf/en/ftpproblem.html
Citat: "...
The short list of real life TCP ports we looked at a few moments back
contained, among other things, FTP. FTP is a sad old thing and a problem
child, emphatically so for anyone trying to combine FTP and firewalls.
FTP is an old and weird protocol, with a lot to not like. The most
common points against it, are
* Passwords are transferred in the clear
* The protocol demands the use of at least two TCP connections
(control and data) on separate ports
* When a session is established, data is communicated via ports
selected at random
All of these points make for challenges security-wise, even before
considering any potential weaknesses in client or server software which
may lead to security issues. These things have *tended* to happen.
Under any circumstances, other more modern and more secure options for
file transfer exist, such as sftp or scp, which feature both
authentication and data transfer via encrypted connections. Competent IT
professionals should have a preference for some other form of file
transfer than FTP.
...."
-
CERT® Coordination Center:
http://www.cert.org/tech_tips/ftp_port_attacks.html
Citat: "...
The site uses good security practice by separating the machines that
provide these external services from those that perform internal
services. It is important to have strong network boundaries (preferably
using firewalls)
....
Sites using dynamic packet filtering firewalls may need to take
additional steps to ensure that third-party PORT commands are blocked by
the firewall. If you need to address this problem, we encourage you to
check with your vendor to determine the steps you should take.
...."
-
DMZ or not ?:
http://honor.trusecure.com/pipermail/firewall-wizards/1999-October/006561.html
Citat: "...If you operate [f.eks. et FTP-server] in between the router
and the firewall, you *lose* the *stateful* *inspection* capabilities of
your firewall. You also *lose* some other *protection* like syn
flooding detection and prevention..."
-
Active FTP vs. Passive FTP, a Definitive Explanation:
http://www.slacksite.com/other/ftp.html
Et stykke nede:
What is the difference between Active and Passive FTP?:
http://www.scala.com/network-manager-3-faq/network-manager-3-faq-index.html
Citat: "...That's the specific problem that passive FTP is designed to
solve, however it does I believe complicate the firewall issues on the
server end..."
-
Problems with the FTP protocol:
http://www.seifried.org/security/network/20010926-ftp-protocol.html
Citat: "...
Currently vsftpd (Very Secure FTPD) is the only ftp server I know of
specifically designed with security as it's main goal.
....
Kurt: What do you think of FTP in general?
H D Moore: To be plain, FTP sucks
....
For a secure transfer protocol, I recommend scp, part of the OpenSSH
package. There are FREE windows clients available, as well as
Full-Featured GUI applications by companies like F-Secure. SCP does
incur an encryption overhead, but for most cases it is fast enough.
...."
Det er ikke kun Kurt der har denne holdning:
Firewall Configuration Prerequisites.
By Jay Beale, Lead Developer, Bastille Linux Project
(jay@bastille-linux.org), Principal Consultant JJB Security Consulting
and Training (C) 2000, Jay Beale:
http://web.archive.org/web/20070702235227/www.bastille-linux.org/jay/firewall-prereqs.html
Citat: "...
Well, there's a partial solution to this, in that you can force
everyone's clients to use "passive" mode FTP, which works like this:
....
So, this is more normal. The client is opening that second connection,
albeit to an arbitrary high (1024-65535) port on the server. *This is
better, though it now opens the server up to greater risk. See, now the
firewall on the server end has to allow all connections to high ports on
the FTP server machines*. Now, a knowledgeable admin can reduce this
port range, from 1024-65535, to something more manageable like
40,000-45,000, but this still leaves a wide port range that has to be
allowed in the server-side firewall. So, is there any hope?
Well, barring killing off FTP, there is. Stateful firewalls can watch
the data stream and understand the port negotiation. Unlike non-stateful
firewalls, which have to allow every potential port, stateful firewalls
can allow through packets destined for the specific additional data
port, at the specific "right time" in the connection.
...."
-
http://www.outpostfirewall.com/guide/rules/preset_rules/ftp.htm
Citat: "...
Protocol: TCP
Direction: Inbound
Local Port(s): 1024-65535
Action: Allow It
Protocol: TCP
Direction:Outbound
Remote Port(s): 1024-65535
Action: Allow It
....
But wait a minute! Doesn't this cause all kinds of problems [
*Sikkerhedsproblemer* ! ] for the server side firewall? [Dén foran
FTP-serveren]
Yes it does, but servers have away round this. Most FTP servers allow a
server administrator to specify a range of local ports [Det er en ussel
men halvgod løsning] the FTP server is allowed to open and use.
...."
hilsen
Glenn