Bonsoir
J’ai décidé de potasser celui la cette semaine avant de revenir sur les autres Le cahier de l'administrateur Debian
@vbreton quoi penses tu en terme de sécurité matérielle.? Cryptage des informations par exemple?
Bonne soirée
@Anonymous23, l’accès physique, la protection contre les perturbations électromagnétiques et électrostatiques, l’architecture matérielle (notamment la séparation de la zone données de la zone code), la redondance des serveurs et leur réplication automatique en cas d’anomalie. Le microcode et la configuration des cartes. Le choix de la carte réseau et de façon plus large le choix des composants ce qui est particulièrement problématique en France depuis la disparition du constructeur français Bull.
En ce qui concerne le cryptage des informations, c’est généralement effectué par logiciel ou microcode, d’où la nécessité de bien paramétrer son BIOS pour l’UEFI par exemple.
1 J'aime
Chiffrement des disques, activation du secure boot (plus facile à faire avant l’installation), remplacement si jamais des clefs et certificats par défaut du secure boot (i.e.: se débarrasser de ceux de Microsoft et de Debian, car il existe des attaques permettant de déchiffrer un disque).
Utilisation de libpam_mount pour ne monter une partition chiffrées qu’à l’ouverture de session.
1 J'aime
Merci
Je viens de faire une première lecture du cahier de l’administrateur Debian et de revisiter le guide de l’ANSSI.
Mon besoin de sécurité reste modéré, je n’ai pas des données géostratégiques dans mon travail.
Le plus gros risque serait que le PC soit bloqué / Crashé / volé / rançonné car mes données ont coûté un bon travail. Donc je crois que la première sécurité serait de mettre un NAS au boulot pour stocker nos données mais c’est une autre histoire.
Concernant mon propre PC mes réflexions sont presque abouties, et résumées par rapport au guide ANSSI:
Séléctionné, première série de mesures
Activer secure boot R3
Protéger le bootloader et le bios par un code R2, R5
Paramétrer réseau IPV4, désactiver IPV6 R12 R13
verrouillage du compte root, des comptes de service, utilisation de sudo et auditd pour tracer les utilisateurs R33
R39 modifier le comportement de sudo
R62 désactiver les services inutiles
En reflexion
Activer l’IOMMU R7
paramétrer les options de configuration de la mémoire R8
paramétrer les options de configurations du noyau R9
désactiver le chargement des modules du noyau R10
activer LSM Yama R11
paramétrer le options de configuration des systèmes de fichiers R14
R31 mots de passe robustes
Et en plus :
UFW, fail2ban, keypass, cryptage des disques…
Est ce que cela vous parait cohérent?
Bonne soirée
Sans IPv6 des sites vont devenir inaccessible de plus en plus. EN cas d’utilsiation d’équipement connecté, point de salut.
Sur ce point l’ANSSI est un peu en retard.
Il est utile d’avoir de l’IPv6 mais dans le même mode que l’IPv4 en utilisant des plages d’adresses locale only (équivalent à la RFC1918), et utilisant une IPv6 publique sur le routeur internet avec un NAT.
pour le
il faut quelque chose de correctement chiffré.
Oui, keypass juste pour le mots clés.
Pour le chiffrage je vais voir, j’utilise zulucrypt actuellement chez moi, mais je n’ai pas arrêté la solution pour le boulot.
Zulucrypt n’est qu’un frontend.
La difficulté du chiffrage d’un disque c’est le déchiffrement au démarrage.
D’autant que la partie UEFI va demander la clef avec un clavier QWERTY.
Ceci étant, Trixie arrive avec l’UKI, ce qui devrait pas mal aider à faciliter les choses.
Un backup régulier me semble la solution. Une gravure sur support permanent et mise au coffre me semble le minimum. Une autre solution complémentaire consiste à échanger avec un tiers de confiance un jeu de sauvegarde crypté. Pour cela il est nécessaire d’identifier au préalable, la quantité de données, la fréquence des ajouts… Cela fait parti du plan de sauvegarde après sinistre mais ça se prépare avant !
kesako UKI ?
Universal Kernel Image
https://wiki.archlinux.org/title/Unified_kernel_image
https://bbs.archlinux.org/viewtopic.php?id=300058
En gros, l’UEFI et le boot image sont unifié en un seul bloc.
Une image de noyau unifiée (UKI) est un exécutable unique qui peut être démarré directement à partir du firmware UEFI, ou automatiquement approvisionné par des chargeurs de démarrage avec peu ou pas de configuration. Il s’agit de la combinaison d’un programme UEFI boot stub comme systemd-stub(7), une image du noyau Linux, un initrd et d’autres ressources dans un seul fichier UEFI PE.
Ce fichier, et donc tous ces éléments peuvent ensuite être facilement signés pour une utilisation avec Secure Boot.
Fini l’UEFi qui te demande la clef de déchiffrement de ton disque chiffré en QWERTY, disque par disque, pour ensuite avoir ton noyau quie te redemande la même clef en AZERTY pour tous les disques du fichier crypttab.
1 J'aime
Oui en effet. J’ai presque fini la config de mon pc pour bosser et c’est casse pied d’avoir a rentrer le user et la clé pour le grub en QWERTY puis le code pour décrypter puis le login et MDP.
Il me reste deux choses à faire. Faire tourner quelques applications métier windows sur wine.
Configurer auditd.
Bonne soirée
Pour voir la qualité de ton système, installe Lynis (direct du paquet Debian ou utilise celui du repo de Lynis pour avoir la dernière version).
Ça te donnera une vue d’ensemble de ton système.
Je travaille actuellement avec pour finaliser les derniers éléments que je n’ai pas encore durcit (je suis passé par les recommendations de CIS Workbench) en premier lieu avec un script bash que j’ai créée à partir de ca, …et qui fait près de 10000 ligne 
et qui me sert à toutes mes installations ou presques).
J’ai installé Lynis, réalisé une grande partie des recommandations qu’il donne.
Pour les malware scanners
Harden the system by installing at least one malware scanner, to perform periodic file system scans [HRDN-7230] - Solution : Install a tool like rkhunter, chkrootkit, OSSEC https://cisofy.com/lynis/controls/HRDN-7230/
Lequel me conseillez vous?
Bonne journée
Et est ce que fail2ban a un intêret vu que ufw est réglé en « deny incoming »?
Pour le file system scan j’utilise AIDE et chkrootkit.
OSSEC est trop gros pour une petit infra car il n’est utile que si l’infra centralisée est mise en place.
J’avais utilisé rkhunter fut un temps, mais certains problèmes avait fait que je l’avais retiré. Mais je ne sais plus malheureusement pourquoi.
Dois je désactiver les core dumps?
dans /etc/security/limits.d/96-coredump.conf j’ai mis:
* hard core 0
sachant que par defaut, il me semble, qu’il y a dans /etc/security/limits.d/20-coredump-debian.conf :
* soft core infinity
root soft core infinity
Et j’ai installé systemd-coredump avec /etc/systemd/coredump.conf
[Coredump]
Storage=none
ProcessSizeMax=0
et dans sysctl:
fs.suid_dumpable=0
Merci 
Et est ce que tu as augmenté le nombre de règles dans /etc/aide/aide.conf?
J’ai gardé les règles par défaut