Ceci est une ancienne révision du document !
Last issue we touched on physical security of your assets. Controlling the perimeter, controlling access, monitoring said perimeter and access and providing different levels of security. This issue, we dive a little deeper into account security. We are all aware of passwords and password strength, as it get drilled into us from an early age. As computers get more powerful, it takes less time to brute-force passwords. Current thinking has us using pass phrases, rather than passwords and the lazy among us will be kicking at it, not understanding the ease at which “.password” or “password1” is compromised. It is easier to attack a system once you have access. ( Compromising it from inside.) A good example of this is android rooting. This is mostly gained via privilege escalation.
Let us have a obligatory look at Linux account types. First we have root or superuser. ( UID 0.) This account can do anything and is the holy grail for malicious hackers. It is good practice to NOT have an account named root or super or derivatives thereof as this would always be the go-to for script kiddies.
These days standard users have UID's larger than 1000 by default. ( You can change this in /etc/login.defs ) I encourage new admins to actually read through the file. Linux only gives two nickels if an account is 0 nor not, the numbering is for us mere mortals.
TIP: It is good to have an alias of this command that you can run twice a day:
awk -F: '($3 == “0”) {print}' /etc/passwd
Avoid using the root account, even if you are the only user on your system. This creates habit. Block direct root logins whenever and wherever you can. Check your sshd_config file and make sure PermitRootLogin is set to no. As previously stated, this is the holy grail for an attacker. Using sudo you expand your audit trail. PAM has a module called pam_securetty to help you secure your system.
In the old wild west days of dial up internet, I used to find my ISP's server names, copy the /etc/password and run it against john the ripper and mail my ISP the new administrator passwords every week as a gag. Then Linux became a bit more professional by moving the passwords to /etc/shadow, but once again it was not a perfect solution. To make things more secure, Linux introduced PAM, the pluggable authentication module, which for illustrative purposes we can say is the man in the middle between the user and the password file. This creates an additional layer of security. PAM however can also be configured incorrectly, so it is vital for administrators to know the options in the pam.d manpage. PAM is great for enforcing strong passwords. Modules like “pam_pwquality” is unmissable in your arsenal. I will not go into password age as changing passwords on a regular (monthly) basis lets users create patterns that can be learned by malicious actors. Controlling account access is just as important as controlling physical access. I should point out multi factor authentication at this stage, again PAM modules such as Google Authenticator, that will message you a code when trying to SSH into a system. If you do not trust Google, there are other options! Even your VPN should be at least two factor secured. A good example is those credit card or USB-type keys that display a code when you press a button. Using multi factor authentication can really tighten up security.
Documentation is another thing you cannot be without. If a new user is created, let there be documentation for it, signed off by someone who is responsible for that person. If a user leaves, that documentation can be the reminder that that you need to change their shell to /sbin/nologin. It is easy to forget and stale user accounts are an attack vector. Back in the day it used to be /bin/false so be aware of this in legacy systems. PAM also has a nologin module you should be aware of. Speaking of paperwork, have a code of conduct for your users to sign, the last thing you need is users sharing accounts.
Intrusion prevention systems is another thing you cannot be without. You will commonly find two flavours, NIDS and HIDS. Use both! On HIDS we have OSSEC, Sagan, AIDE, Samhain and the most popular, fail2ban. On NIDS we have Security onion, SNORT, Bro, Open WIPS-ng. There are quite a few commercial offerings too.
It is good practise to keep your log files on another server. The last thing you need is not to be aware that your system has been compromised. Make time to review /var/log/messages , /var/log/syslog , /var/log/auth.log and /var/log/secure - these are generic locations and may vary. With this said, I would like to reiterate that root passwords on different systems should not be the same!
There are, of course other account options, like open LDAP etc. These single sign on locations are also high value targets for attackers as this allows them to traverse the system with ease. I am not going to cover them all, there are too many for the scope of this piece, but suffice to say, rather be paranoid with any of them. The GDPR penalties have started rolling in.