Astuce #007 : Renforcez la sécurité de vos serveurs Linux

You are currently viewing Astuce #007 : Renforcez la sécurité de vos serveurs Linux

Astuce #007 : Renforcez la sécurité de vos serveurs Linux

La protection des systèmes d’exploitation qui hébergent vos bases de données est une barrière importante contre les attaques.

Un serveur Linux mal sécurisé suffit à compromettre :

  • vos bases Oracle,
  • vos sauvegardes,
  • vos comptes applicatifs,

Les attaques de ces systèmes peuvent provenir

  • Des services inutiles actifs;
  • Des ports ouverts au grand public
  • Des comptes avec des accès sudo

SOLUTION COURANTE

La sécurité de base appliquée dans la plus part des systèmes consiste à:

  1. Mettre un mot de passe fort à l’utilisateur root
  2. Empêcher la connexion par ssh avec root
  3. Activer le parefeu et n’ouvrir que les ports utiles (22, 1521, 9090)
  4. Mettre en place une politique d’expiration du mot de passe

RECOMMANDATION

Vous pouvez aller plus loin en appliquant les règles suivantes:

Appliquez un mot de passe fort à tous les comptes génériques (oracle, grid, admin, etc.)

Ces comptes disposent généralement de privilèges élevés, voire de droits administrateur complets, sur les systèmes, les bases de données ou les applications. Ils permettent ainsi d’accéder aux fonctions critiques (administration, configuration, arrêt/démarrage de services, accès aux données sensibles).
Toute compromission de l’un de ces comptes représente donc un risque majeur, car elle peut entraîner une prise de contrôle totale du système, une altération des données, une interruption de service ou une fuite d’informations sensibles.

Empêchez les connexions SSH des comptes génériques

Les comptes génériques ne doivent pas être utilisés pour établir des connexions interactives. Chaque accès doit être effectué via un compte nominatif avec élévation de privilèges tracée (sudo ou su contrôlé). Cela permet d’assurer la traçabilité et la responsabilité des actions réalisées.

Ouvrez les ports uniquement à des adresses fixes

L’ouverture des ports réseau doit être strictement limitée aux flux nécessaires en provenance d’adresses IP identifiées et de confiance. Toute exposition inutile augmente en effet de manière significative la surface d’attaque du système.

Exemple 1: accès aux ports des bases de données depuis un serveur applicatif et un poste DBA

# firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.10.20" port protocol="tcp" port="1521" accept'
# firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.20.30" port protocol="tcp" port="1521" accept'
# firewall-cmd --reload

Vérifiez que la politique de mot de passe est bien appliquée aux utilisateurs.

Il faut également s’assurer que la politique de sécurité (complexité, durée de validité, verrouillage après échecs) est bien appliquée à l’ensemble des comptes, y compris aux comptes techniques et applicatifs. Des contrôles périodiques doivent être mis en place pour détecter toute non-conformité.

Exemple: Utilisez la commande suivante pour vérifier les utilisateurs qui ont des mots de passe à durée illimitée.

for USER in $(grep home /etc/passwd | cut -d':' -f1)
do
  if [ "$(chage -l $USER | grep 'Password expires' | cut -d':' -f2)" == ' never' ]
 then
   echo $USER
 fi
done

Après avoir évalué les comptes, vous pouvez appliquer des règles de sécurité aux comptes qui n’en ont pas.

for USER in admin test; do chage --mindays 7 --maxdays 90 --warndays 5 $USER; done

Ajoutez des messages d’alerte mentionnant la criticité des serveurs lors des connexions.

Afficher un message d’avertissement indiquant la criticité du serveur, le caractère strictement professionnel de son utilisation et les règles de sécurité en vigueur. Ce message doit rappeler que toute action est susceptible d’être journalisée et auditée.

Exemple de message:

# vi /etc/issue
********************************************************************************
*    Avertissement : l'accès est réservé au personnel autorisé.                *
*    Ce serveur est une infrastructure critique.                               *
*    Toutes les actions sont surveillées et journalisées.                      *
*    Toute connexion non autorisée donnera lieu à des poursuites judiciaires.  *
********************************************************************************

✨ EN BONUS

Privilégiez les connexions à travers un serveur bastion

Centralisez l’ensemble des accès d’administration via un serveur bastion dédié et sécurisé. Ce point d’entrée unique permet de contrôler, de filtrer et de tracer l’ensemble des connexions vers les serveurs critiques, réduisant ainsi la surface d’exposition du système et facilitant les audits de sécurité.

Administrez vos serveurs sur RedHat avec cockpit

Utilisez Cockpit comme interface d’administration centralisée pour les serveurs Red Hat. Cet outil vous permet de superviser l’état des systèmes, de gérer les services, les mises à jour et les utilisateurs, tout en limitant les connexions directes en ligne de commande.

Bloquez l’accès ssh sur le réseau et prenez la main sur le terminal à travers l’interface cockpit.

Interdisez les connexions SSH directes vers les serveurs depuis les réseaux utilisateurs. L’administration se fait via l’interface Cockpit, qui offre un accès sécurisé au terminal et aux fonctions système tout en assurant une authentification contrôlée et journalisée.

Suivez l’historique des connexions utilisateurs

Activez et exploitez les mécanismes de journalisation afin de conserver l’historique des connexions (SSH, Cockpit, élévation de privilèges). Ces journaux doivent être consultables, protégés contre toute altération et, idéalement, centralisés sur une plateforme de logs.

# journalctl -u sshd

Vérifiez bien toutes les zones de votre parefeu.

Contrôlez régulièrement l’ensemble des zones définies dans le pare-feu (dmz, internal, home, trusted, etc.) afin de vous assurer que les règles appliquées sont cohérentes avec l’architecture du réseau et les niveaux de confiance attendus. Toute règle obsolète ou injustifiée doit être supprimée.

#  firewall-cmd --list-all-zones

Limitez le partage des clés de sécurité des comptes

L’utilisation des clés de sécurité, notamment des clés SSH, doit être fortement encadrée, limitée au strict nécessaire et, dans la mesure du possible, évitée au profit de mécanismes d’authentification plus contrôlables et traçables.

  • Mettre en place un contrôle régulier des clés de sécurité afin d’identifier et de supprimer toute clé obsolète ou non justifiée ;
  • définir une procédure formelle de rotation, de révocation et de réinitialisation immédiate des clés en cas de changement ou de suspicion de compromission.

Laisser un commentaire