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
https://www.ssllabs.com/ssltest/analyze.html
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
https://www.ssllabs.com/ssltest/analyze.html
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 :
Avertissements: A vos risques et périles Msieursd’ames ;>)
Les vidéophiles l’auront constaté…
Visionner Netflix sur Windows en 1080P est d’une simplicité déconcertante sous Windows: Il suffit d’utiliser Internet Explorer ou Edge. Sous OSX, Safari en fera de même, et si les drivers sont un minimum à jour dans ces environnements, la fluidité sera assurée.
Concernant Linux, c’est bien plus pénible: Firefox ou Chrome sont limités en 720P. De plus, de nombreux problèmes Vsync apparaissent, qui rendent l’image atroce, genre une zone qui apparaît au milieu des scènes rapides et traumatise l’expérience vidéo de la chaîne VDO au point que n’importe quel cinéphile jurera que l’on ne l’y reprendra plus…
Sans compter que voir une vidéo en 720P sur un écran 1080P natif de 24 pouces est affligeant par rapport à ce que l’œuvre pourrait délivrer dans son format natif.
Et pourtant, tous ceux qui regardent Netflix depuis l’application idoine sur leurs Smart TV utilisent généralement sans le savoir aussi Linux, et ci cela fonctionne dans ce cas, on imagine qu’il doit en être de même sur leurs ordinateurs.
Il est difficile de trouver des solutions à tous les problèmes sous Linux, tant les environnements sont différents et complexes.
D’un côté nous avons les paramètres afférents au noyau, ensuite le serveur graphique utilisé, puis l’environnement de présentation, et enfin des paramètres sur le compositeur vidéo.
Donc, je vais vous indiquer ce qui a fonctionné pour moi, et peut être cela sera t’il utilisable sur d’autres environnements. Sauvegardez votre système préalablement !
Configuration Linux
OS
Kubuntu 18.04 LTS
Kernel
4.17 RC5
Environnement graphique
KDE Plasma
Carte vidéo
GeForce GTX 1070
RAM
8192 MB
Ecran 1
DELL U2415 1920 X 1200
Ecran 2
Fujitsu P24W-5 ECO 1920 X 1200
Driver Nvidia
Propriétaire 396.24
Détecter son matériel
Détecter le modèle de sa carte ainsi que les drivers recommandés
Update du repository et installation des drivers Nvidia
sudo apt update
sudo apt install nvidia- et presser sur <TAB> pour afficher les différentes versions disponibles
Choisissez par exemple la version de driver nvidia-396, donc
sudo apt install nvidia-396
Au redémarrage, vous devrez trouver l’utilitaire Nvidia disponible sur votre système Linux.
Paramètres matériel / Affichage et écran
Paramètres standards
Paramètres matériel / Compositeur
Vitesse d’animation : Ultra-rapide
Méthode de mise à l’échelle : Précise
Moteur de rendu : OpenGl 3.1
Prévention de déchirement VSYNC : Rafraîchissement de tout l’écran
Conserver les vignettes des fenêtres : Toujours
Avec cela, on a déjà réglé une partie du problème, mais ce n’est pas terminé.
Passer en mode super-utilisateur
sudo -s
Créer le fichier suivant :
nano /etc/profile.d/Tearing.sh file
Le contenu doit être
export KWIN_TRIPLE_BUFFER=1
Rendre le fichier exécutable
chmod +x /etc/profile.d/Tearing.sh
Redémarrer
Note : Si cela n’apporte pas d’amélioration, il est possible de remplacer le contenu du fichier par une autre commande, à essayer donc :
export __GL_YIELD="USLEEP"
Naviguateur Chrome
Comme indiqué, Chrome limite la vidéo à 720P, mais cela est contournable avec une extension qui indique un useragent particulier, CrOS (On imagine bien qu’il s’agit de Chrome OS…) ainsi que quelques paramètres spécifiques.
Donc sous Chrome, installer l’extension suivante :
Netflix 1080p
Important : Ensuite, il faut entièrement vider le cache de Chrome, puis redémarrer Chrome.
Et cette fois, le contenu Netflix apparaîtra en 1080P, sans aucuns problème d’affichage ou de rafraîchissement. Aussi bien, voir mieux que dans Edge;>)
En pressant sur les touches
<SHIFT>+<CTRL>+<ALT>+<D>
On devra avoir la confirmation que nous sommes bien en 1920X1080
C’est gagné ! Plus besoin de rebooter sous Windows pour regarder Netflix.
Notez que ces paramètres corrigeront également les problèmes pouvant survenir sous d’autres plates-formes vidéos, comme YouTube par exemple.
Pour la 4K, il faudra encore attendre un peu, cela n’est possible que sous Edge, avec les processeurs Intel Génération 8 ou supérieur. Tout a un temps.
SSH access is always critical and you might want to find ways to improve the security of your SSH access.
In this article we will see how we can secure SSH with simple two factor authentication by using Google Authenticator. Before using it you have to integrate the SSH daemon on your server with Google Authenticator one time password protocol TOTP and another restriction is that you must have your android phone with you all the time or at least the time you want SSH access
First of all we will install the open source Google Authenticator PAM module by executing the following command on the shell.
yum install google-authenticator
The next step is to get the verification code. It’s a very simple command to get the verification code and scratch codes by just answering simple questions of server which he will ask you.
google-authenticator
Do you want authentication tokens to be time-based (y/n) y
You will get an output like the following screenshot which is being displayed to help you step by step as this step is very important and crucial.
Write down the emergency scratch codes somewhere safe, they can only be used one time each, and they’re intended for use if you lose your phone.
Do you want me to update your "/root/.google_authenticator" file? (y/n)y
Do you want
to disallow multiple uses of the same authentication token? This restricts you
to one login about every 30s, but it increases your chances to notice or even
prevent man-in-the-middle attacks (y/n) y
By default, a new token is generated every 30 seconds by the mobile app. In order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. This allows for a time skew of up to 30 seconds between authentication server and client. If you experience problems with poor time synchronization, you can increase the window from its default size of 3 permitted codes (one previous code, the current code, the next code) to 17 permitted codes (the 8 previous codes, the current code, and the 8 next codes). This will permit for a time skew of up to 4 minutes between client and server. Do you want to do so? (y/n) y
If the
computer that you are logging into isn't hardened against brute-force login
attempts, you can enable rate-limiting for the authentication module. By
default, this limits attackers to no more than 3 login attempts every 30s. Do you want
to enable rate-limiting? (y/n) y
Now download Google authenticator application – or much better Authy – on your Mobile phone, the app exists for Android and Iphone. Well I have Android so I will download it from Google Play Store where I searched it out just by typing « google authenticator » or « Authy ». « Authy » is able to backup your accounts in their Cloud in case you loose your phone…
Scan the code above with your authenticator. The Account Name should be named like root@www.ordi.ch
The next step is to change some files which we will start by first changing /etc/pam.d/sshd.
nano /etc/pam.d/sshd
Add the following line to the bottom of line:
auth required pam_google_authenticator.so
–> Save the file
Change the next file which is /etc/ssh/sshd_config.
nano /etc/ssh/sshd_config
Add the following line in the file and if its already placed then change the parameter to « yes »:
ChallengeResponseAuthentication yes
–> Save the file
Now restart the service of ssh by the following command:
service sshd restart
Last step is to test the service by connecting with SSH to the server to see if it will require verification code. You can see the following screenshot which shows the verification code that keeps on changing time after time and you have to login with it:
Next, install yum-utils which is an assortment of utilities that integrate with yum to enhance its default features, giving it more advanced package management options and also making it easier to use. A few of its important features include manipulating repositories, enabling or disabling packages on the go and lots more, without any manual configurations.
yum install yum-utils
One of the most important program provided by yum-utils is yum-config-manager, which you can use to active Remi repository as the default repository for installing various PHP versions.
yum-config-manager --enable remi-php56
Now that you’ve enabled selected versions of PHP, you can install PHP with all needed modules as follows
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.
