Password scan - Security

This is a discussion on Password scan - Security ; Hi everyone! I am not that experienced with Linux security problems and how to deal with them, and I am encountering some problems that I don't know very well how to deal with. Maybe some more experienced people could help ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Password scan

  1. Password scan

    Hi everyone! I am not that experienced with Linux security problems and
    how to deal with them, and I am encountering some problems that I don't
    know very well how to deal with. Maybe some more experienced people
    could help me with an advice.
    What's happening? After running the "lastb" commands, I can see a lot
    of failed attempts to login into my Linux server - it just goes on
    every night, from different IP addresses. Here is a sample of what the
    "lastb" command shows:

    gem ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    ansel ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    ansel ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    weaken ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    weaken ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    sne ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    sne ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    relf ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    relf ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    mi ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    mi ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    linss ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    linss ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    jean ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    jean ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00)
    hansen ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    (00:00) .

    Fortunately, it seems there has not been any successful attempt, as the
    "last" command shows nothing suspicious, only the expected connections
    from the trusted hosts. But I am still worried that somebody might find
    a way to break in eventually, because this kind of password scanning
    goes on continuosly. What I did was just disable login from all user
    accounts different than root, by means of the sshd_config file, and
    made sure the root password is strong enough. Is there anything else I
    should do in this situation? What about trying to follow up on the IP
    addresses appearing inside the log, to see where the aggressors are
    coming from? Is there any way I can take action against this
    unauthorized scanning of my machine? Or maybe the IP addresses are fake
    and the attack comes actually from somewhere else?
    Please let me know what you think about this situation, so that I
    could have a better idea about how to improve the security of my Linux
    server.

    Thank you,
    Christian Sava


  2. Re: Password scan

    "christian_sava" writes:

    >Hi everyone! I am not that experienced with Linux security problems and
    >how to deal with them, and I am encountering some problems that I don't
    >know very well how to deal with. Maybe some more experienced people
    >could help me with an advice.
    >What's happening? After running the "lastb" commands, I can see a lot
    >of failed attempts to login into my Linux server - it just goes on
    >every night, from different IP addresses. Here is a sample of what the
    >"lastb" command shows:


    Yes, ssh attacks have become a standard of the internet on Linux machines.
    Make sure that all of your accounts on your system are either disabled, or
    have good passwords.


    >gem ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >ansel ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >ansel ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >weaken ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >weaken ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >sne ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >sne ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >relf ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >relf ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >mi ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >mi ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >linss ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >linss ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >jean ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >jean ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00)
    >hansen ssh:notty 60.248.215.110 Thu Dec 21 02:14 - 02:14
    >(00:00) .


    >Fortunately, it seems there has not been any successful attempt, as the
    >"last" command shows nothing suspicious, only the expected connections
    >from the trusted hosts. But I am still worried that somebody might find
    >a way to break in eventually, because this kind of password scanning
    >goes on continuosly. What I did was just disable login from all user


    Yes, it does. Aren't you happy that first the attacker has to find a valid
    user on your system, and then guess the password. With a good MD5 password
    it should take at least 10^9 tries to find it. Since there are only 3 10^7
    seconds in a year, it should take a long time.

    >accounts different than root, by means of the sshd_config file, and
    >made sure the root password is strong enough. Is there anything else I
    >should do in this situation? What about trying to follow up on the IP
    >addresses appearing inside the log, to see where the aggressors are
    >coming from? Is there any way I can take action against this
    >unauthorized scanning of my machine? Or maybe the IP addresses are fake
    >and the attack comes actually from somewhere else?


    No. But those are almost certainly machines which have been taken over by
    some trojan/virus etc. Ie the owner of the machine is probably totally
    clueless that it is being used for this attack. However you could go ahead
    and send the sysadmin ( use whois) a message informing them that their
    machine has been taken over.


    > Please let me know what you think about this situation, so that I
    >could have a better idea about how to improve the security of my Linux
    >server.


    > Thank you,
    > Christian Sava



  3. Re: Password scan

    Unruh (06-12-21 19:05:08):

    > > Fortunately, it seems there has not been any successful attempt, as
    > > the "last" command shows nothing suspicious, only the expected
    > > connections from the trusted hosts. But I am still worried that
    > > somebody might find a way to break in eventually, because this kind
    > > of password scanning goes on continuosly. What I did was just
    > > disable login from all user

    >
    > With a good MD5 password it should take at least 10^9 tries to find
    > it. Since there are only 3 10^7 seconds in a year, it should take a
    > long time.


    I don't know how you have related those terms and numbers with each
    other, but my calculation is different. There are at most 2^128 MD5
    passwords. The information rate of a random ASCII string (without
    control characters) is log_2(96) = 6.58 bits per byte. So with each
    character, you add 6.58 bits of entropy to the hash value of the
    password.

    In theory, the worst-case brute-force attack would take 2^128 steps.
    But in cases such as passwords, you have a lot of valuable information
    about the original message, hence the attack will need much less time.

    So in practise, a brute-force attack will need at most a total of T =
    2^min(6.58*L, 256) tries, where L is the length of the password,
    e.g. for an insecure password with six characters, you will need at most
    T = 782757789696 steps to find out the correct password. Since there is
    a small probability for collisions, the real number of tries is slightly
    less than T, from a probabilistic view.

    However, to be more realistic, we consider that a password is a
    combination of at most 36 characters. In such a case, for eight
    characters, you will need at most 2821109907456 tries, which is still a
    huge number. In the average, you will find the correct password after
    T/2 tries.

    Well, a _good_ password has at least 12 characters, such that T =
    4738381338321616896. This is a lot more than 10^9 I think.


    Regards,
    E.S.

  4. Re: Password scan

    christian_sava wrote:
    > Please let me know what you think about this situation, so that I
    > could have a better idea about how to improve the security of my Linux
    > server.


    This is a fact of life for an exposed SSH server. Two things to do are:

    1) Disable SSH version 1 - It is less secure than SSH 2

    2) Disable root login. If you need to do remote admin, login as a
    normal user and use su or sudo. Remember to give your non-root user
    sudo authority BEFORE you disable root login :-)

    3) Disable password-based authentication and use key-based auth only.
    In key-based auth every user must possess a unique private key file
    in addition to the key-file's passphrase, and no password hash is
    ever sent over the wire.

    The relevant SSHD configuration parameters are:

    Protocol 2
    PasswordAuthentication no
    PermitRootLogin no
    PubkeyAuthentication yes

    If this is on a remote server where you don't have physical
    console access then you have to do things in the right order
    or you risk shutting yourself out by accident.

    1) Generate the keypair you will be using (ssh-keygen)

    2) Install the public key on the server in $HOME/.ssh/authorized_keys

    3) TEST KEY-BASED LOGIN - make absolutely sure you can login with the
    matching private key.

    4) Only then disable PasswordAuthentication

    If you disable PasswordAuthentication before verifying that you can
    login with the private key, you may find yourself unable to login
    at all.

  5. Re: Password scan

    Jim Garrison (06-12-22 11:19:05):

    > 2) Disable root login. If you need to do remote admin, login as a
    > normal user and use su or sudo. Remember to give your non-root
    > user sudo authority BEFORE you disable root login :-)
    >
    > 3) Disable password-based authentication and use key-based auth only.
    > In key-based auth every user must possess a unique private key file
    > in addition to the key-file's passphrase, and no password hash is
    > ever sent over the wire.


    Bad idea. If you need to login to a normal user first, and then issue
    su/sudo to become root, an attacker can easily guess the length of the
    root password, by nothing more than counting packets. When using
    key-based authentication, better login to root directly.


    > The relevant SSHD configuration parameters are:
    >
    > Protocol 2
    > PasswordAuthentication no
    > PermitRootLogin no
    > PubkeyAuthentication yes


    And of course:

    ChallengeResponseAuthentication no


    Regards,
    E.S.

  6. Re: Password scan

    On 2006-12-23, Ertugrul Soeylemez wrote:

    > Jim Garrison (06-12-22 11:19:05):
    >
    >> 2) Disable root login. If you need to do remote admin, login as a
    >> normal user and use su or sudo. Remember to give your non-root
    >> user sudo authority BEFORE you disable root login :-)
    >>
    >> 3) Disable password-based authentication and use key-based auth only.
    >> In key-based auth every user must possess a unique private key file
    >> in addition to the key-file's passphrase, and no password hash is
    >> ever sent over the wire.


    > Bad idea. If you need to login to a normal user first, and then issue
    > su/sudo to become root, an attacker can easily guess the length of the
    > root password, by nothing more than counting packets. When using
    > key-based authentication, better login to root directly.


    How so? They still have to guess the password (actually two -- one for
    the user account from which to invoke su/sudo and another for su/sudo
    itself), and while they're doing that they're generating a log entry for
    every failed attempt. Any sysadmin with a functioning brain cell is
    going to perk up at that.

    --

    John (john@os2.dhs.org)

  7. Re: Password scan


    Ertugrul Soeylemez wrote:
    > Jim Garrison (06-12-22 11:19:05):
    >
    > > 2) Disable root login. If you need to do remote admin, login as a
    > > normal user and use su or sudo. Remember to give your non-root
    > > user sudo authority BEFORE you disable root login :-)
    > >
    > > 3) Disable password-based authentication and use key-based auth only.
    > > In key-based auth every user must possess a unique private key file
    > > in addition to the key-file's passphrase, and no password hash is
    > > ever sent over the wire.

    >
    > Bad idea. If you need to login to a normal user first, and then issue
    > su/sudo to become root, an attacker can easily guess the length of the
    > root password, by nothing more than counting packets. When using
    > key-based authentication, better login to root directly.


    That has its own dangers. There are numerous reasons to force non-root
    login first, but the main reason is tracking: which of the authorized
    root users on a system logged in and blew up the system at 4:00 AM last
    night? It also makes it easier to cut off one inappropriate or expired
    user than to expire the root passwords on all machines that user has
    root access to.


  8. Re: Password scan

    "Nico" (06-12-23 23:08:08):

    > > Bad idea. If you need to login to a normal user first, and then
    > > issue su/sudo to become root, an attacker can easily guess the
    > > length of the root password, by nothing more than counting packets.
    > > When using key-based authentication, better login to root directly.

    >
    > That has its own dangers. There are numerous reasons to force non-root
    > login first, but the main reason is tracking: which of the authorized
    > root users on a system logged in and blew up the system at 4:00 AM
    > last night? It also makes it easier to cut off one inappropriate or
    > expired user than to expire the root passwords on all machines that
    > user has root access to.


    On the other hand, if root wipes all data, you can't track anything
    anyway, other than on an external logging server, which is shut tight.
    If so, you can simply log, which public key has been used for that
    particular session. No need for an intermediate login here.


    Regards,
    E.S.

  9. Re: Password scan

    John Thompson (06-12-23 16:04:22):

    > > Bad idea. If you need to login to a normal user first, and then
    > > issue su/sudo to become root, an attacker can easily guess the
    > > length of the root password, by nothing more than counting packets.
    > > When using key-based authentication, better login to root directly.

    >
    > How so? They still have to guess the password (actually two -- one for
    > the user account from which to invoke su/sudo and another for su/sudo
    > itself), and while they're doing that they're generating a log entry
    > for every failed attempt. Any sysadmin with a functioning brain cell
    > is going to perk up at that.


    True, but key based authentication makes bruteforcing effectively
    impossible, even though the attacker might know everything about the
    public key.


    Regards,
    E.S.

+ Reply to Thread