Archives par étiquette : aws

Brèves (mai 2019)

Conteneurs Docker

Excellent : après la découverte d’une grosse boulette sur les distributions Alpine Linux, dont les images Docker permettaient l’accès root sans mot de passe (durant 3 ans !), les chercheurs ont poussé leur recherche dans les 1000 images les plus utilisées1. Au total 194 images (sur 1000) sont dans le même cas (root sans mot de passe).

Source

Responsabilité partagée

Bien que n’ayant pas tous les détails, voici un bel exemple d’illustration de ce qu’est la responsabilité partagée, quand on est dans le cloud.

Une base de données non protégée, hébergée chez AWS, a fait fuiter des millions d’informations sur des « influenceurs » d’Instagram2 (qui appartient à Facebook…) y compris des données privées. Or c’est au propriétaire de la base, une société nommée Chtrbox, qu’il appartient de sécuriser sa base de données.

Patch XP et Windows 7

Bien que le support de ces versions de Windows soit théoriquement terminé (au moins pour le grand public), Microsoft a sorti des patchs de sécurité sur ces produits en mai 20193456.

Pourquoi ?

En raison d’une faille de sécurité sur RDP (Remote Desktop Protocol) si grave qu’on redoute un nouveau WannaCry, rien de moins (à savoir un programme malveillant se propageant sous la forme de ver réseau).

Sources

Bastion

Le bastionnage (pas sûr que le terme existe) consiste à créer un bastion pour accéder à vos ressources (informatiques). On les utiliser sur des ressources sensibles par leur positionnement (ex : production), par leur nature (ex : outil de gestion de droits), leur contenu, etc.

Ainsi, personne ne peut (en théorie) accéder à vos ressources sans montrer patte blanche et sans passer par ce bastion, qui peut surveiller et mettre en historique les actions effectuées, filtrer les éléments indésirables, gérer des droits d’accès différenciés, etc.

AWS

  • Création d’un seul VPC ayant 2 sous-réseaux
    • Un premier subnet « privé » routant tout le trafic de son CIDR en local, tout le reste est dirigé vers une Nat Gateway créée dans le subnet suivant (public) ;
    • Un second subnet « public » routant tout le trafic de son CIDR en local, tout le reste est dirigé vers une Internet Gateway ;
    • Enfin une route supplémentaire, associée à aucun des subnets mais directement au VPC, ne route que le trafic local.
  • Création de 3 Security Groups
    • Le 1er permet le trafic sortant HTTP/HTTPS (pour permettre le SSH via l’agent SSM), et n’autorise rien en entrée ;
    • Le 2e permet le trafic entrant sur HTTPS uniquement et autorise tout en sortie ;
    • Le 3e permet tout le trafic en sortie (sans restriction), ainsi que tout le trafic en entrée mais uniquement quand la source est… lui-même (inutile) ?
  • Création d’un Endpoint

Sources