Re: I've thought better of Linux


Tim X <timx@xxxxxxxxxxxxxxxxx> writes:

> Greg Menke <gregm-xyzpdq@xxxxxxxxxxxx> writes:
>
> > Tim X <timx@xxxxxxxxxxxxxxxxx> writes:
> >
> > > Greg Menke <gregm-xyzpdq@xxxxxxxxxxxx> writes:
> > > The FTP protocol specification does seem overly complex in today's
> > > world of high speed connections and fast servers. However, if you put
> > > it in context with the time it was defined - in a world of slow and
> > > less reliable networks, slow cpus and little security concerns, it
> > > sort of makes sense.
> >
> > The big complicated horribleness of FTP isn't related to IO speeds, but
> > is more associated with its built-in conversion features that attempt to
> > correctly transfer datasets between systems with very different concepts
> > of what files are- blocks here, bytes there, different coding etc.. Now
> > that we have a nearly monocultural concept of filesystems, all those
> > conversion features are pretty much vestigal.
> >
>
> hmmm, why is this voice in my head saying "pathnames" right now?

I couldn't say. Perhaps its time to experiment with a hat made of
aluminum foil? ;)

> >
> > Its bad because the command/data protocols occur over multiple TCP
> > connections that are set up in different directions, which are not well
> > suited to modern firewalled networks. Authentication happens in plain
> > text, its also difficult- or at least subtle to secure. Its popularity
> > is due to its ubiquity and a very minimally conformant implementation
> > will pretty much work on very similar architectures.
>
> Yes, that is a royal pain, but in context, the firewall and security
> issue was barely even considered back when the ftp protocol was
> defined - back then, it was still a community cnsidered to be made up
> pretty much of trusted techies

True, so I guess I'd put the difficult to secure aspect in as a 2nd
order issue. OTOH, plaintext authentication is certainly a problem from
day 1. If you're going to authenticate, then there must be provision
for doing better than that.

> > We don't allow telnet, ftp or any of the r* tools to traverse the
> > routers on our enterprise networks- terminal and file transfer
> > activities are ssh-based or nothing, and our network isn't on the
> > security bleeding edge, so I'd say ftp is pretty well gone as far as
> > we're concerned.
> >
> Oh how I envy your position. We keep trying to do this, but keep
> having to "soften" our stance because of "critical business needs". In
> the main, its still bloody Windows applicaitons which still rely on
> telnet/ftp/rsh type protocols. All the Unix/Linux apps we run are fine
> and have decent "security awareness". However, many of the windows
> apps seem to use DLLs which provide telnet or ftp type protocol
> support, but not ssh/ssl/tls etc. When we contact the vendors and ask
> them to provide secure comms channels in their software, they sort of
> go silent and then ask something like "what do you mean".

Too true. Thankfully the "advanced business software" which can't
handle crypto and insists on incomplete or partially secured
infrastructure can be dumped behind a firewall. But then there are the
wankers who really MUST export their broken-ass protocols...


> In fact, I can almost guess what sort of developer and what platform
> whenver they ask to access our network to help track down a
> problem. The Unix/Linux ones generally ask for VPN access or at least
> ssh. The windows developers usually ask for telnet and then for
> instructions on how to setup putty!

I think my Windows users are similar to yours. I have been fortunate
enough for the moment to give a resounding NO to the ftp and telnet
question. Watching Windows people dink around with notepad and telnet
is good for a laugh though- they're IT Knowledge Workers... wheee!

> Meanwhile, I have constant arguments with management - I'm responsible
> for ensuring data security and integrity, but then get forced to open
> up firewalls etc to allow insecure applications because they are
> "business critical". Consequently, I'm considered by them to be a tech
> head with no real understanding of business and the real world and I
> consider them to be unthinking fools who think Gartner is god!

Gah.. well its got to be that or some UML idiot...

Gregm
.

Relevant Pages

  • Re: Ive thought better of Linux
    ... OTOH the ftp spec is a royal PITA. ... >> The FTP protocol specification does seem overly complex in today's ... Yes, that is a royal pain, but in context, the firewall and security ...
    (comp.lang.lisp)
  • ftp / telnet problems: connection refused
    ... telnet access from a remote (windows) machine no longer work. ... For ftp I ... no problem using the solaris ftp client to access remote machines, ...
    (comp.unix.solaris)
  • RE: Winnt/Win2k Vuln ?
    ... specifying the underlying protocol, ... expect file system requests to be carried over the web. ... And you should need a separate client for FTP. ... A web BROWSER, also by definition, BROWSES the web. ...
    (Vuln-Dev)
  • Re: [Full-disclosure] Security issue in Filezilla 3.0.9.2:passwords are stored in plain text (si
    ... clients such as the OpenSSH.com groups proactive secure Secure FTP ... Right, except that SFTP isn't the RFC959 protocol that lives on ports 20/21, ... it's an entirely different protocol layered on top of the OpenSSH on port 22. ... The argument field is a Telnet string specifying the user's ...
    (Full-Disclosure)
  • RE: Restricting SSH in windows
    ... I don't think you'll find a solution in windows for what you're looking ... In an effort to restrict the vendor's access to our network ... is allowed to execute (in this case only ftp and telnet). ...
    (Security-Basics)