ClamAV (« Clam AntiVirus »), est un logiciel antivirus pour systèmes UNIX et Linux. Il est souvent utilisé avec les serveurs de courriels pour filtrer les virus transportés par ce vecteur. Les virus ciblés sont majoritairement des virus s’attaquant au système d’exploitation Microsoft Windows, et non pas aux systèmes sur lesquels ClamAV s’installe. Toutefois, UNIX et Linux (Tout comme MacOS…) sont vulnérables à quelques dizaines de souches de virus, et il est important de protéger également les machines fonctionnant dans ces environnements, sans compter sur le fait que si ces serveurs abritent des dossiers utilisateurs, on va y trouver tout et n’importe quoi…Le 1 mars 2017, ClamAV affichait 5 902 241 signatures
Installer ClamAV
Pour installer ClamAV sur CENTOS, nous utilisons le repostory EPEL (Extra Packages for Enterprise Linux).
Si l’on souhaiter utiliser ClamAV avec CentOS et SELinux activé, il faut rajouter une configuration particulière afin que ClamAV puisse accéder à tous les fichiers du disque, et mettre à jour ses fichiers de définition. Permettre « antivirus_can_scan_system »:
setsebool -P antivirus_can_scan_system 1
Configuration du daemon Clam
Créer un lien symbolique sur le chemin de fichier par défaut
ln -s /etc/clamd.d/scan.conf /etc/clamd.conf
Editer le fichier de configuration installé par le package clamd-scanner:
nano /etc/clamd.d/scan.conf
Commenter la ligne
#Example
Dé-commenter la ligne LocalSocket pour l’activer
LocalSocket /var/run/clamd.scan/clamd.sock
Sauver et quitter l’éditeur de texte
Démarrer le service et l’activer au démarrage
Démarrer le service
systemctl start clamd@scan
Et l’activer au démarrage…
systemctl enable clamd@scan
Redémarrer la machine. Pour vérifier le statut du daemon, taper
systemctl status clamd@scan
Au besoin, pour désactiver l’agent, tout de même gourmand en ressources…(Souvent ClamAV n’est utilisé que pour des analyses occasionnelles…
systemctl disable clamd@scan
Installer et configure l’updater ClamAV
Pour bénéficier des mises à jour automatique (Le package doit déjà être installé…)
yum install clamav-update
Editer le fichier de configuration:
nano /etc/freshclam.conf
Commenter la ligne d’exemple:
#Example
Editer le second fichier de configuration (dans sysconfig…):
nano /etc/sysconfig/freshclam
Comment cette ligne pour pouvoir utiliser crontab (Les mises à jour sont désactivées par défaut):
#FRESHCLAM_DELAY=disabled-warn
Sauver et quitter l’éditeur de texte. Lancer la commande freshclam pour mettre à jour la base d’antivirus. Au besoin vous pouvez créer une tâche crontab pour l’exécuter régulièrement.
freshclam
Tester votre scanner ClamAV
Il est possible de scanner en utilisant le daemon, avec clamdscan, ou en utilisant le client interactif clamscan. Les deux exemples sont fournis ici. On considère que clamdscan est plus économe en ressource, mais il faut qu’il soit chargé en mémoire, et si ce n’est pas le cas, utilisez donc clamscan.
Toujours utiliser l’option –fdpass pour donner les permissions correctes si vous utilisez le daemon clamdscan.
clamdscan --fdpass /var/log/*
Pour scanner tout votre système avec lamscan
clamscan -r /
Pour scanner tout votre système en t’ache de fond, mais seulement afficher les fichiers infectés:
clamscan -r -i / &
Pour scanner les fichiers dans tous les dossiers utilisateurs “home”
clamscan -r /home
Pour scanner les fichiers dans le dossier “home” d’un utilisateur et déplacer le fichier infecté dans le dossier =/home/USER/VIRUS
clamscan -r --move=/home/USER/VIRUS /home/USER
Pour scanner les fichiers dans le dossier “home” d’un utilisateur et supprimer le /les fichier (s) infecté (s). Attention, les fichiers seront vraiment supprimés…
La procédure est donnée comme cas d’école, et il se peut qu’elle ne convienne pas à vos environnements. Elle est réservée à des personnes expérimentées à même d’en comprendre les tenants et les aboutissants, et d’effectuer les adaptations nécessaires.
Vous devez avoir installé préalablement le repository epel.
Installer MONIT
sudo yum install monit
Démarrer le service Monit
sudo systemctl restart monit.service
Mettez le service Monit en lancement automatique au démarrage du serveur
sudo systemctl enable monit.service
Créer des fichiers de configurations pour surveiller les services
La seconde chose à faire est de créer des fichiers de configurations qui indiqueront à Monit quels sont les services à surveiller, et les actions à entreprendre en cas de dysfonctionnement. Pour commencer, nous allons mettre en œuvre une surveillance du service Apache.
Apache
Créer un fichier apache.conf dans le dossier /etc/monit.d/
nano /etc/monit.d/apache.conf
Le fichier doit contenir les lignes suivantes:
check process httpd with pidfile /var/run/httpd/httpd.pid
start program = "/usr/bin/systemctl start httpd.service" with timeout 60 seconds
stop program = "/usr/bin/systemctl stop httpd.service" if children > 250 then restart if loadavg(5min) greater than 10 for 8 cycles
then exec "/root/pushover.sh/pushover.sh" if failed port 80 for 2 cycles then restart if 3 restarts within 5 cycles then exec "/root/pushover.sh/pushover.sh"
La première ligne indique le service à monitorer
La seconde est la commande de démarrage, en laissant 60 secondes de marge pour indiquer qu’il fonctionne directement (Sur un système lent, cela peut prendre du temps ;>)
La troisième comment le service doit redémarrer en fonction de diverses contraintes.
La quatrième ligne est liée à l’expédition d’une alerte via un système de push dont le tutoriel sera créé ultérieurement par une collègue.
Tester le status de Monit
Afin de voir si Monit démarre correctement avec ce fichier de configuration, il faut le relancer avec
sudo monit reload
Ou
sudo systemctl restart monit
Contrôler que la syntaxe des fichiers est correcte avec
monit -t
Qui devra renvoyer
Control file syntax OK
Et voir le statut de Monit
sudo monit status
Pour avoir une vue simplifiée, il est aussi possible d’utiliser
sudo monit summary
MariaDb
Nous devons créer un fichier de configuration pour surveiller MariaDB
nano /etc/monit.d/mariadb.conf
Le fichier doit contenir les lignes suivantes:
check process mariadb with pidfile /var/run/mariadb/mariadb.pid
start program "/usr/bin/systemctl start mariadb.service" with timeout 60 seconds
stop program "/usr/bin/systemctl stop mariadb.service" if children > 250 then restart if loadavg(5min) greater than 10 for 8 cycles
then exec "/root/pushover.sh/pushover.sh" if failed host 127.0.0.1 port 3306 for 2 cycles then restart if 3 restarts within 5 cycles then exec "/root/pushover.sh/pushover.sh"
ProFTPD
Nous devons créer un fichier de configuration pour surveiller notre serveur ProFTPD
nano /etc/monit.d/proftpd.conf
Le fichier doit contenir les lignes suivantes:
check process proftpd with pidfile /var/run/proftpd.pid
start program "/usr/bin/systemctl start proftpd.services" with timeout 60 seconds
stop program "/usr/bin/systemctl stop proftpd.services" if children > 250 then restart if loadavg(5min) greater than 10 for 8 cycles
then exec "/root/pushover.sh/pushover.sh" if failed port 21 for 2 cycles then restart if 3 restarts within 5 cycles then exec "/root/pushover.sh/pushover.sh"
SSHD
Nous devons créer un fichier de configuration pour surveiller notre serveur SSHD
nano /etc/monit.d/sshd.conf
Le fichier doit contenir les lignes suivantes:
check process httpd with pidfile /var/run/sshd.pid
start program = "/usr/bin/systemctl start sshd.service" with timeout 60 seconds
stop program = "/usr/bin/systemctl stop sshd.service" if children > 250 then restart if loadavg(5min) greater than 10 for 8 cycles
then exec "/root/pushover.sh/pushover.sh" if failed port 22 protocol ssh for 2 cycles then restart if 3 restarts within 5 cycles then exec "/root/pushover.sh/pushover.sh"
Les options de Monit
Nous n’allons pas rentrer dans les détails ici, mais il faut savoir que Monit possède un fichier de configuration dans
/etc/monit.rc
Le « Polling Frequency » est le paramètre qui indique l’intervalle en seconde du contrôle des services. Le défaut est 30 secondes, ce qui peut sembler être une cadence trop rapide, et cette valeur dépendra surtout du nombre de tests que vous souhaiterez effectuer sur un nombre donné de services et les actions entreprises dans les différents fichiers de configuration. Plus vous surveillerez de service, plus cette valeur devra être importante afin de ne pas surcharger inutilement votre système.
Le fichier comprend également des entrées relatives à son propre serveur WEB affichant des informations sur le port 2812. Par défaut il n’est accessible que depuis la machine hôte avec l’utilisateur admin et le mot de passe monit, et il est évidemment conseillé de laisser ce paramètre ainsi. Voici les paramètres par défaut :
set httpd port 2812 and
use address localhost # only accept connection from localhost
allow localhost # allow localhost to connect to the server and
allow admin:monit # require user 'admin' with password 'monit'
A supposer que l’on désire afficher la page WEB de Monit depuis n’importe quel endroit, ce qui est évidemment déconseillé car extrêmement risqué si ce port est ouvert sur Internet, il suffit de changer les sections suivantes (Ici on n’autorise que depuis adresse IP publique…)
set httpd port 2812 and
# use address localhost # only accept connection from localhost
allow localhost # allow localhost to connect to the server and
allow 94.67.23.22 # Votre adresse IP publique
allow admin:monit # require user 'admin' with password 'monit'
Puis redémarrer le service avec
sudo systemctl restart monit
Contrôler le statut avec
sudo monit status
Et vous devriez pouvoir afficher la page WEB ainsi, indiquant les services surveillées. En cliquant sur un des services, vous accédez à des informations complémentaires, comme par exemple son uptime ou sa consommation mémoire.
Comment tester ?
Il y’a plusieurs manières de faire le test. Trouver par exemple le processus lié à MariaDB en tapant
ps -ef|grep mysqld
Donc mon cas, il s’agit du processus ayant le PID 6926. Je vais donc lui envoyer une commande kill, en tapant
kill 6926
Le /var/log/messages m’indique
mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
Dans la plupart des cas, il est préférable d’avoir un serveur à jour, plutôt qu’utiliser des logiciels obsolètes dans lesquels une faille de sécurité ou un problème de fonctionnement a été décelé. De nombreux serveurs WEB sont affectés par un certain délaissement, car installés une fois et peu suivis; différents prétextes sont invoqués, comme ne pas toucher quelque chose qui fonctionne, ou par excès de foi dans la sécurité de Linux, ou simplement par manque de temps.
Toutefois, mettre à jour automatiquement un serveur peut avoir un impact considérable sur son fonctionnement ; Imaginez que vous avez installé un kernel non fournit dans la distribution de base (une version 4 sous CentOS…), et que celui-ci est remplacé lors d’une mise à jour par une version antérieur. Que se passerait-il ? Et bien cela dépend des cas. Des fois rien du tout, ou alors un dysfonctionnement majeurs.
Installer yum-cron
sudo yum install yum-cron
Configurer yum-cron
La configuration de yum-cron se trouve dans 2 fichiers. Le premier fait un contrôle journalier et le second horaire. Généralement, nous ne configurons que le premier.
/etc/yum/yum-cron.conf
/etc/yum/yum-cron-hourly.conf
Dans yum-cron.conf il faut changer mettre à jour ces trois lignes afin que les mises à jour puissent s’effectuer
update_message = yes
download_update = yes
apply_update = yes
Il est également possible de modifier le paramètre d’envoi des messages afin de choisir un destinataire externe, en choisissant la méthode appropriée. Pour cela il faut changer la ligne concernant la manière d’envoyer les informations en changeant à « email » et indiquer un destinataire.
# List of addresses to send messages to.
# email_to = root
email_to = votreemail@domaine.com
emit_via = email
Démarrer le deamon au démarrage
sudo systemctl enable yum-cron
Démarrer le deamon
sudo systemctl start yum-cron
Contrôler que le deamon est actif
sudo systemctl status yum-cron
Redémarrer yum-cron
sudo systemctl restart yum-cron
Pour s’assurer que yum-cron fonctionne, il faut contrôler le fichier log
tail -50 /var/log/yum.log
On doit voir une section « updated » avec des dernières mises à jour
Il n’est pas toujours simple d’identifier les problèmes de performances sous Linux, mais on sera plus efficace avec ces quelques outils, qui constituent la trousse de secours de tout administrateur système.
Note
L’auteur fournit tel quel cette liste d’outils, et ne prend aucune responsabilité sur leur utilisation qui doivent être effectuée par des personnes confirmées sur un système de production.
1. htop
htop est une évolution de top, permettant une excellente vision des processus ou des threads s’exécutant sur le système en mode utilisateur ou en mode kernel, htop permet de trier ou stopper les processus d’une manière entièrement interactive. Pour l’installer
sudo yum install htop
2. glances
Outil de monitoring général similaire à htop permettant d’afficher un maximum d’information sur le moins d’espace possible. Pour l’installer
sudo yum install glances
3. iotop
iotop indique des informations sur les I/O des différents processus sur le disque dur, permettant de détecter d’éventuels latences ou autres goulets d’étranglements par rapport à la performance du sous-système disque. Pour l’installer
sudo yum install iotop
4. df
df signifie Disk Free et permet de voir l’occupation des volumes sur n’importe quel système UNIX ou Linux, il est préinstallé par défaut. Pour visualiser les informations de manière confortable, utiliser l’option –h (Pour Human…)
df -h
5. lshw
Un outil qui extrait les informations du matériel, que ce soit du processeur à la carte mère. Pour l’installer
sudo yum install lshw
Et pour le lancer, simplement
lshw
6. apachetop
apachetop monitor les performances globales de votre serveur apache en affichant le nombre d’accès en lecture et en écriture, comme le nombre global de requêtes effectuées. Pour l’installer
sudo yum install apachetop
7. ftptop
ftptop indique des informations de base sur les connections ftp courantes, comme le nombre d’utilisateurs connectés et les chargements et téléchargements en cours. Pour l’installer
sudo yum install ftptop
8. mytop
mytop indique des informations concernant les threads en cours et la performance d’une base mysql ou mariadb. Pour l’installer
powertop vous donne une vision de la consommation électrique des processus et du matériel, et peut vous aider à effectuer les réglages adéquats pour limiter la consommation du système.
sudo yum install powertop
Il faut ensuite utiliser la touche <TAB> pour passer d’une vue à l’autre.
10. Netstat
Netstat affiche des statistiques sur les paquets entrants et sortants, ainsi que sur les interfaces réseaux. Il est installé par défaut dans le système, et l’exemple d’utilisation est le suivant :
netstat -pan | less
11. Nmap
Nmap est un scanner permettant de connaitre les ports ouverts, sur sa machine ou un host distant. Pour l’installer
sudo yum install –y nmap
L’exemple d’utilisation est le suivant :
nmap 127.0.0.1
12. iftop
Outil de visualisation du réseau indiquant le connexions entrantes et sortantes avec le serveur ainsi que la consommation de la bande passante pour chaque connexion, la résolution des hosts ainsi que les ports utilisés. Un must to have ;>)
sudo yum install iftop
13. jnettop
jnettop est un autre outils de visualisation des arcanes du réseau. Pour l’installer, télécharger la dernière version depuis
Et choisissez ensuite votre carte réseau en pressant les touches de 0 à 9 jusqu’à ce que vous ayez trouvé votre carte.
14. Iptraf-ng
Encore un autre outil d’analyse des métriques réseaux.
sudo yum install Iptraf-ng
15. bmon
Un outil qui mesure la bande passante de votre carte et les affiche sous la forme d’un graphique
sudo yum install bmon
16. tcpdump
tcpdump est un outil de capture du trafique réseau aux possibilités quasi infinies, demandant toutefois une certaine expertise largement documentée sur Internet. Pour installer tcpdump
sudo yum install tcpdump
Exemple d’utilisation : Capturer tout le trafic mais exclure son adresse IP et son protocol ssh en combinant ces 2 exclusions afin de ne pas visualiser votre trafique parasite :
tcpdump -i eth0 port not 22 and host 85.218.71.41
Capturer tout le trafic depuis une adresse de destination
tcpdump -i eth0 dst 50.116.66.139
Capturer tout le trafic depuis une adresse source
tcpdump -i eth0 src 192.168
16. lsof
Un outil préinstallé lisant tous les fichiers ouverts et les connections réseaux. Outil puissant, il permet de trouver quel fichier est ouvert par quel processus, basé sur son nom, ou sur un utilisateur. Et pour le lancer, simplement
Passer CentOS 7.3 à une version de kernel de génération 4.
Note
L’auteur fournit tel quel cette procédure et ne prend aucune responsabilité sur son bon fonctionnement. Changer le kernel sur une distribution peut amener des dysfonctionnements majeurs sur un système de production. Le repository communautaire proposant le nouveau kernel est ELRepo, qui n’est pas officiel, et dont les sources doivent être ajoutées manuellement.
Mise à jour du kernel
Contrôler la version actuelle du kernel
uname –a
La version retournée sera 3.X. Il faut pour poursuivre ajouter la clé GPG du repository ELRepo. (Note : cette commande peut avoir été changée ; elle est visible sur le site de ELRepo http://elrepo.org/)
Ensuite, le repository ELRepo dans CentOS 7 / RHEL 7 ou Scientific Linux 7. (Note : cette commande peut avoir été changée ; elle est visible sur le site de ELRepo http://elrepo.org/)
Activer les miroirs rapides de ELRepo afin de télécharger les sources depuis une position géographique plus proche de vous :
yum install yum-plugin-fastestmirror
Maintenant, installer le kernel Linux 4.10 (ou supérieur…) avec la commande
yum --enablerepo=elrepo-kernel install kernel-ml
Redémarrer et choisir le nouveau kernel dans le menu de démarrage, car les anciennes versions seront toujours présentes. Contrôler avec uname –a qu’il s’agit du bon kernel…
Après s’être assuré que le matériel et les logiciels fonctionnent correctement, il faut modifie le loader grub pour le charger par défaut. Pour lister les entrées de Grub, tapez
Dans les 2 cas on voit que l‘entrée comportant le kernel le plus récent est la première…qui porte donc le numéro d’entrée 0. Demander à grub de charger par défaut la valeur 0
grub2-set-default 0
Et sauvegarder la configuration…
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Rebooter et contrôler avec uname –a que nous avons bien la version attendue du kernel.
Mettre en quarantaine les tentatives d’accès et les signaler par courriel en utilisant une passerelle GMAIL. Fail2ban est un script qui lit le journal /var/log/secure et bannit les adresses IP dans le firewall en suivant certains critères.
Note
L’auteur fournit la procédure de l’installation de fail2ban tel quel et ne prend aucune responsabilité sur son bon fonctionnement. fail2ban est une contre-mesure aux attaques courantes, mais n’est qu’un élément sécuritaire parmi d’autres.
Installer fail2ban
Fail2ban n’est pas disponible dans le repository officiel de CentOS, il faut ajouter celui du projet EPEL.
sudo yum install -y epel-release
Installer maintenant le package fail2ban
sudo yum install -y fail2ban
Activer le service
sudo systemctl enable fail2ban
Configure Local Settings
Les fichiers de configuration se trouvent dans /etc/fail2ban. Le fichier de configuration par défaut est jail.conf, qui peut être modifié en tout temps par des nouvelles versions de package. Il ne faut en aucun cas l’éditer, mais en faire une copie jail.local qui contiendra les paramètres que nous souhaitons écraser.
Ce fichier contient une section [DEFAULT], suivies par des sections individuelles. Ce fichier peut être à la limite vide si l’on se contente des paramètres par défaut, mais sera populé au besoin des modifications souhaitées.
Les paramètres sont appliqués dans l’ordre des fichiers suivants :
/etc/fail2ban/jail.conf
/etc/fail2ban/jail.d/*.conf, alphabetically
/etc/fail2ban/jail.local
/etc/fail2ban/jail.d/*.local, alphabetically
Chaque fichier peut contenir une section [DEFAULT] exécutée en premier, ainsi que d’autres sections pour les prisons individuelles.
Par défaut tous les jails sont désactivés dans le jail.conf et il faut les créer dans le fichier jail.local.
La commande doit se terminer sans erreurs. Nous pouvons le statut de fail2ban en invoquant son statut :
systemctl status fail2ban
Nous pouvons le statut de fail2ban en invoquant son client :
sudo fail2ban-client status
Nous pouvons avoir des informations concernant une prison particulière :
sudo fail2ban-client status sshd
Il est possible de checker le journal de fail2ban depuis son dernier démarrage
sudo journalctl -b -u fail2ban
Il est aussi possible de checker directement le journal de fail2ban
sudo tail –f –n 2000 /var/log/fail2ban.log
Ou de contrôler les rôles courants définis par fail2ban dans iptables:
sudo iptables -L
Ou de lister les entrées sous la forme des commandes employées dans iptables.
sudo iptables -S
Ou encore de voire toutes les adresses IP bannies par fail2ban
sudo iptables -L -n
Lorsqu’on est certain que fail2ban fonctionne correctement, on peut l’ajouter en démarrage automatique et redémarrer le serveur pour tester.
systemctl enable fail2ban
Envoyer des emails d’alertes
Attention: Il faut compter environ une dizaine de tentative par heure sur le port SSH pour un serveur qui vient d’être activé sur Internet.
Toutefois il y’a un prérequis pour envoyer des courriels, c’est d’installer un MTA. Inutile d’installer Postfix ou Sendmail, des produits qui risquent de vous ouvrir à de nouvelles vulnérabilités, il faut juste pouvoir envoyer des messages en ligne de commande, et surtout passer par un gateway authentifié sur GMAIL pour que vos messages ne soient pas rejetés par le système de messagerie du destinataire.
Installer Heirloom mailx
yum install -y mailx
Créer un lien symbolique sur email
ln -s /bin/mailx /bin/email
Configurer mail.rc
nano /etc/mail.rc
#Use TLS set smtp-use-starttls # Ignore SSL set ssl-verify=ignore set nss-config-dir=set nss-config-dir=/root/.certs # set smtp=smtp://smtp.server.tld:port_number set smtp=smtp://smtp.gmail.com:587 # tell mailx that it needs to authorise set smtp-auth=login # set the user for SMTP # set smtp-auth-user=user@domain.tld set smtp-auth-user=votreuser@gmail.com # set the password for authorisation set smtp-auth-password=votremotdepasseducomptegmail
Importer les certificats nécessaires à l’implémentation TLS avec GMAIL
Créer un dossier pour les certificats
mkdir ~/.certs
Créer une nouvelle base de données (Ne pas oubleir d’y rentrer et noter votre mot de passe)
certutil -N -d ~/.certs
Créer 3 fichiers pour stocker les chaines de certificats
Contrôler que l’opération été effectuée correctement :
certutil -L -d ~/.certs
Sortie d’exemple :
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Google Internet Authority CT,, GeoTrust Global CA CT,, Equifax Secure Certificate Authority CT,,
Tester l’envoi de message
Tapez la ligne pour envoyer un message
echo "Votre message" | mail -s "Sujet" email@votrechoix
Configurer fail2ban pour envoyer des alertes par email
Pour utiliser mailx, la première chose à faire est de dupliquer le fichier mail.conf en mail-whois.conf
Si l’on souhaite automatiser des tâches administratives, comme lancer des sauvegardes sans mettre chaque fois le mot de passe, il est nécessaire d’implémenter des clés ssh pour approuver la sécurité des hosts entre eux.
L’exemple utilise ici toujours l’utilisateur root. Ce n’est pas forcément une bonne idée…
Avertissement
Ce tutoriel est livré sans garanties aucune, et vous seuls êtes responsables de son éventuelle implémentation.
La plupart des tutoriaux proposent de créer une clé avec la commande
ssh-keygen -t rsa
Toutefois, il s’agit d’un ancien algorithme basé sur la difficulté de factoriser des grands nombre. Aujourd’hui ce niveau de sécurité est caduc, quand bien même il faudrait au moins utiliser une clé de 4096 bits avec l’option ssh-keygen -t rsa -b 4096
ssh-keygen -t dsa
Un autre algorithme ancien qui n’est plus du tout recommandé…
ssh-keygen -t ecdsa -b 521
Un nouvel algorithme utilisé par le gouvernement américain, dont la taille des clés peut être 256, 84, and 521 bits. Toujours utiliser la version looongue
Et le bon est…
ssh-keygen -t ed25519
Un nouvel algorithme implémenté maintenant dans OpenSSH. Pas forcément implémenté dans tous les systèmes, c’est pourtant le choix à retenir par défaut.
Etape 1 : Créer votre pair de clés
Ouvrir un terminal shell et taper
ssh-keygen -t ed25519
Il vous sera demandé dans quel fichier enregistrer la clé. Laisser les propositions par défaut.
[root@localhost ~]# ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_ed25519.
Your public key has been saved in /root/.ssh/id_ed25519.pub.
/root/.ssh/ id_ed25519 La clé privée, qu’il ne faudra jamais partager…
/root/.ssh/ id_ed25519.pub La clé publique, qui sera copiée sur le host que l’on souhaitera atteindre sans le mot de passe.
Il est possible de changer ou d’ajouter le mot de passe aux fichiers par la suite en tapant
Ssh-keygen -p
Etape 2 : Copier la clé publique sur la machine distante
Lancer l’utilitaire suivant suivis du nom du host
ssh-copy-id root@192.168.50.133
Ceci ajoutera automatiquement la clé publique la plus récemment modifiée sur la machine locale en mettant à jour le fichier ~/.ssh/authorized_keys sur la machine distante. (Si le fichier existe déjà, l’information sera simplement ajoutée).
Le résultat sera le suivant dans le shell
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@192.168.50.133's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'root@192.168.50.133'"
and check to make sure that only the key(s) you wanted were added.
Note : Si l’on ne souhaite pas copier des clés se trouvant dans plusieurs fichiers, on peut aussi spécifier le fichier à copier
L’informatique, cela ne fonctionne jamais su premier coup, alors backuper préalablement votre site WEB et la base de données associée…
Livré sans résultats garantis…
Prérequis
La première chose est d’autoriser le firewall à accepter les connexions HTTPS, pour la simple et bonne raison que sans cela, une étape de vérification aura lieu plus en aval, et se terminera par un message d’erreur de type suivant :
Failed to connect to x.x.x.x:443 for TLS-SNI-01 challenge
Donc
sudo ufw allow https
Installer le mode SSL pour Apache
yum -y install mod_ssl
Redémarrer le servcice Apache
systemctl restart httpd.service
Installer le repository EPEL, qui nous servira à installer des packages en dépendances
yum install epel-release
Installer GIT
yum install git
Aller dans le répertoire approprié pour rafraichir GIT
Aller dans le répertoire approprié pour invoquer la commande de demande de certificat
cd /usr/local/letsencrypt
Lancer la commande appropriée. Très important : Générer tant pour le nom de domaine que pour le site web, sinon les navigateurs vous sonneront une erreur plutôt moche…
Un certain nombre de dépendances supplémentaires seront certainement téléchargées…
Tester le site
Aller sur
Entrer votre nom de domaine (sans www…)
Un rapport est issu, avec nombre d’informations…
Si vous recevez une note de C, c’est que votre domaine est vraiment mal sécurisé, et des ajustements sont nécessaires. Éditez le fichier concernant la configuration SSL avec
nano /etc/httpd/conf.d/ssl.conf
Chercher pour la ligne commençant par
SSLProtocol
Et ajouter
-SSLv3
A la fin de la ligne.
Continuer votre recherche, et commenter avec un dièse la ligne commençant par
SSLCipherSuite
Créer une nouvelle ligne en copiant la (longue…) ligne suivante :
Et rajouter encore 2 lignes supplémentaires en-desous…
SSLHonorCipherOrder on
et
SSLOptions +StrictRequire
Re-Tester le site
Aller sur
Refaire le test mais cliquer sur « Clear cache »
Un rapport est issu, avec nombre d’informations… Et on devrait avoir quelque chose de mieux maintenant ;>)
Renouveler automatiquement le certificat Let’s Encrypt sur Apache
Et oui, cette béat crée un certificat qui expire après …. 90 jours. C’est court, et très moche, mais un script a été créé afin de renouveler automatiquement le certificat.
Ce script sera schedulé par la commande « cron » afin d’être lancée au moment approprié.
Pour renouveler manuellement le certificat, vous devez taper la ligne suivante :
Parmi les logiciels de développement, on trouve couramment une vieille casserole connue ayant eu autrefois son heure de gloire, appelée Visual FoxPro.
Ce RAD inclut aussi un gestionnaire de base de données utilisant la technologie ISAM.
Dans un système de base de données ISAM, c’est le client qui gère ses propres accès aux tables de la base données en accédant directement aux tables ainsi qu’aux index.
Le client se repose donc sur un mécanisme de verrouillage des fichiers pour maintenir l’intégrité et la consistance du jeu de données global.
Cette méthode est simple et efficace en termes de vitesse, et permet de se passer d’un gestionnaire de base de données centralisé comme SQL Server ou Oracle.
Toutefois, par la nature même de cette technologie, la protection des données est très inférieure à un système SGBD centralisé, qui deviennent ainsi extrêmement sensibles aux différentes erreurs d’écritures, pouvant facilement corrompre l’entier des données.
Au début, Windows NT, à travers son protocole réseau SMB 1, mettait en jeu un certains nombres de mécanisme permettant d’accélérer les écritures en réseau au travers de différentes techniques de cache, dont la plus connue appelée Opportunistic locking or oplocks.
Le problème de oplocks est que si plusieurs demande d’accès avaient lieu sur un même fichier, le cache était relâché et les données écrites sur le disque, et potentiellement des corruptions pouvaient se produire dans le dit fichier.
Cette optimisation étant quelquefois non souhaitée, il était possible de la désactiver dans SMB1 (Q219022).
Par la suite, la couche réseau de Windows a passablement évolué. Depuis Windows Vista, le protocole est passé à la version SMB2, et avec Windows 8, SMB3.
L’inconvénient est que dans ses dernières versions SMB2 et SMB3, oplocks ne peut plus être désactivé, et les bases de données reposant sur la technologie ISAM ne fonctionnent plus correctement sans avoir continuellement des problèmes de corruption.
Selon Microsoft (Voir plus bas l’article original en anglais) oplocks ne permet plus de faire fonctionner en toute sécurité des bases de données utilisant la technologie ISAM, et une solution est de désactiver les protocoles récents SMB2 et SMB3 dans Windows 8 ou Windows 10, ainsi que sur le serveur Windows 2016, solution préconisée d’ailleurs par certains éditeurs sur leur site Internet, et de n’utiliser que SMB1.
Cette solution est extrêmement dangereuse, car le protocole SMB1 contient un grand nombre de problèmes de sécurité qui ne sera plus corrigé par Microsoft, au point même que l’éditeur désactive SMB1 dans ses dernières versions de Windows. De plus, cela rend plus lent le fonctionnement du réseau entre les postes clients et le serveur.
La seule solution que nous recommandons est dès lors de ne plus accéder directement aux données d’une base ISAM en passant par le réseau, mais de confiner le programme et ses données dans une session de type Services Bureaux à Distances sur un serveur.
Ainsi, en ne déportant que l’affichage sur les postes clients du logiciel, les informations de la base de données ne transitent plus par le réseau entre le programme et ses fichiers, ce qui élimine les risques de corruption.
La seconde recommandation que nous faisons est claire: Ne plus acquérir de logiciels utilisant la technologie de base de données de type ISAM. Les outils permettant de développer des programmes sur ce modèle, comme Visual Foxpro, sont maintenant totalement dépassés (Visual Foxpro n’est même plus supportés par Microsoft…), car ils n’ont plus la possibilité de suivre les évolutions de Windows.
Avant d’acquérir une solution informatique, il est de votre devoir de connaitre avec quel outil elle a été conçue, ce qui vous donnera une idée sur sa pérennité et son évolutivité,
Des éditeurs créant encore des logiciels avec des RAD utilisant la technologie ISAM prétendent faussement que si leurs solutions connaissent des problèmes de fonctionnement, il s’agit de « problèmes réseaux », mettant ainsi la faute sur les infrastructures des clients, ce qui est évidemment malhonnête, ou pour le moins démontre une méconnaissance totale de l’architecture des systèmes modernes.
“If a multiuser or single user database application accesses a common data store on a Windows NT file server using opportunistic locks (or OPLOCKS), it is possible for a given user to cache partial transactions on the client systems hard drive. This is a performance enhancement to the Windows client redirector to reduce network file I/O between the client and server. The data being cached on the client redirector is later written back to the server. However, in some cases, a client system may stop responding (hang), do a hard reboot, lose its network connection to the server, or experience any number of other technical difficulties. In such cases, the content of the local cache that has not yet been written to the server can be lost. As a result, the transaction integrity of the database structures on the server is compromised and the data on the file server can become corrupted.” (see Q224992)
The only thing that developers utilizing ISAM database systems can do to help mitigate the problem posed by network communications issues and optimistic locking, is to perform more regular flushes (writes of buffered information) to disk. This process will both lessen performance, but may also still not resolve the issues that can arise from optimistic locking and network communications failures.
Our recommended solution is to place the data access inside a safe environment where file access and requests are not handled over the network at all. We recommend accessing our software via Remote Desktop Services and to have the data stored directly on the server managing the remote access. If file access is handled locally, and no network access is handled, the cache / locking / race conditions that can occur during read/write over the network are veritably eliminated.
If network file access is required, following Microsoft suggestion to downgrade to SMB 1.0 and disabling optimistic locking is the recommended solution. There are known side effects with performance and file access is going to generally be slower after doing this. This solution may still not eliminate all potential network file access issues, and has no effect on mitigating communications problems or failures leading to data corruption.
Nous utilisons les cookies afin de fournir les services et fonctionnalités proposés sur notre site et afin d’améliorer l’expérience de nos utilisateurs.
En cliquant sur ”J’accepte”, vous acceptez l’utilisation des cookies. Vous pourrez toujours les désactiver ultérieurement.
En poursuivant votre navigation, vous acceptez le dépôt de cookies tiers destinés à vous proposer des vidéos, des boutons de partage, des remontées de contenus de plateformes sociales.
Nous utilisons des cookies pour nous permettre de mieux comprendre comment le site est utilisé. En continuant à utiliser ce site, vous acceptez cette politique.
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are as essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.