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.
Dans le dernier numéro, nous avons abordé la sécurité physique de vos actifs : le contrôle du périmètre, le contrôle de l'accès, la surveillance des dits périmètres et accès et l'apport de différents niveaux de sécurité. Ce mois-ci, nous irons plus en détail dans la sécurité des comptes. Nous sommes tous conscients de mots de passe et de leur force, car nous en entendons parler avec force depuis notre enfance. Au fur et à mesure que les ordinateurs deviennent plus puissants, il faut moins de temps pour trouver les mots de passe par la force brute. Le raisonnement actuel nous suggère d'utiliser des phrases de passe, plutôt que des mots de passe et les paresseux parmi nous renâcleront, car ils ne comprennent pas combien c'est facile de compromettre « ;password » ou « password1 ». Il est plus facile de s'attaquer à un système quand vous pouvez y accéder. (Compromission de l'intérieur.) Un bon exemple de ceci est le rootage d'Android. L'accès y est acquis via l'escalade des privilèges.
Nous devons obligatoirement examiner les types de comptes sous Linux. Il y a, d'abord, root ou superuser. (UID 0.) Ce compte peut tout faire et c'est le grand objectif pour des pirates malicieux. C'est une bonne pratique de NE PAS avoir un compte nommé root ou super, ou leurs dérivés, car ces comptes seraient toujours les cibles des gosses fana de scripts.
De nos jours, les utilisateurs standards ont des UID plus grands que 1000 par défaut. (Vous pouvez changer ceci dans /etc/login.defs.) J'encourage les nouveaux administrateurs à prendre le temps de lire ce fichier. Linux s'en fiche royalement de savoir si un compte est 0 ou pas, la numérotation existe uniquement pour nous, simples mortels.
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.
ASTUCE : il serait bon d'avoir un alias de cette commande que vous pouvez lancer deux fois par jour :
awk -F: '($3 == “0”) {print}' /etc/passwd
Évitez l'utilisation du compte root, même si vous êtes le seul utilisateur de votre système. Cela crée des habitudes. Bloquez des connexions root directes dans la mesure du possible. Vérifiez votre fichier sshd_config et assurez-vous que PermitRootLogin est réglé sur no (non). Comme indiqué plus tôt, c'est le saint Graal pour tout assaillant. En utilisant sudo vous élargissez votre piste d'audit. PAM propose un module appelé pam_securetty qui vous aidera à sécuriser votre système.
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.
Autrefois, à l'époque du Far West et de la connexion à Internet via le réseau commuté, j'avais l'habitude de trouver le nom des serveurs de mon FAI, de copier le /etc/password et de le lancer contre John the Ripper, puis d'envoyer les nouveaux mots de passe administrateur à mon FAI chaque semaine comme une blague. Ensuite Linux est devenu un peu plus professionnel en déplaçant les mots de passe dans /etc/shadow, mais, à nouveau, ce n'était pas une solution parfaite. Pour sécuriser les choses davantage, Linux a introduit PAM, le module d'authentification enfichable, dont, à des fins d'illustration, on peut dire que c'est l'homme au milieu entre l'utilisateur et le fichier de mots de passe. Cela crée une couche supplémentaire de sécurité. Cependant, PAM peut être configuré incorrectement ; aussi, il est vital pour des administrateurs de connaître les options dans la page man de pam.d. PAM applique les mots de passe forts de façon géniale. Des modules comme « pam_pwquality » doivent figurer dans votre arsenal. Je ne vais pas parler de l'âge des mots de passe, car changer les mots de passe régulièrement (sur une base mensuelle) permet la création de motifs par les utilisateurs et des acteurs malicieux peuvent apprendre ces motifs. Contrôler l'accès à un compte est tout aussi important que contrôler l'accès physique à l'ordinateur. À ce stade, je devrais signaler l'authentification à facteurs multiples, à nouveau des modules PAM comme Google Authenticator, qui vous enverra un code quand vous essayez d'entrer dans un système via SSH. Si vous ne faites pas confiance à Google, d'autres options existent ! Même votre VPN doit être sécurisé par au moins deux facteurs. Un bon exemple serait ces cartes de crédit ou des clés de type USB qui affichent un code quand vous appuyez sur un bouton. L'utilisation d'une authentification à facteurs multiples peut vraiment améliorer votre sécurité.
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.
Une autre chose qu'il est impératif d'avoir, c'est de la documentation. Si un nouvel utilisateur est créé, faites qu'il y ait de la documentation signée par quelqu'un qui est responsable de cette personne. Si un utilisateur part, cette documentation peut être le rappel qu'il faudrait changer leur shell à /sbin/nologin. Il est facile d'oublier de le faire et des comptes utilisateurs rassis sont un vecteur d'attaque. Autrefois, c'était dans /bin/false et il faut être conscient des vieux systèmes. PAM a également un module nologin dont il faut être conscient. En parlant de paperasse, ayez un code de conduite que vos utilisateurs doivent signer, car la dernière chose dont vous avez besoin est le partage de comptes entre utilisateurs.
Autre chose qu'il faut avoir : des systèmes de prévention d'intrusion. Généralement vous en trouverez deux parfums, NIDS et HIDS. Utilisez les deux ! Sur HIDS, nous avons OSSEC, Sagan, AIDE, Samhain et, le plus populaire, fail2ban. Sur NIDS, wnous avons Security onion, SNORT, Bro et OpenWIPS-ng. Il y a pas mal d'offres commerciales aussi.
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.
Une bonne habitude est de stocker vos fichiers journaux sur un autre serveur. La dernière chose dont vous avez besoin est de ne pas savoir que votre système est compromis. Trouvez le temps de consulter /var/log/messages , /var/log/syslog , /var/log.auth.log et /var/log/secure (ce sont des emplacements génériques et ils peuvent varier). Tout cela étant dit, je persiste et je signe : les mots de passe root sur différents systèmes ne devraient pas être les mêmes !
Il existe, bien entendu, d'autres options de comptes, comme open LDAP, etc. Ces emplacements uniques de connexion sont des cibles à grande valeur pour des assaillants, car ceci leur permet de parcourir le système avec une grande facilité. Je ne vais pas les traiter toutes, car il y en a trop pour la portée de ces articles, mais je vais seulement dire qu'il vaut mieux être paranoïaque avec n'importe laquelle. Les pénalités du RGPD ont commencé à tomber.