Un ordinateur portable itinérant accédant à une boîte LAMP CentOS - Problèmes de sécurité !

Il y a plusieurs choses que je suggérerais :

• Je commencerais par désactiver tous les services inutilisés (tels que pop3 et imap). Cela réduira considérablement votre surface d'attaque. Si vous devez laisser un service actif, bloquez-le par le pare-feu pour toute source externe.
• De même, pré-remplir l'empreinte de la clé du serveur SSH ou la donner d'une manière ou d'une autre au responsable. Assurez-vous qu'il/elle ne se connectera pas à la machine à moins que l'empreinte ne corresponde réellement, sinon une attaque de type man-in-the-middle peut être réalisée.
• Envisagez d'utiliser sudo au lieu du bon vieux su et limitez ce que le responsable du développement peut faire. N'assouplissez la politique de sécurité que si l'accès est justifié par une raison légitime.

Dans toutes les circonstances éviter FTP. SSH a un support intégré pour le transfert de fichiers, n'utilisez donc pas du tout FTP. Il envoie les informations d'identification (nom d'utilisateur/mot de passe) et les fichiers en clair, de sorte que n'importe qui sur le même réseau peut intercepter toutes les données.

Considérez ceci comme le point de départ de votre voyage amusant : ).

Considérez également les guides fournis par la National Security Agency, les personnes responsables de Security Enhanced Linux. Ils couvrent RedHat (et CentOS) 5.3, Mac, Windows, Solaris. Utilisez le guide à l'adresse suivante : http://www.nsa.gov/ia/_files/ . (Soyez paranoïaque : tapez l'url dans votre navigateur au lieu de suivre les liens).

L'utilisation des listes de contrôle d'accès n'est pas abordée dans le guide. Vous trouverez cela sur . Google "red hat acl. Cela améliore radicalement le contrôle d'accès basé sur *nix en vous donnant beaucoup plus de flexibilité pour autoriser ou interdire l'accès. Il faut un peu de temps pour s'y habituer mais cela en vaut la peine.

"Ports inutilisés" Votre message ne disait pas si vous nécessaire ces applications. Cependant, à moins que cela ne soit absolument nécessaire (c'est-à-dire qu'il n'y ait pas d'autre moyen de le faire), je désactiverais l'accès à tout. Il semble que vous ayez besoin de http et de ssh, mais tout le reste devrait avoir une solution de contournement si vous en avez besoin. (par exemple, mysql est accessible via la ligne de commande après ssh dans la machine. Si vous avez besoin de quelque chose de plus, vous pouvez utiliser le transfert de port SSH, etc.)

Autres considérations :

• Je ne sais pas pour la subversion, mais GIT (contrôle de source distribué) utilise SSH.
• Il existe plusieurs façons d'utiliser transfert de fichiers plus sécurisé que au ftp.
• D'après les études, il est pratiquement garanti que la machine Windows est compromise, donc ne faites jamais entièrement confiance ni à la machine ni à l'utilisateur.
• Si vous avez les ressources matérielles (par exemple, suffisamment de CPU et de RAM, utilisez des virtuelles pour partitionner davantage les services (puis exécutez SELinux sur ces hôtes).
• Le guide de la NSA recommande le pare-feu qui verrouillent les ports. Les autres options sont le rôle propre (c'est-à-dire basé sur le guide de masquage à le Linux Documentation Project).

Si la sécurité physique du système ou des lecteurs est remise en question, envisagez d'utiliser l'option de cryptage LUKS, facile à utiliser, pendant l'installation. Ensuite, il y a la sécurité de la sauvegarde. Bon voyage.

Eric Chowanski

Envisagez d'utiliser un outil de durcissement tel que Bastille . CentOS est essentiellement un RedHat relooké, et en tant que tel, il est compatible binairement, donc pour la plupart, toutes les instructions pour le même numéro de version de RHEL devraient fonctionner pour CentOS.

Une autre bonne ressource spécifique à CentOS est le Protection de l'OS page wiki.

L'analyse la plus approfondie consisterait à suivre l'évolution de la situation de l'UE. Référence CIS .