Tutoriel | Héberger son IA locale avec Ollama et lui apprendre vos données (RAG) sans exploser son serveur !

Article publié le 28 Février 2026

Salut à tous !

Aujourd’hui, on va s’attaquer à un gros morceau, mais on va le faire à notre sauce d’admin sys : proprement, en local, et sans dépendre du cloud.

Vous en avez marre d’entendre parler d’IA tout en sachant que la moindre question posée à ChatGPT envoie vos données internes, vos docs techniques ou les infos de votre boîte directement sur des serveurs aux États-Unis ? Moi aussi.

La bonne nouvelle, c’est qu’héberger son propre LLM (Large Language Model) n’est plus réservé à ceux qui ont 15 000 € à mettre dans un cluster de GPU. Aujourd’hui, on va voir comment déployer Ollama sur une simple VM Linux (un petit 4 vCPUs / 16 Go de RAM fera l’affaire), et surtout, on va voir comment lui injecter vos propres données grâce à la magie du RAG (Retrieval-Augmented Generation).

Accrochez vos ceintures, on va se monter un chatbot souverain et ultra-léger !

1. Ollama : Le « Docker » des modèles d’IA

Si vous savez utiliser Docker, vous savez utiliser Ollama. C’est un outil écrit en Go qui simplifie à l’extrême le téléchargement et l’exécution de modèles d’IA en local. Il gère la RAM, le CPU, et expose même une API REST compatible avec celle d’OpenAI. Que demander de plus ?

Installation

Sur votre distribution Linux préférée (Debian, Ubuntu…), l’installation se fait via un script officiel. Oui, je sais, on n’aime pas trop les curl | bash, mais ici c’est l’outil officiel et il configure tout le service systemd proprement.

curl -fsSL https://ollama.com/install.sh | sh

 

Vérifions que le démon tourne correctement :

systemctl status ollama

 

Télécharger et lancer un modèle

Pour notre VM sans carte graphique, on va éviter les modèles obèses à 70 milliards de paramètres. On va partir sur Gemma 3 (1B) Il est  bluffant et tourne parfaitement sur CPU.

# On télécharge et on lance le modèle interactif
ollama run gemma3:1b

 

Boum ! Vous avez un prompt interactif. Vous discutez avec une IA qui tourne à 100% sur votre machine. Pour sortir, faites un petit /bye.

Par défaut, Ollama écoute sur le port 11434 en local. Vous pouvez tester son API avec un simple curl :

curl http://localhost:11434/api/generate -d '{ "model": "gemma3:1b", "prompt": "Explique-moi ce qu'est un hyperviseur en une phrase.", "stream": false }'

C’est cool, mais ce modèle a un défaut : il ne connaît rien de VOUS. Il ne connaît pas vos procédures internes, ni votre wiki, ni les tarifs de votre boîte. C’est là qu’entre en jeu le RAG.

 

2. Le RAG : Donner un cerveau métier à votre IA

Plutôt que d’essayer de ré-entraîner le modèle avec vos données (le fameux fine-tuning, qui coûte un bras en puissance de calcul et qui est une galère à maintenir), on utilise le RAG (Retrieval-Augmented Generation).

Le concept est brillant de simplicité :

  1. On découpe vos documents (fichiers TXT, PDF, Markdown) en petits morceaux.

  2. On transforme ces morceaux en vecteurs (une suite de chiffres) et on les stocke dans une petite base de données.

  3. Quand l’utilisateur pose une question, on cherche les morceaux de vos documents qui s’en rapprochent le plus.

  4. On envoie ces morceaux à Ollama en lui disant : « Voici des infos de mon wiki interne. Utilise-les pour répondre à cette question : … »

C’est l’équivalent de donner un livre ouvert à un étudiant pendant un examen.

3. Pratique : Le script RAG « Admin-Friendly » (Ultra-Light)

Beaucoup de tutos vous diront d’installer l’usine à gaz LangChain ou le monstrueux PyTorch (qui va vous bouffer 4 Go d’espace disque). Sur Journal d’un admin Linux, on aime quand c’est slim.

On va écrire un script Python qui n’utilise que l’API de notre serveur Ollama (pour la génération ET pour la vectorisation) et une minuscule base de données appelée ChromaDB.

Les prérequis

Sur votre machine, on télécharge un modèle spécialisé d’Ollama (minuscule et ultra-rapide) pour créer nos vecteurs :

ollama pull nomic-embed-text

 

Puis on installe les deux seules dépendances Python nécessaires :

pip3 install requests chromadb

 

Vos données

Créez un fichier wiki_interne.txt avec quelques infos factices pour le test :

Serveur d’impression : L’IP du serveur d’impression de l’étage 2 est 192.168.1.50. Il faut utiliser le driver générique PCL6.
VPN : Pour se connecter au VPN de l’entreprise, le port utilisé est le 1194 en UDP. Le certificat doit être renouvelé tous les ans.
Serveur Web : Notre site principal tourne sous Nginx sur le serveur SRV-WEB-01 (Debian 12).

Le Script Python : rag_local.py

Voici notre script fait maison. Il est agnostique, rapide, et ne fait pas exploser la RAM.

import requests
import chromadb
import argparse

# --- CONFIGURATION ---
URL_OLLAMA = "http://localhost:11434"
MODEL_IA = "gemma3:1b"          # Modèle qui rédige la réponse
MODEL_VECTEUR = "nomic-embed-text" # Modèle qui lit le document

def get_embedding(text):
    """ Demande à Ollama de transformer le texte en suite de nombres (vecteurs) """
    res = requests.post(f"{URL_OLLAMA}/api/embeddings", 
                        json={"model": MODEL_VECTEUR, "prompt": text})
    return res.json()["embedding"]

def interroger_mon_ia(question, fichier_txt):
    try:
        # 1. On charge notre fichier de doc interne
        with open(fichier_txt, 'r', encoding='utf-8') as f:
            contenu = f.read()
        
        # On découpe grossièrement par paragraphes
        paragraphes = [p.strip() for p in contenu.split('\n') if len(p.strip()) > 10]

        # 2. Création de notre base de données vectorielle (en RAM pour la vitesse)
        db_client = chromadb.Client()
        collection = db_client.get_or_create_collection(name="mon_wiki")

        # 3. On injecte nos paragraphes dans la base via Ollama
        print(f"[*] Indexation de {len(paragraphes)} blocs de texte en cours...")
        for i, texte in enumerate(paragraphes):
            vecteur = get_embedding(texte)
            collection.add(ids=[str(i)], embeddings=[vecteur], documents=[texte])

        # 4. Recherche magique : on trouve les infos liées à la question !
        vecteur_question = get_embedding(question)
        resultats = collection.query(query_embeddings=[vecteur_question], n_results=1)
        contexte_trouve = "\n".join(resultats['documents'][0])

        # 5. On demande à l'IA de faire une synthèse avec NOS infos
        prompt = (
            f"Tu es un admin sys expert. Utilise UNIQUEMENT le contexte ci-dessous pour répondre.\n"
            f"CONTEXTE INTERNE :\n{contexte_trouve}\n\n"
            f"QUESTION : {question}\n\n"
            f"RÉPONSE :"
        )

        res_ia = requests.post(f"{URL_OLLAMA}/api/generate", 
                               json={"model": MODEL_IA, "prompt": prompt, "stream": False})
        
        return res_ia.json().get('response', 'Erreur de génération')

    except Exception as e:
        return f"Erreur critique : {str(e)}"

# --- EXÉCUTION ---
if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Interrogez vos docs locales avec l'IA")
    parser.add_argument("question", type=str, help="Votre question")
    parser.add_argument("-f", "--fichier", type=str, default="wiki_interne.txt", help="Fichier source")
    args = parser.parse_args()

    reponse = interroger_mon_ia(args.question, args.fichier)
    print(f"\n[RÉPONSE DE L'IA] :\n{reponse}")

Il ne reste plus qu’à poser une question ultra-spécifique à notre script depuis le terminal :

python3 rag_local.py "Sur quel port tourne notre VPN ?"

Sortie :

[*] Indexation de 3 blocs de texte en cours...

[RÉPONSE DE L'IA] :
1194 en UDP !

💥 Bim ! L’IA ne vous a pas fait une réponse générique copiée sur Wikipédia, elle a lu votre fichier de configuration et vous a répondu avec vos données. Le tout sans qu’un seul octet n’ait quitté votre serveur en bare-metal ou votre VM.

Conclusion

L’association d’Ollama (pour l’inférence) et d’un petit script Python avec ChromaDB (pour le RAG) est une véritable tuerie. C’est robuste, ça consomme peu de ressources disque par rapport aux grosses stacks d’IA habituelles, et ça ouvre la porte à des dizaines d’usages :

  • Un chatbot d’entreprise qui interroge vos logs ou vos manuels de procédures.

  • Une API (en rajoutant un peu de FastAPI par dessus) pour le support IT interne.

  • Une solution d’IA à proposer à vos clients, sans les soucis liés au RGPD !

Et vous, vous l’hébergez où votre IA ? Dites-le-moi en commentaire ou venez en discuter avec nous sur le réseau !




Tutoriel | Dokploy : Le PaaS qui veut réconcilier l’Admin Linux avec le déploiement moderne

Article publié le 19 Janvier 2026

 

À l’heure où les notions de cloud souverain et d’écosystème « Auto-hébergé » reviennent en force, utiliser Dokploy sur votre infrastructure « on-premise » devient de plus en plus pertinent.

Dokploy est une solution open source qui permet de déployer en 10 minutes un PaaS sur des serveurs classiques, qu’ils soient sur votre cloud privé ou chez un cloud provider public (AWS, GCP ou Azure).

 

1) Installation

Pour ce tuto, j’ai utilisé une VM sous Debian 12 avec 4 vCPU et 16 Go de RAM afin d’être peinard.

L’installation est une formalité, même pour un admin débutant. Il suffit d’exécuter ce script avec l’utilisateur root :

sudo curl -sSL https://dokploy.com/install.sh | sh

 

Que fait ce script?

  • Vérification des dépendances : Il installe curl, sudo et git.

  • Setup Docker : S’il n’est pas présent, il installe Docker Engine.

  • Swarm Mode : Il exécute docker swarm init (si ce n’est pas déjà fait). C’est crucial car Dokploy utilise les services Swarm pour la gestion du réseau. (Même si je ne suis pas fan de Docker Swam il faut admettre que c’est bien pratique)

  • Pull & Run : Il télécharge l’image Docker de Dokploy et lance le service.

Une fois terminé, vérifiez que l’interface web est dispo sur le port 3000 et enregistrez votre premier utilisateur.

 

Sous le capot, un petit docker ps -a vous confirmera que tout tourne proprement.

 

2) Prise en main

Nous voici sur l’interface d’admin qui me parait fort sympathique. On est loin des usines à gaz surchargées : ici, c’est propre, sombre (le mode Dark par défaut, merci pour nos yeux d’admin) et surtout très structuré.

Voici ce qu’on retrouve dans la barre latérale et qui va devenir notre quotidien :

Le pilotage opérationnel (Home)

C’est ici que l’on gère le « Run ».

  • Projects : C’est le cœur du réacteur. On y crée des groupes pour nos apps (par exemple « Prod », « Staging » ou « Blog »).

  • Monitoring & Schedules : Pour garder un œil sur la charge CPU/RAM et gérer les tâches cron sans avoir à éditer la crontab du host à la main.

  • Traefik File System & Docker/Swarm : La partie que j’apprécie particulièrement. Dokploy ne vous cache rien. Vous avez un accès direct aux fichiers de config du reverse proxy et à l’état de votre cluster Swarm. C’est transparent.

La configuration fine (Settings)

C’est là qu’on sent que l’outil est pensé pour la prod « on-premise » :

  • Remote Servers & Cluster : Dokploy n’est pas limité à un seul nœud. On peut piloter d’autres serveurs et gérer son cluster directement depuis cette interface.

  • Registry & S3 Destinations : Indispensable ! On peut lier son propre registre Docker et surtout configurer ses backups de bases de données vers du S3 (AWS, Minio ou autre).

  • Certificates : La gestion du SSL (Let’s Encrypt) est automatisée, mais vous pouvez aussi importer vos propres certificats si vous avez des contraintes de sécurité spécifiques.

Le petit plus : L’onglet AI

On notera la présence d’un menu AI. À l’heure actuelle, cela permet de configurer un modèle (type OpenAI) pour vous aider à générer des Dockerfiles ou des fichiers de configuration si vous avez un trou de mémoire sur une syntaxe. Gadget pour certains, gain de temps pour d’autres.

3) Déploiement d’un workload.

On va maintenant déployer un site wordpress via Dokploy pour voir comment tout cela fonctionne:

3.1) Déploiement de la base de données

– Créons un projet en cliquant sur « Create Project » depuis l’onglet « Projects »:

– Une fois le projet créé, nous allons déployer ce dont nous avons besoin pour faire tourner un site wordpress: une application et une database

– Commencons pas la base de donnée: cliquez sur « service » et « database. »

Comme vous pouvez le voir, l’éventail de choix est large ; pour ce tuto, nous partons sur une base MySQL. Remplissez simplement les champs de configuration et validez en cliquant sur « Create ».

 

Il ne reste plus qu’à déployer la base de données en cliquant sur le bouton « Deploy »

C’est beau!!

En vérifiant on peut peut voir que le container est bien démarré (1er ligne)

 

3.) Déploiement de WordPress

Ca repart, on crée un nouveau service de type application que l’on va nommer « website »:

On clique sur le service que l’on vient de créer pour le configurer :

Arrétons nous un instant pour rentrer dans le détail de cette interface de configuration:

C’est ici que la magie du PaaS opère. Une fois votre projet créé (ici je l’ai nommé « WordPress »), on rentre dans le vif du sujet avec la configuration de notre service. L’interface de déploiement est un modèle du genre : complète mais sans fioritures.

Le pilotage du déploiement

En haut de page, on retrouve nos commandes de vol habituelles : Deploy, Reload, Rebuild ou encore Start. Mention spéciale pour le bouton Open Terminal qui permet de garder un pied dans le conteneur sans quitter son navigateur. On peut aussi activer l’Autodeploy pour que chaque push sur votre branche déclenche la mise à jour, ou forcer un Clean Cache si vous avez des doutes sur votre build.

Le choix de la source (Provider)

Dokploy est très souple sur l’origine du code :

  • Git pur jus : Intégration directe avec GitHub, GitLab, Bitbucket ou même une instance Gitea auto-hébergée (cohérent avec notre approche souveraine).

  • Docker : Vous pouvez aussi simplement tirer une image depuis un registre Docker.

  • Drop : Pour les plus pressés, on peut même envoyer directement un fichier.

La cuisine interne : Build Type

C’est là que l’admin va pouvoir choisir sa méthode préférée pour transformer le code en conteneur :

  • Dockerfile : Pour ceux qui aiment garder le contrôle total sur leur image.

  • Nixpacks (par défaut) : C’est l’option moderne qui analyse votre code et crée l’image optimale tout seul.

  • Heroku/Paketo Buildpacks : Pour rester compatible avec les standards du marché.

Petit conseil d’admin : Comme indiqué par l’alerte dans l’interface, le build peut être gourmand en ressources (CPU/RAM). Avec mes 16Go de RAM, je suis large, mais gardez un œil sur vos petites instances lors des phases de compilation.

On retrouve également des onglets cruciaux pour la prod : Environment pour vos variables secrètes, Domains pour le mapping DNS avec SSL automatique, et Volume Backups pour ne pas oublier que la donnée, c’est sacré.

 

Pour notre usecase nous allons déployer une image wordpress depuis le docker hub, pour cela cliquez sur le provider Docker:

Faisons un petit tour dans l’onglet environnement pour renseigner les informations de connexions à la base de donnée que nous venons de créer juste avant (cliquez sur le petit oeil en haut à droite pour activer le mode édition):

Cliquez sur « save »

L’astuce de sioux : Accéder au site sans DNS avec sslip.io

C’est le moment où l’admin a fini sa conf et veut voir le résultat, mais n’a pas forcément envie d’aller modifier ses zones DNS chez son registrar pour un simple test.

C’est là qu’intervient sslip.io. Pour ceux qui ne connaissent pas, c’est un service de « DNS Wildcard » génial : il résout n’importe quel nom de domaine contenant une adresse IP vers cette même adresse IP.

  • Si vous tapez 13.42.26.29.sslip.io, le service vous renvoie vers 13.42.26.29.

  • Pas de configuration, pas d’attente de propagation. C’est instantané.

La marche à suivre dans Dokploy :

Cliquez sur domain et « Add Domain »

Comme vous le voyez sur ma capture, la configuration est un jeu d’enfant :

  1. Host : On renseigne l’IP de notre VM suivie de .sslip.io (dans mon cas : 13.42.26.29.sslip.io).

  2. Container Port : Attention ici ! C’est le piège classique. Dokploy propose souvent le port 3000 par défaut. Mais notre image WordPress officielle, elle, écoute sur le port 80. Il faut donc impérativement changer cette valeur pour que Traefik sache où envoyer le trafic à l’intérieur du conteneur.

  3. HTTPS : Pour un test rapide sur sslip.io, on peut le laisser décoché. Si vous voulez du SSL, Traefik tentera de le générer, mais Let’s Encrypt peut parfois tiquer sur les domaines en sslip.io.

Une fois que c’est validé, on retourne dans l’onglet General, on clique sur Deploy, et on laisse la magie opérer.

Maintenant testons l’accès à l’interface de Wordpres:

 

Ca fonctionne!!

 

4) Le mot de la fin : Dokploy, on valide ou pas ?

Alors, après ce tour d’horizon, quel est le verdict pour un admin habitué à gérer ses propres serveurs ?

Soyons honnêtes : le « tout en ligne de commande », ça a son charme et c’est formateur. Mais à l’heure où l’on doit multiplier les environnements de test, les sites clients ou les outils de monitoring, on ne peut plus se permettre de passer 2 heures à configurer un reverse proxy ou à débugger un certificat SSL récalcitrant.

Dokploy réussit son pari : offrir une expérience PaaS moderne (le fameux « Heroku-like ») sans nous enfermer dans un cloud propriétaire. On garde nos données, on garde notre OS (Debian 12 dans mon cas), et surtout, on garde le contrôle sur ce qui tourne.

Ce qu’il faut retenir :

  • C’est rapide : L’installation « One-liner » et le déploiement via sslip.io permettent de voir son projet en ligne en quelques minutes.

  • C’est propre : On s’appuie sur des standards (Docker Swarm, Traefik, Nixpacks) que l’on peut auditer.

  • C’est souverain : Que votre VM soit chez vous, chez un hébergeur local ou sur un gros cloud public, c’est vous qui avez les clés du camion.

Mon conseil : Si vous avez une petite grappe de VPS qui traîne ou un serveur dédié qui ne demande qu’à être optimisé, testez Dokploy. C’est une excellente alternative à Coolify pour ceux qui cherchent une interface peut-être un peu plus légère et réactive.

Le cloud souverain ne se fera pas sans outils simples pour les admins. Dokploy est clairement un pas dans la bonne direction.




vim: Impossible de copier coller dans Debian Stretch

Article publié le 17 Avril 2018

 

Certains l’auront remarqué, depuis debian 9 (stretch), il est par défaut impossible de faire un copier coller depuis un terminal en utilisant vim.

Afin de résoudre ce petit désagrément, il suffit d’éditer le fichier /usr/share/vim/vim80/defaults.vim et de modifier la ligne suivante:

if has (‘mouse’)

set mouse=a

endif

 

par:

if has (‘mouse’)

set mouse=r

endif

 

 

 




Mettre à jour Debian 8 Jessie vers Debian 9 Stretch

Article publiée le 19 Juin 2017

Pour ceux qui l’ignore encore, une nouvelle version de debian est disponible en version final depuis le 17 Juin 2017.

Ci-dessous la liste des nouveautés (Sources : https://www.debian.org):

 

  • Apache 2.4.25
  • Asterisk 13.14.1
  • Chromium 59.0.3071.86
  • Firefox 45.9 (in the firefox-esr package)
  • GIMP 2.8.18
  • an updated version of the GNOME desktop environment 3.22
  • GNU Compiler Collection 6.3
  • GnuPG 2.1
  • Golang 1.7
  • KDE Frameworks 5.28, KDE Plasma 5.8, and KDE Applications 16.08 and 16.04 for PIM components
  • LibreOffice 5.2
  • Linux 4.9
  • MariaDB 10.1
  • MATE 1.16
  • OpenJDK 8
  • Perl 5.24
  • PHP 7.0
  • PostgreSQL 9.6
  • Python 2.7.13 and 3.5.3
  • Ruby 2.3
  • Samba 4.5
  • systemd 232
  • Thunderbird 45.8
  • Tomcat 8.5
  • Xen Hypervisor
  • the Xfce 4.12 desktop environment

 

Ci-dessous la procédure pour mettre à jour votre Debian Jessie:

  • Vérifiez que votre OS est à jour

apt-get update && apt-get upgrade

  • On remplace les dépôts Jessie par les dépôts Stretch

sed -i ‘s|jessie|stretch|’ /etc/apt/sources.list && apt-get update

  • Si vous avez message d’avertissement concernant une clé:

  • Installez le paquet suivant:

apt install debian-archive-keyring

  • Enfin  vous pouvez lancez la mise à niveau

apt-get dist-upgrade

  • Une fois la mise à niveau terminée, redémarrez votre machine puis vérifiez que tout c’est bien passé:

Enjoy!

 

 




Vérifiez la sécurité de votre site wordpress avec WPSeku

Article publiée le 02/06/2017

Plus de 74 millions de sites tournent sous WordPress dans le monde. Malheureusement ce CMS est très facilement piratable ce qui fait qu’il y a énormément de site wordpress piraté dans le monde. WordPress représente à lui tout seul une faille de sécurité si celui ci n’est pas géré correctement (mise à jour régulière de wordpress et des plugins installés, vérification de la provenance des plugins, etc…) et ceux, même si vous sécurisez convenablement votre serveur (apache, OS etc…)

Après quelques recherches, j’ai trouvé un super outil développé en PYTHON permettant de faire un audit de sécurité complet d’un site wordpress: WPSEku.

Comme vous pouvez le voir sur la capture d’écran ci-dessus, ce petit script est riche en fonctionnalités.

Un grand merci au développeur pour son travail !

Ci-dessous le lien git

https://github.com/m4ll0k/WPSeku

En cas de message d’erreur lors de l’exécution de ce script, vérifiez l’installation des librairies Python nécessaire pour la bonne exécution de ce script comme python-request.

Inutile de tester cet outil sur mon site, vous risqueriez d’avoir votre IP blacklisté et de ce fait ne plus pouvoir accéder à mon blog ;-))




Tutoriel | chiffrer et déchiffrer avec GnuPG

Article publié le 10 Octobre 2016

Petit tuto très simplifié sur comment chiffrer/dechiffrer des fichiers avec GnuPG.

– Démarrez l’agent gnugpg:

gpg-agent –daemon –use-standard-socket

 

– Authentifiez vous sans utiliser sudo mais en vous connectant directement avec le compte UNIX souhaité.
– Générez votre clé privée (de préférence sur une machine sûre):

gpg -gen-key

 

– Renseignez les informations demandées par l’invite de commande. Si la génération de votre clé prend trop de temps, utilisez la commande ci-dessous

rngd -r /dev/urandom

– Générez votre clé de révocation (au cas ou)

gpg –output revoke.asc –gen <id de votre clé>

– Vérifiez que votre clé a bien été généré

gpg –list-keys

– Exportez votre clé publique qui sera nécessaire pour chiffrer / déchiffrer (la clé public devra être envoyé au destinataire afin qu’il puisse
déchiffrer le contenu).

gpg –output mykey.asc –armor –export <id de la clé>

– Une fois la clé reçu par le destinataire celui ci devra signer la clé

gpg –sign-key <id de la clé>Chiffrement / Déchiffrement

– Procédez au chiffrement de votre fichier

gpg –recipient « <identifiant de votre clé  » –encrypt –cipher-algo AES256 <votre fichier>

– Le destinataire pourra alors déchiffrer votre fichier avec la clé publique précédemment envoyée

gpg –decrypt <fichier>.gpg




Testez la configuration SSL de vos serveurs avec ssllabs

Article publiée le 23 Mai 2016

 

Depuis pas mal de temps je bosse sur la configuration SSL des serveurs web. Ayant rejoint une entreprise dont la préoccupation sur la sécurité est forte j’ai pu connaitre l’existence de petits outils permettant de faire un check complet de la configuration SSL (HTTPS) de votre site Web.

Cet outil est vraiment bien et peu notamment vous servir en cas d’audit pour prouver que la configuration de vos serveurs web est sérieuse.

1) Qualys SSL LABs

Le plus connu et réputé Qualys SSLLABS. Via cette page web vous pouvez avoir un diagnostic complet de votre site avec une note ainsi que des indications sur ce qui peut être amélioré:

2) API SSL Labs

Pour ceux qui sont vraiment à fond dans la configuration SSL de leurs serveurs web, je leur propose une petite solution afin d’automatiser les checks de leurs site. Pour ma part un script va vérifier chaque jour que les serveurs webs de mon employeur aient la note A+.

Afin d’éviter de réinventer la roue, un petit outil opensource en ligne de commande existe:

https://github.com/ssllabs/ssllabs-scan

Ci dessous la procédure pour l’installer

  • Téléchargez le package
  • Assurez vous d’avoir les outils de compilations (make, gcc etc…), pour les utilisateurs de Debian faites un « apt-get install build-essential » et vous serez tranquille 😉
  • Assure vous également que golang-go soient installé:
    • Sous debian: apt-get install golang-go
    • RedHat/Centos: Installez les dépots EPEL  et installez le paquet golang (yum install epel-release && yum install golang)
  • Enfin il ne vous reste plus qu’à compiler avec la commande « make » à la racine du répertoire contenant les sources de ssllabs-scan
  • Enfin lancer le binaire ssllabs-scan <URL>:
  • Une fois l’exécution terminée un fichier avec le résultat complet de votre test sera créé.

3) Scripts d’automatisations

Enfin, j’ai conçu un petit script permettant de monitorer automatiquement la note et d’envoyer une alerte si jamais la note que vous désirez et inférieur.

#!/bin/bash

BASEDIR=$(dirname $(readlink -f $0))

SSL_LABS_BINARY=$BASEDIR/bin/ssllabs-scan
SSL_LABS_CONF=$BASEDIR/conf/hosts.conf
SSL_LOGS_DIR=$BASEDIR/logs

unset HTTP_PROXY

if [ ! -f $SSL_LABS_BINARY ] || [ ! -f $SSL_LABS_CONF ]; then
echo « ERREUR: Arret du script, l’un des fichiers n’est pas présent »
exit 1
fi

if [ ! -d $SSL_LOGS_BINARY ]; then
mkdir $SSL_LOGS_DIR
fi

audit_securite ()
{
LOGNAME= »`date +%Y%m%d` ».log
$SSL_LABS_BINARY –hostfile $SSL_LABS_CONF >> $SSL_LOGS_DIR/$LOGNAME
if [ $? -eq 0 ]; then
echo « Rapport de securite généré et disponible dans $SSL_LOGS_DIR/$LOGNAME »
else
echo « Erreur durant la génération du rapport » >> $SSL_LOGS_DIR/$LOGNAME
mail -a « from:ssllabs » -s « Erreur de génération du rapport SSLLABS » [email protected] <<< ‘Bonjour, une erreur a été detectée durant la génération quotidienne du rapport SSLLABS.’
exit 1
fi
}

rapport_securite ()
{
LOGNAME= »`date +%Y%m%d` ».log
RAPPORT_TEMP=$(grep ‘grade’ $SSL_LOGS_DIR/$LOGNAME | grep -v ‘gradeTrustIgnored’)
NOTE_FINALE=$(echo $RAPPORT_TEMP | cut -d « : » -f2 | cut -c3-4)

if [ « $NOTE_FINALE » != « A+ » ]; then      # Changer ici pour la note désirée
mail -a « from:ssllabs » -s « WARNING : NOTE SSLLABS INFERIEURE A A+ » [email protected] <<< ‘Bonjour, la note SSLLABS est inferieure a A+, Merci de verifier la conf Apache !’
fi
}

audit_securite
rapport_securite

Dans le fichier hosts.conf, indiquez juste l’URL du site que vous voulez monitorer

 




Historiser (logguer) toutes les commandes shell avec snoopy dans un fichier log

Article publié le 31 Mars 2016

L’un de mes premiers tuto a été de proposer une solution pour « historiser qui a tapé telle commande et quand »  dans une base Mysql en patchant et recompilant le bash.

(http://journaldunadminlinux.fr/loggue-toutes-les-commandes-executees-dans-une-base-mysql/).

Depuis j’ai découvert une autre solution certes moins aboutie mais beaucoup plus facile à mettre en place: snoopy.

Snoopy va logger chaque commande tapée par un utilisateur dans un fichier de log (par défaut /var/log/auth.log).

 

Téléchargez les sources de snoopy ici: http://source.a2o.si/download/snoopy/

Décompressez-les ensuite avec un tar -xvf <nom de votre archive>

Nous allons procéder à la compilation (assurez vous que gcc et make soient bien installées)

./configure && make && make install && make enable

(il est possible que la compilation plante à cause d’un prérequis manquant: socat. Si c’est le cas, installez-le: apt-get install socat (Sous Debian/Ubuntu)  ou yum install socat (Sous Redhat/Centos)

Ouvrez la log (vi /var/log/auth.log) et vous pourrez voir les entrées Snoopy loguant les commandes tapées par les utilisateurs connectés sur votre machine:

 

Enjoy 🙂

 




Retrouver la commande ifconfig | « ifconfig command not found for RedHat & Centos 7 »

Article publiée le 2 Février 2016

Je pense que tout le monde l’a remarqué:  sous Centos7 / RedHat 7 la commande « ifconfig » n’existe plus!  Eh oui hélas, celle ci est considéré comme obsolète par la communauté… Quelle chamboulement dans nos habitudes!

Désormais vous devez utiliser la commande « ip addr » pour afficher vos interfaces:

Pour voir les statistiques utilisez la commande « ip link »

 

Bon si vous n’arrivez vraiment pas à vous y faire il est toujours possible de réinstaller la commande « ifconfig »!

Il vous suffit pour cela d’installer le package « net-tools »:

yum install net-tools:

La commande ifconfig sera de nouveau disponible:




Astuces | Améliorez l’historique de votre shell avec .inputrc

Article publiée le 23 Décembre 2015

Ci-dessous une petite astuce fort sympatique afin d’améliorer considérablement votre terminal:

  • Créez ou éditez le fichier /home/<votre user>/.inputrc.
  • Ajoutez y les lignes suivantes:

« \e[A »: history-search-backward
« \e[B »: history-search-forward
set show-all-if-ambiguous on
set completion-ignore-case on

 

 

  • bind -f /home/<votre user>/.inputrc

Relancez votre terminal (ou établissez une nouvelle connexion SSH) et vous pourrez désormais effectuer des rechercher par commande dans votre historique en tapant le nom de la commande + flèche haut/flèche bas.

 

Votre autocomplétion ne sera plus case sensitive (ignore la majuscule/minuscule)

 

 




Tuto | Protection contre les rootkits avec RKHunter

Article publiée le 7 Décembre 2015

Rkhunter ou RootKit Hunter est un outil absolument génial permettant de détecter sur votre serveur les rootkit, portes dérobées, exploit.

Pour l’installer sous debian : apt-get install rkhunter

Pour l’installer sous Centos/RedHat: yum install rkhunter

 

Une fois  rkhunter installé,  nous allons le mettre à jour:

rkhunter –update

Vous pouvez maintenant lancer un scan manuel avec la commande rkhunter -c.

RKhunter va alors faire un scan très complet de votre système:

 

 

Si vos serveurs sont considérées comme sensible (serveurs à risque), je vous conseille de planifier des checks  automatiques (via Cron).

enjoy 🙂




Tutoriel | Sécurisez son accès SSH

Article publiée le 6 Décembre 2015

Cela m’arrive très souvent d’être horrifié en voyant des serveurs « publiques » dont l’accès SSH n’est pas du tout sécurisé.

Pourtant quelques actions très simple permettent d’éviter tout désagréments!

Ci-dessous un petit tuto très simple expliquant comment sécuriser l’accès SSH d’un serveur:

1) Changer le port SSH

Tout le monde sait que le port SSH par défaut est le port 22, même les hackers… Le fait de juste changer le numéro du port SSH peut mettre à mal un très grand nom de script automatique de hacking…

Pour changer le port il suffit d’éditer le fichier /etc/ssh/sshd_config et de changer le numéro de port (sans oublier de redémarrer le service SSH):

 

2) Privilégiez impérativement l’authentification par clé

  • Procédez à la génération des clés: ssh-keygen

  • Éditez le fichier /root/.ssh/authorized_keys (ou /home/votreuserquiseconnecteenssh/.ssh/authorized_keys) et ajoutez y les clés publiques des users ayant le droit de se connecter en root  sur votre machine (clé publique contenue dans le fichier ayant l’extension .pub ou qui peut-être générer depuis l’outil puttygen sous Windows)

 

 Cette manipulation est à faire pour chaque user qui aura les accès SSH sur votre serveur (si le nom du user est toto votre arborescence ssh sera /home/toto/.ssh)

  • Paramétrez SSH pour qu’il n’accepte que des authentifications par clé SSH, pour cela éditez le fichier /etc/ssh/ssd_config et modifiez les paramètres comme indiqués ci-dessous (dé-commentez les lignes si elles le sont) :

PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keysPermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
KerberosAuthentication no
KerberosGetAFSToken no

KerberosOrLocalPasswd no
KerberosTicketCleanup no

GSSAPI options
GSSAPIAuthentication no

  • Je vous conseille également d’interdire la connexion avec le user root (autorisation de vous connecter uniquement avec les autres users):

PermitRootLogin no

  • Redémarrez le service SSH: /etc/init.d/sshd restart

 

3) Alertes Mails

Et si l’on veut être encore plus parano on peut configurer un alerting mail à chaque connexion d’un user:

  • Editez votre fichier .bashrc : vi /root/.bashrc ou /home/<user>/.bashrc
  • Ajoutez la ligne suivante dans votre fichier: echo ‘Connexion détecté ‘ `date` `who` | mail -s `hostname` Connexion du USer `who | cut -d« («  -f2 | cut -d« ) » -f1` [email protected]

3) Protégez votre serveur contre les DOS (déni de service) avec Fail2ban

Et enfin, pour finir en beauté, je vous propose de sécuriser votre serveur avec fail2ban qui protégera votre machine contre les attaques DOS (déni de service) ou brutforce

Tuto disponible via ce lien:

http://journaldunadminlinux.fr/tutoriel-protegez-votre-serveur-avec-fail2ban

 

Je pense qu’après ça votre accès SSH sera beaucoup mieux protégé! 🙂




Tutoriel | Protégez votre serveur avec fail2ban

Article publiée le 6 Décembre 2015

Fail2ban est un outil développé en Python.Cette outil vous permettra de parser vos logs à la recherche de tentatives d’attaques brut force ou DOS et de bloquer au bout d’un certain nombre d’essais l’IP concernée. Fail2ban fonctionne avec tout les services courants: ssh, apache, etc…

1)  Installation

Sous Debian :apt-get install fail2ban

Sous RedHat/Centos: Fail2ban n’est pas disponible via les dépôts officiels. Vous devez ajouter les dépots EPEL pour pouvoir l’installer via yum:

wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm && rpm -ivh epel-release-7*.rpm && yum install fail2ban

 

2) Configuration

Pour notre exemple de configuration nous allons sécuriser notre service SSH avec fail2ban:

  • Éditez le fichier /etc/fail2ban/jail.conf:

Ce fichier permet de paramétrer le comportement de fail2ban par rapport à un service donnée.

Dans notre cas nous allons bloquer au bout de 3 essais les tentatives de connexions infructueuses via SSH à notre machine:

Explications:

enabled: active ou non la protection

port: Le protocole concerné

filter: indique le nom du filtre qui va parser (mots ou suite de mots qui seront recherché) les logs

logpath: indique le chemin de la log à parser:

maxretry: le nombre maximums d’essais.

 

Il ne reste plus qu’à redémarrer le service fail2ban: service fail2ban restart

 

3) Autre configurations

Pour ignorer une IP (non soumis aux blocages de fail2ban):

  • Editez le fichier jail.conf et ajouter les IP ou les plages d’adresses IP dans la partie « ignoreip = »

Pour paramétrer le temps de bannissement

  • Éditez le fichier jail.conf et indiquez le temps de bannissement avec le paramètre « bantime »

Pour ajouter ou configurer des parsers de logs (filter):

 

  • Vous pouvez ajouter ou modifier des parsers de logs grâce aux fichiers de configuration situés dans le répertoire /etc/fail2ban/filter.d

Si nous ouvrons sshd.conf nous pourrons voir la configuration du parser:

Enjoy 🙂




Debian 8: Connexion root impossible en ssh (connection refused)

Article publiée le 29 Novembre 2015

Depuis la sortie de Debian 8 il est impossible de se loguer en root en SSH via l’authentification par mot de passe

Pour moi c’est une best practice . Je recommande fortement de garder cette configuration est de privilégier l’utilisation de clé publie/clé privée pour vous loguer en root via SSH.

 

Cependant, je sais que cela peut en rebuter plus d’un c’est pourquoi je vous donne ci-dessous la marche à suivre pour réactiver l’authentification par mot de passe:

Éditez le fichier de configuration: /etc/ssh/sshd_config et remplacez la ligne contenant « PermitRootLogin without-password » par « PermitRootLogin yes »

Redémarrez ssh:

/etc/init.d/sshd restart




Comprendre les commandes SHELL avec explainshell

Article publiée le 24 Avril 2014

 

Toujours dans ma foulé des outils de scripting SHELL je vous  propose aujourd’hui un super outil qui s’appelle ExplainShell.

Ce site accessible depuis une interface web via l’url : http://explainshell.com/  vous explique la signification des commandes shell les plus complexes.

Finit les longs moment de solitudes devant un script SHELL conçu par un de vos collègue utilisant des commandes incompréhensible !!! 🙂

 

 

 

Enjoy!

 

 

 

 

 

 




Vérifier vos scripts Shell avec ShellCheck

Article publiée le 16 Avril 2014

 

Une petite découverte forte sympathique!

Un collègue vient de me montrer un outil absolument génial qui permet de vérifier vos scripts shell (Variable non initialisée, erreur de synthaxe etc…) et je dois dire que cet outil s’est montré très performant voir bleuffant!

Cette outil s’appelle ShellCheck.

Vous avez la version online ici disponible sur ce site: http://www.shellcheck.net/

De plus il est également possible de télécharger une version local installé sur un de vos serveurs. Vous pourrez donc en une commande checker vos scripts!

Pour cela allez sur le site pour récupérer les sources: https://github.com/koalaman/shellcheck

 

– Dézipper l’archive zip

unzip -e <nom de l’archive>

– Aller dans le répertoire contenant les sources

– Installez ensuite les dépendances nécessaires:

 

Sous Debian:

– apt-get install ghc libghc-parsec3-dev lightghc-json-dev lightghc-regex-compat-dev libghc-quickcheck2-dev pandoc

 

Sous Centos/RedHat

– Installez les dépots EPEL. (tutoriel disponible ici)

– yum install ghc ghc-parsec-devel ghc-QuickCheck-devel ghc-json-devel ghc-regex-compat-devel pandoc

Le package pandoc n’est pas indiqué dans la documentation officielle, il est cependant nécessaire de l’installer!

 

– Il ne reste plus qu’à compiler:

make

– Copier le binaire dans /usr/bin

La commande shellcheck est maintenant disponible.

 

Faisons un petit test  avec un script contenant une erreur (par de fermeture de la condition if avec fi).

Contenu du script

– Vérifions avec shellcheck le script:

– Nous allons maintenant tester shellcheck avec une erreur un peu plus subtile (variable initialisé mais non utilisée):

Contenu du script

Résultat avec shellcheck:

Shellcheck  relève l’erreur!(en rouge les erreurs critiques, en vert les erreurs non critiques)

Enjoy! 🙂

 

 

 

 

 

 

 

 

 

 

 




KornShell | Rappel de commande avec les flèches sous Ksh

Article publiée le 19 Février 2014

 

Une petite astuce que l’on vient de me faire découvrir.

Qui n’a jamais galéré avec KornShell qui n’accepte pas les rappels de commandes avec les flèches directionnelles mais uniquement avec des raccourcis obscures??? (utilisateurs de HPUX notamment ;-))

Aujourd’hui on vient de me filer LA solution.

– Editez le .profile du user concerné

– Rajoutez les lignes suivantes:

set -o emacs

alias __A=`echo « \020″`     # up arrow = ^p = back a command
alias __B=`echo « \016″`     # down arrow = ^n = down a command
alias __C=`echo « \006″`     # right arrow = ^f = forward a character
alias __D=`echo « \002″`     # left arrow = ^b = back a character
alias __H=`echo « \001″`     # home = ^a = start of line
alias __F=`echo « \005″`     # end = ^e = end of line

Reconnectez vous et testez…

Vous ne vous énerverez plus jamais sur du kornshell !

 

 




Désactiver « BAD Password: it is Based on Dictionary Word »

Article publiée le 29 Janvier 2014

Une petite astuce qui pourrait s’avérer utile. La politique de mot de passe par défaut des distributions RedHat/ CentOS/ Fedora empêche tout les users non root de s’attribuer un mot de passe basé sur le dictionnaire.

Bien que je vous déconseille fortement de changer cette politique je vous donne malgré tout la marche à suivre afin de désactiver cette sécurité si besoin:

– Editez le fichier /etc/pam.d/system-auth

– Commentez la ligne password    requisite     pam_cracklib.so try_first_pass retry=3

– Repérer la ligne password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok

– Enlever « use_authtok »

– Votre ligne devrez ressembler à ça :

password    sufficient    pam_unix.so md5 shadow nullok try_first_pass

– Retenter de modifier un mot de passe via la commande passwd.

Enjoy 🙂




Comparateur distribution Linux/UNIX

Article publiée le 23 Janvier 2014

 

Je viens de découvrir un petit site extrêmement génial:

http://bhami.com/rosetta.html#security

Ce site offre un comparateur des commandes Shell ainsi que des architectures systèmes de toutes les distributions Linux/Unix existantes.

Pour ma part je pense que je vais l’imprimer et l’accrocher 😉

 

 

 




MOTDStat (Message Of The Day – System Status)

Article publiée le 09 Janvier 2014

Article mis à jour le 10 Février 2016

 

MOTDstat est un petit outil qui pourra vous être bien utile!

Il génère dynamique le motd avec les informations systèmes de votre machine (Message qui s’affiche lorsque vous ouvrez un terminal).

Un petit exemple:

 Installation:

– Téléchargez le tar.gz d’installation sur le site officiel (http://www.gelogic.net/download/)

– Téléchargez la dernière version et décompresser la via la commande:

tar -xvf <votre archive>

– Placez vous dans le répertoire qui où vous avez décompresser motdstat puis procédez à l’installation:

cd <repertoire des sources> && make install

– Pour procéder à la génération du motd utilisez la commande suivante:

motdstat –generate

– Afin que les informations soient mises à jour régulièrement pensez à la cronner

crontab -e  puis rajouter la ligne suivante:

*/5 * * * *   /usr/bin/motdstat –generate
Configuration:
Les fichiers de configuration de motdstat se situe dans le répertoire /etc/motdstat.
Ils sont extrêmement simples:
motdstat.conf: Fichier de configuration principal
fstab_limits: Contient la liste des file system à surveiller avec les seuils d’alertes Warning et Critical
process:  Contient la liste des ports d’écoute à surveiller
netservice: Contient la liste des processus à surveiller
Enjoy 🙂