Re: ssh and port 22 problem, cont.

From: James Wilkinson (james_at_westexe.demon.co.uk)
Date: 10/06/04

  • Next message: Yang Xiao: "Re: Name Servers"
    Date: Wed, 6 Oct 2004 13:54:39 +0100
    To: fedora-list@redhat.com
    
    

    Gerhard Magnus wrote:
    > Shouldn't ssh be here? And what's telnet doing open? The books have me
    > scared to death of this... hackers, crackers, script kiddies, etc.

    Um.

    First of all, let me say that it's a bad idea to have any un-necessary
    services open to the Internet. It gives crackers more targets: you only
    need one service to have a vulnerability and you're vulnerable.

    In practice, unless you've got a badly written daemon, one more port is
    not going to make much of a difference.

    But unless you actually *use* them, an open telnet port is no more
    insecure than an open ssh port (as Fedora ships it).

    SSH has a number of security advantages:
     * you can use per-user authorized keys, not passwords.

     * data is sent encrypted, not in plain text.

     * users have some assurance that they're connecting to the server they
       want to connect to (and not a man-in-the-middle attack).

    There are others but, like the last two points above, they're only of
    any use when legitimate users connect. If you don't actually make any
    connections, then no data of any kind (that you care about) flows, and
    you don't care whether it's encrypted or not. Likewise, if you don't
    connect to a server, it's kind of moot whether it's the right one or
    not!

    So what about the first one? You can turn password authentication off
    with SSH servers, which means that only users who configure personal
    keys can connect. If no-one is using SSH, then the chance is there
    aren't any keys configured, keeping everyone out.

    If password authentication is turned on, then an attacker is reduced to
    looking for vulnerabilities or brute-forcing passwords. You can try
    those with either server, but Fedora will limit the speed at which
    connections can be tried, and this limit is what stops it being
    practical.

    So the difference effectively boils down to which server is more likely
    to have vulnerabilities. The OpenSSH team is *extremely* good, but there
    have been vulnerabilities in the past, and the server has to be more
    complex than a telnet daemon.

    (You've had good advice for the rest of your problem...)

    James.

    -- 
    E-mail address: james | "During the shutdown period I received not one
    @westexe.demon.co.uk  | single support call, confirming my theory that my
                          | network is indeed perfect, and that all faults are
                          | user-inflicted."
    -- 
    fedora-list mailing list
    fedora-list@redhat.com
    To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
    

  • Next message: Yang Xiao: "Re: Name Servers"

    Relevant Pages

    • Kermit is good, Telnet and FTP are not bad was Re: network sniffing question
      ... >> well actually I've been always using SSH myself and all my servers use ssh. ... >> the system as root using telnet is a bad idea. ... >> I'm just trying to convice this guy that kermit and korn shell and telnet ... secure connectivity to your Telnet server. ...
      (comp.os.linux.security)
    • Re: [Full-Disclosure] Re: Re: open telnet port
      ... I don't have a backup user called test. ... that keeping another way (than ssh) into the server ... could be a valid argument for keeping a telnet running. ...
      (Full-Disclosure)
    • Re: Securing Linux
      ... >> no one gets to lift your doormat, or tap that unencrypted telnet ... Telnet has had its own buffer overflow vulnerabilities as ... > version of ssh installed older than the one released a month or so ago ... Security is never an absolute thing; ...
      (comp.os.linux.security)
    • Re: [SLE] Stillcant ssh or telnet
      ... Web Server, Telnet Server, and the SSH Server included in the Firewall ...
      (SuSE)
    • Re: [SLE] Stillcant ssh or telnet
      ... Web Server, Telnet Server, and the SSH Server included in the Firewall ... The Apache web server is running ok but the remote location ...
      (SuSE)