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

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!

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 ;-))

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

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

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 🙂

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:

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)

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 🙂

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é! 🙂

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 🙂

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

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!

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! 🙂

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 !

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 🙂

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 😉

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:

Article publiée le 8 Janvier 2014

Après un long moment d’absence je me permet d’écrire ce mini article sur comment checker la consommation RAM d’une machine Linux.

J’ai pu m’apercevoir tout au long de ma carrière que les admin débutants  check la consommation mémoire de leur machine uniquement avec la commande top ou htop!

Et la je crie oh sacrilège!!!

Eh oui il arrive  que ce type de commandes puisse induire en erreur les jeunes admins car  celle ci indique très souvent  une consommation quasi à 100% de la mémoire alors qu’il n’en est rien!

Pour être sur de votre coup je vous invite à checker la mémoire de votre machine avec la commande free!

Ci dessous un exemple d’interprétation de cette commande:

La commande free -m retourne normalement ceci:

Dans un premier temps vous pouvez voir que votre machine ne SWAP pas ce qui est déjà bon signe!

Ensuite la colonne free indique 321 MO de mémoire libre et pourtant, en réalité, la mémoire disponible est  bien plus élevée!

La marche à suivre:

Ce qui nous fait 321+90+202 = 613 Mo de libre!

Pour info le Buffer/cache stock les information lu et écrites afin de réduire les accès disques et augmenter les performances! (directement géré par le kernel)

Article publiée le 16 Novembre 2013

Une petite astuces en passant:

Souvent lors de nos petites investigations Linuxienne il peut arriver que l’on est besoin de savoir qui s’est connecté quand est ou et sur quelle machine!

Une petite commande fort bien sympathique existe:  last

Disponible nativement sur la plupart des distribs connues last vous permet d’avoir la liste des dernière connexions effectuées sur un serveur.