Dora au pays du kernel debugging

Magazine
Marque
MISC
HS n°
Numéro
22
Mois de parution
octobre 2020
Domaines


Résumé

Après plusieurs années dans le monde de la sécurité informatique il est récurrent d'être confronté aux remarques telles que : « Wow tu bosses sur le kernel Windows, c'est trop cool, mais vachement compliqué quand même ! ». Que nenni, en réalité la documentation est conséquente et le point le plus difficile et rédhibitoire est bien souvent la mise en place d'un Labo permettant d'analyser celui-ci. En bref, cet article vous permettra de vous faire passer pour un super haxxor de ses morts qui dt des KPCR à tour de bras et vous permettra peut-être au passage de demander une augmentation.


1. Dora installe ses machines virtuelles

La première étape est bien entendu d'installer sa ou ses machines virtuelles, en partant du principe qu'on est en 2020, il est conseillé d'utiliser l'outil MediaCreationTool [MCTOOL] que Microsoft nous fournit pour télécharger un ISO en toute tranquillité.

Maintenant que vous utilisiez VirtualBox ou VMWare, je vous invite à créer deux machines virtuelles, les deux exécutant la version x64 de Windows 10 ; pour moi ce sera la version 10.0.18363.592. La première nommée Labo d'où vous effectuerez vos analyses ; la seconde, Target, sera la VM que vous analyserez. La VM Labo nécessitera plus de RAM que la Target, partons sur un ratio de 4Go / 2Go avec chacune 40Go minimum d'espace disque. N'oubliez pas l'activation de VT-x/AMD-V, le passage de l'interface réseau en mode Bridge, l'ajout d'un répertoire partagé monté automatiquement sur Z:, d'afficher les extensions et fichiers systèmes protégés et l'installation des Vbox...

Cet article est réservé aux abonnés. Il vous reste 95% à découvrir.
à partir de 21,65€ HT/mois/lecteur pour un accès 5 lecteurs à toute la plateforme
J'en profite


Articles qui pourraient vous intéresser...

Définissez l'architecture de vos serveurs et installez-les

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

Dans cet article, nous réfléchirons aux besoins de sécurité auxquels nos serveurs devront répondre. Il sera d’ailleurs plus question d’architecture que de serveur personnel. Pourquoi cela ? Car nos besoins vont à coup sûr évoluer dans le temps. L’approche la plus pérenne sera donc de mener une réflexion basée sur des services et non sur un serveur unique. Nous allons aussi nous attacher à assurer la résilience de nos services de base. Nos choix d’architecture auront pour objectif de pouvoir mieux détecter, contrer et éventuellement réparer les dommages causés par une attaque informatique. Nous pourrons par exemple restaurer nos services si un attaquant réussissait à prendre le contrôle du serveur. Notre plan de bataille commencera par la définition des grandes lignes de notre infrastructure, puis par la sélection de nos fournisseurs. Nous déploierons ensuite le serveur avec un premier palier de sécurisation système.

Migrez de iptables vers nftables

Magazine
Marque
Linux Pratique
Numéro
122
Mois de parution
novembre 2020
Domaines
Résumé

Il y a cinq ans, je lisais un premier article sur nftables [1] : l’outil semblait intéressant, mais il n’était pas disponible sur ma machine. En 2019, une distribution majeure, Debian, a basculé sur nftables avec sa version 10 (Buster) [2] : il est donc temps de voir comment migrer du vénérable pare-feu iptables vers son successeur.

Cas pratique sur la sécurisation d'un cluster Kubernetes

Magazine
Marque
MISC
Numéro
112
Mois de parution
novembre 2020
Domaines
Résumé

Cet article présente trois exemples de problèmes de sécurité rencontrés sur des clusters Kubernetes, causés par un manque de maîtrise des applications déployées sur un cluster par ses administrateurs ou par les développeurs des applications s’y exécutant. Nous donnons ensuite des pistes afin de mieux maîtriser et sécuriser ces applications.

Sauvegardez vos données, centralisez vos logs et supervisez votre sécurité

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

Nos serveurs présentent désormais une surface d’attaque réseau maîtrisée et une sécurisation système d’un niveau cohérent avec notre modèle de menaces. De même, le service SSH tournant sur ces serveurs est configuré de manière optimisée. Nous pouvons donc être relativement sereins si nos adversaires sont d’un niveau intermédiaire. Et si malgré toutes ces protections, une attaque comme un rançongiciel réussissait ? Et bien dans ce cas-là, pour l’instant, notre infrastructure serait particulièrement vulnérable. Aucune sauvegarde externalisée. Pas de centralisation des traces. Une supervision sécurité inexistante. Remédions à cette situation afin d’élever le niveau de maturité de la sécurité de notre infrastructure.