PROXMOX – run-parts: /etc/cron.daily/mlocate exited with return code 1

Il m’est arrivé de recevoir un email de l’hyperviseur avec comme titre :
RUN-PARTS: /ETC/CRON.DAILY/MLOCATE EXITED WITH RETURN CODE 1

run-parts: /etc/cron.daily/mlocate exited with return code 1

locate est un lien vers le programme mlocate, il permet de localiser immédiatement n’importe quel fichier ou répertoire présent sur la machine.

locate est rapide parce qu’au lieu de parcourir en « live » toute l’arborescence du système (comme le fait find), une base de données ou index est régulièrement mis à jour qui contient la liste de tous les fichiers et répertoires. C’est cet index statique qui va être exploré très rapidement et fournir le résultat de la recherche lors de l’utilisation de locate.

La base de données est automatiquement mise à jour quotidiennement grâce au programme anacron.

C’est un problème de cet index, que l’on peux résoudre en deux lignes, et les droits root :

rm /var/lib/mlocate/mlocate.db

puis on met à jour updatedb manuellement via :
updatedb

WARNING: The « syslog » option is deprecated

WARNING: The « syslog » option is deprecated

Administration Systèmes en Informatique

Dans le contexte de Samba, le message d’avertissement « WARNING: The ‘syslog’ option is deprecated » indique que l’option « syslog » utilisée dans la configuration de Samba pour la journalisation des événements est obsolète. Cette option était utilisée pour envoyer les journaux vers le système de journalisation syslog. Cependant, elle est désormais obsolète et il est recommandé d’utiliser des méthodes de journalisation alternatives, telles que l’utilisation du journal système (systemd), le journal Samba intégré ou d’autres solutions de journalisation tierces compatibles.

 

Éditez le fichier de configuration de Samba  /etc/samba/smb.conf

vi /etc/samba/smb.conf

puis commentez l’option syslog = 0 avec un #

# syslog = 0

 

Utilisation de systemd

Éditez le fichier de configuration de Samba  /etc/samba/smb.conf

[global]
# Autres paramètres globaux...

# Utilisation du journal système (systemd)
log file = systemd

Conclusion

En mettant à jour la configuration de Samba pour utiliser une méthode de journalisation moderne, vous pouvez éviter les problèmes de compatibilité et bénéficier de fonctionnalités améliorées de journalisation et de surveillance.

 

Vulnérabilité dans le gestionnaire de paquets APT – CERT-FR

Objet: Vulnérabilité dans le gestionnaire de paquets APT

Max Justicz a découvert une vulnérabilité dans APT, le gestionnaire de paquet de haut niveau. Le code traitant les redirections HTTP dans la méthode de transport HTTP ne vérifie pas correctement les champs transmis sur le réseau. Cette vulnérabilité pourrait être utilisée par un attaquant dans la position « d’homme du milieu » entre APT et un miroir pour injecter un contenu malveillant dans la connexion HTTP. Ce contenu pourrait ensuite être reconnu comme un paquet valable par APT et être utilisé plus tard pour l’exécution de code avec les droits du superutilisateur sur la machine cible.

Source : Vulnérabilité dans le gestionnaire de paquets APT – CERT-FR

Bulletin d’alerte Debianhttps://www.debian.org/security/2019/dsa-4371

Des services Tor identifiables

BSelon le chercheur en sécurité Yonathan Klijnsma, de RiskIQ, cité par Bleeping Computer, des serveurs web (Apache ou Nginx) mal configurés écoutent une adresse IP sur l’Internet public, plutôt que leur localhost (127.0.0.1).

Les serveurs mal configurés : une menace pour la sécurité en ligne

Dans le cas d’un service Tor, la configuration sécurisée des serveurs web est tout aussi cruciale, voire même plus importante. Tor est un réseau décentralisé qui permet aux utilisateurs de naviguer sur Internet de manière anonyme en faisant transiter leur trafic à travers plusieurs nœuds, masquant ainsi leur véritable adresse IP. Cependant, cette anonymisation peut également attirer l’attention des cybercriminels cherchant à exploiter les vulnérabilités pour découvrir l’origine du trafic.

La spécificité des services cachés Tor

Les services cachés Tor sont des sites web ou des services accessibles uniquement via le réseau Tor. Ces services utilisent des adresses en « .onion » et sont destinés à offrir une plus grande confidentialité et anonymat à leurs utilisateurs. Cependant, la gestion sécurisée de ces services est essentielle pour éviter toute compromission.

Les risques liés à une mauvaise configuration

Si un service caché Tor est mal configuré, plusieurs risques de sécurité peuvent survenir :

Dé-anonymisation des utilisateurs : Une mauvaise configuration du serveur peut potentiellement exposer des informations sur les utilisateurs qui se connectent au service caché, mettant ainsi en danger leur anonymat.

Vulnérabilités d’exécution distante de code : Des failles de sécurité pourraient permettre à des attaquants de prendre le contrôle du serveur et de l’utiliser pour des activités malveillantes.

Fuite d’informations sensibles : Des erreurs de configuration pourraient conduire à la divulgation accidentelle d’informations sensibles, telles que des clés privées ou des données utilisateur.

Attaques sur le réseau Tor : Un serveur mal configuré pourrait également être utilisé pour mener des attaques contre d’autres services cachés Tor, compromettant ainsi l’ensemble du réseau.

Meilleures pratiques pour sécuriser un service caché Tor

Pour garantir la sécurité d’un service caché Tor, voici quelques meilleures pratiques à suivre :

Utilisation de versions à jour : Assurez-vous que le logiciel du serveur et les dépendances utilisées sont régulièrement mises à jour pour bénéficier des derniers correctifs de sécurité.

Restriction d’accès : Configurez le serveur pour qu’il n’écoute que sur l’interface de réseau local (localhost) et empêchez les connexions extérieures non autorisées.

Isolation du service : Utilisez des techniques d’isolation, telles que les conteneurs ou les machines virtuelles, pour limiter les interactions entre le service caché et le reste du système.

Chiffrement fort : Activez le chiffrement SSL/TLS avec des certificats valides pour sécuriser les communications entre le serveur et les utilisateurs du service caché.

Configuration par défaut sécurisée : Vérifiez et modifiez les paramètres de configuration par défaut pour éliminer les vulnérabilités potentielles.

Audits de sécurité réguliers : Effectuez des audits de sécurité périodiques pour identifier et résoudre tout problème de configuration ou de vulnérabilité.

En conclusion

La sécurité d’un service caché Tor dépend grandement d’une configuration adéquate du serveur web. En prenant des mesures pour assurer la confidentialité et l’intégrité du service, les propriétaires de sites web .onion peuvent offrir à leurs utilisateurs un environnement en ligne plus sûr et protéger l’anonymat que Tor est censé fournir.

 

A voir : https://m.nextinpact.com/brief/des-services-caches-tor-identifiables-via-leur-certificat-tls-5248.htm

Find où sont mes répertoires vides sous GNU/Linux

La commande find permet de trouver des fichiers, des répertoires et éventuellement d’exécuter une action par dessus. C’est exactement ce que je veux : trouver les répertoires vides d’un répertoire donné.

find -maxdepth 2 -empty -type d
  • -maxdepth : permet de limiter le find à une profondeur de 2
  • -empty : trouver les « vides »
  • -type d : on veux les répertoire

Pour exécuter une commande sur le résultat

find -maxdepth 2 -empty -type d -delete

Attention, il n’y a pas de confirmation, d’où l’intérêt de tester sans l’option -delete avant

D’autres exemples de commandes

Donne la liste des fichiers de « /etc » ayant été modifiés ces dernières 24 heures :

find /etc -mtime -1

Cette utilisation de ‘find’ permet de supprime (après confirmation) tous les fichiers (sous Unix, GNU/Linux tout est fichiers, le répertoires sons aussi concernées) de « /tmp » n’ayant pas été utilisés depuis plus de 5 jours :

find /tmp -atime +5 -exec rm -ri {} \;

Pour trouver les fichiers de plus de 100 Mo on peux utiliser :

find ~ -size +100M

sign_and_send_pubkey: signing failed: agent refused operation

Mémo de résolution de connexion par clef ssh

 

~$ ssh backup
sign_and_send_pubkey: signing failed: agent refused operation
root@10.109.55.6’s password:

 

sur le client : ~$ ssh-add

permet de voir que les droit sur la clef sont trop large, il faut restreindre les droit sur ce fichier.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0744 for ‘/home/christophe/.ssh/id_rsa’ are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

 

Un simple :

~$ chmod 0700 /home/christophe/.ssh/id_rsa

 

 

Et c’est OK !