Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)ST
Posts
0
Comments
679
Joined
2 yr. ago

  • That is actually somewhat usual, isn't it? Just compared previous gens high end with entry to mid on nvidia like 1080 vs 3060 and 2080 vs 4060. They paint the same picture.

    We are far away from the times where every single generation, marks a significant performance increase. For CPU or GPU performance.

  • And what do you suggest to use otherwise to maintain a server? I am not aware of a solution that would help here? As an attacker you could easily alias any command or even start a modified shell that logs ever keystroke and simulates the default bash/zsh or whatever.

  • The scenario OC stated is that if the attacker has access to the user on the server then the attacker would still need the sudo password in order to get root privileges, contrary to direct root login where the attack has direct access to root privileges.

    So, now i am looking into this scenario where the attack is on the server with the user privileges: the attacker now modifies for example the bashrc to alias sudo to extract the password once the user runs sudo.

    So the sudo password does not have any meaningful protection, other then maybe adding a time variable which is when the user accesses the server and runs sudo

  • Most comments here suggest 3 things

    1. least privilege: Which is ok, but on a Server any modification you do requires root anyway, there is usually very little benefit
    2. Additional protection through required sudo password: This is for example easily circumvented by modifying the bashrc or similar with an sudo alias to get the password
    3. Multiuser & audittrails: yes this is a valid point, on a system that is modified or administered by multiple ppl there are various reasons lime access logging and UAC for that

    An actual person from the pen testing world: https://youtu.be/fKuqYQdqRIs

  • Do you want to prevent brute forcing or do you want to prevent the attack getting in?

    If you want to prevent brute forcing then software like fail2ban helps a little, but this is only a IP based block, so with IPv6 this is not really helpfull against a real attack, since rotating IP addresses is trivial. But still can slow down the attacker. Also limiting the amount of sessions and auth tries does significantly slow down the attacker.

    If you just want to not worry about it set strong passwords, and when it is a multi user system where other ppl might access it, configure Public Key Auth so you can be sure the other users have strong passwords (or keys in this case) to authenticate.

    With strong passwords or keys it is basically impossible to brute force your way in with ssh.

  • I don't use browser extensions and I manually copy/paste my passwords to fill in entries.

    On most systems copy pasting is heavily insecure since a lot of processes have access to the clipboard. autotype and thinga like browser extensions are considered more secure.

  • Either you are heavily misinformed about how difficult arch is, or you lack any confidence in your 'Linux skill'.

    Choose the system you want to achieve, follow the wiki and choose the software you want to use using it and you are good to go, it really is not that hard. You can always use archinstall.