Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Serious - Need help - CentOS8 - VM - Probably compromised - Page 2
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Serious - Need help - CentOS8 - VM - Probably compromised

2»

Comments

  • letboxletbox Member, Patron Provider

    @plumberg said:
    Thank you all. Atleast for now I know what was the malware. But I haven't figured out anything from logs.

    So many people suggest Key based authentication...

    How does that work when I have multiple devices to login from? Like my phone/ home laptop/ work laptop/ an idling vps... what's best way to setup keys? Also if one pvt key on a device is compromised, wouldn't the attacker be able to remove other keys from server?

    Thank you

    Just use termius it will rsync all ssh keys with all devices.

    Regards

    Thanked by 2pedagang TimboJones
  • @key900 said:

    @plumberg said:
    Thank you all. Atleast for now I know what was the malware. But I haven't figured out anything from logs.

    So many people suggest Key based authentication...

    How does that work when I have multiple devices to login from? Like my phone/ home laptop/ work laptop/ an idling vps... what's best way to setup keys? Also if one pvt key on a device is compromised, wouldn't the attacker be able to remove other keys from server?

    Thank you

    Just use termius it will rsync all ssh keys with all devices.

    Regards

    I'll check. Thnx

  • Don't mean to hijack a topic but out of curiosity is host.deny host.allow configured to allow connection from just one IP enough to keep them out or are there any work arounds for it?

  • @Falzo said:
    while I agree that using keys instead of passwords should be the way to go, one should note that this table and given times are kind of meaningless without specification of the crunching setup.
    most likely you will only achieve that, if you're already in possession of the hash so you can bruteforce directly on whatever powerful system.

    the usual attacks against ssh still involve connection limits, latency and such, so it will for sure take a lot longer to brute force even an 8 mixed chars passwords directly. things like fail2ban add to that time frame simply because an attacker then needs to circle through tons of IPs or dial down on the frequency.

    You are totally right. Yes, passwords are bad, but not that bad.
    Lets say its a 8 character password with lower- and uppercase plus numbers. That's 62 possible characters, that gives 62^8 possible combinations.
    Just to keep the math easy we say one attempt per second.
    62^8 combinations = 218 trillion attempts. With 1 attempt per second it would take about 7 million years to guarantee that the password is found. We can go extreme and say that it manages 1000 attempts per second. Still, it takes 7000 years.
    And simple things like fail2ban and similar multiplies that time by a lot. Such a simple thing as not permitting root login forces the attacker to have to guess the username as well as the password. Anyone with basic understanding of math can figure out what that does to the total time taken (unless the user is an idiot and uses 'admin' or similar as username).

    Don't get me wrong, I'm not advocating using just passwords, absolutely not, but if people could just use good, random passwords bruteforce attacks would be more or less useless. There are of course a lot of other reasons to not use just passwords, but bruteforce against services such as ssh is so easily prevented it shouldn't even be a problem.
    And again, since I know I will probable take some heat for this: I'm not advocating using passwords! I just think people should understand what an extremely big difference it makes to just add a few numbers or symbols in their passwords.

    Thanked by 2Falzo chocolateshirt
  • @rcy026 said: Such a simple thing as not permitting root login forces the attacker to have to guess the username as well as the password

    totally agree on that one. if you install debian/ubuntu via netinst or as minimal, root access will be set to no-password as this is the openssh-server default - while you'll still get an unprivileged user to be able to login with a password and become root via su - afterwards.

    it's only a convenience/automation thing nowadays that has providers still setup templates with root access via password enabled, so they can simply set something and send to the user 🤷‍♂️

  • noted
    root via su
    like one of my provider

Sign In or Register to comment.