Configurer SSL Bump sur Squid 5

La procédure détail comment mettre en place le SSL bump sur squid 5. Le travail se fait sur Ubuntu 20.04. Cela permet de déchiffrer à la volée les requêtes en https afin de permettre leur analyse. Cela est utile dans le cadre professionnel afin de permettre l’analyse anti virus à la volée.

On démarre la procédure en téléchargeant les sources de squid et en préparant la compilation avec les options qui vont bien. Les trois options à ne pas oublier sont : –enable-ssl –with-openssl –enable-ssl-crtd

git clone https://github.com/squid-cache/squid.git && \
cd squid && git branch -r && git checkout v5 && ./bootstrap.sh && mkdir build && cd build && \
../configure --prefix=/opt/squid --with-default-user=proxy --enable-ssl --with-openssl --enable-ssl-crtd --disable-inlined \
--disable-optimizations --enable-arp-acl --disable-wccp --disable-wccp2 --disable-htcp \
--enable-delay-pools --enable-linux-netfilter --disable-translation --disable-auto-locale \
--with-logdir=/opt/squid/log/squid --with-pidfile=/opt/squid/run/squid.pid

La préparation à la compilation est terminée, on peut lancer la compilation, ca peut prendre un peut de temps en fonction de la config de la machine

sudo make && sudo make install

Quand c’est terminé on peut lister les éléments

ls -la /opt/squid

Continuer la lecture de Configurer SSL Bump sur Squid 5

Lancer un script python3 en service

cette procédure est réalisée sous ubuntu 20.04, ca doit fonctionner sous Debian 10 modulo quelques syntaxes qui peuvent varier (non testé). Cette procédure peut être utilisée dans le cas ou on souhaite faire re-démarrer automatiquement un script python3 en cas de crash ou simplement démarrer un script à l’allumage d’un serveur. En cas de reboot le script va démarrer automatiquement en tant que service géré par systemd.

Je pars du principe que vous êtes en root.

On démarrer par créer un fichier de service

nano /etc/systemd/system/monservice.service

Continuer la lecture de Lancer un script python3 en service

Introduction à kubernetes

Qu’est ce que Kubernetes ?

C’est un orchestrateur de container, il permet de d’automatiser le déploiement des applications en container. (Architecture dynamique) Il est open source.
kubernetes va gérer le bon fonctionnement de nos applications via la déclaration d’un « état souhaité » (nombre de CPU, RAM, réplicat ext …)

Avantages :
Vitesse de déploiement, notion de micro service
Capacité à absorber rapidement les changements
Capacité à récupérer rapidement (Perte de l’état souhaité, correction rapide)
Abstraction de la complexité du cluster, charge à l’administrateur de définir l’environnement pour le développeur qui peut se concentrer sur l’application.

Principe de Kubernetes
On va définir notre application kubernetes dans une configuration déclarative (état souhaité ou manifeste). Suite à cela Kubernetes va tout mettre en œuvre pour conserver l’état inscris dans notre déclaration.(Via les objets contrôleurs, qui vont vérifier régulièrement l’état du cluster)
A l’opposé de ce mode de fonctionnement actuellement on travail de façon impérative. (Administration manuel d’un SI, ajout de ressources CPU/RAM ext …)
On va pouvoir interagir avec Kubernetes via son serveur API.

Principe de l’API Kubernetes

Kubernetes est constitué d’une collection de primitives qui représentent l’état du système.
Pour intéragir avec Kubernetes on va passer par l’API RESTful qui s’exécute en HTTP ou HTTPS via le format JSON stocké dans une BDD interne.

Quelques objets de Kubernetes

  • POD : Un seul ou plusieurs container que l’on va déployer comme une « unité »
  • Contrôleur : Permette de maintenir notre cluster dans l’état souhaité
  • Service : Fournisse un point d’accès permanent dans l’application
  • Stockage : Appelé volume, cela permet de stocker les données de façon persistantes

Détail sur les PODS
Un POD est une unité de travail élémentaire (la plus petite pour kubernetes), il peut contenir un ou plusieurs container. Kubernetes va gérer notre POD, pas le container. Il va contenir notre application. Si le container interne au pod disparait, le POD disparait avec lui, même réaction dans le cas d’un POD multi container.
Le travail de Kubernetes sera donc de garder en état de fonctionnement notre POD, il va suivre son état. On va utiliser des sondes d’activité afin de surveiller le bon fonctionnement de notre application, « Liveness Probes ». (Ping vers un serveur WEB par exemple pour vérifier la bonne réponse du serveur WEB dans le POD)

Continuer la lecture de Introduction à kubernetes

Retrouver un mot de passe de wallet bitcoin en bruteforce GPU

L’avantage d’un bruteforce GPU est qu’il est beaucoup plus efficace que par CPU, l’outil présenté ici gère les deux mais je vais ajouter une courte procédure afin d’installer le dépendance pour faire tourner le tout en GPU sous Windows 10 pour une version en X64.

On va utiliser le projet btcrecover.py disponible sur : https://github.com/gurnec/btcrecover

L’outil supporte un grand nombre d’options de récupération qui va d’une seed à une clé privé d’un wallet bitcoin core (wallet.dat)
Dans le billet je vais présenté une procédure pour retrouver une clé privé d’un wallet.dat extrait depuis bitcoin core.
Pour le tuto j’utilise git bash : https://gitforwindows.org/

Continuer la lecture de Retrouver un mot de passe de wallet bitcoin en bruteforce GPU

Ouverture d’un Websocket avec le Framework Meteor sur Bitstamp

Dans ce billet, je présente un code simple côté serveur pour le framework Meteor qui permet d’initialiser une connexion websocket vers le serveur API de Bitstamp pour récupérer l’order book. J’ai re-utilisé le code initiale d’exemple présent sur le site de la plateforme.

Courte procédure de déploiement :

meteor create monprojet
cd monprojet
meteor npm install --save ws
meteor

Le code présenté est côté serveur

Continuer la lecture de Ouverture d’un Websocket avec le Framework Meteor sur Bitstamp

Gestion de Disques Durs avec LVM

LVM se compose de trois éléments :

  • Physical Volumes (PV) – Disques Physiques (ex: /dev/sda, /dev/sdb …..)
  • Volume Groups (VG) – Les volumes Physiques sont assemblés en Volumes groupes (ex: vg0 = /dev/sda + /dev/sdb)
  • Logical Volumes (LV) – Les volumes groups sont divisés en volumes logiques (ex: vg0 divisé en vg0/home, vg0/sauvegarde …..)

Dans cette procédure on va ajouter un nouveau disque dur pour étendre l’espace disque disponible de 30go à 40go.

On commence par lister les volumes physiques disponible

pvs
pvdisplay

On peut à présent lister le VG

vgs
vgdisplay

Continuer la lecture de Gestion de Disques Durs avec LVM

ESXi Explication sur les Vlan

On peut tag de différentes façons des VLAN dans la suite vmware, on peut les nommer de la façon suivante :

  • EST ou ACCESS : pas de configuration côté vswitch, le vswitch récupère le vlan du port physique (donc 1 seul vlan possible)
  • VST ou TRUNK : le vlan est configuré sur le vswitch ou le Port Group, les ports du switch physique sont en mode trunk.(donc multiple vlan possible)
  • VGT : le/les vlans sont configuré directement dans la carte réseau de la machine virtuelle

Continuer la lecture de ESXi Explication sur les Vlan