Archive

Archives de l'auteur

Configuration avancée du firewall iptables

10/12/2017 Comments off

Iptables c’est quoi ?

Iptables est un firewall pour les distributions linux. Wikipédia et d’autres articles expliquent ça bien mieux que moi, du coup  je ne vais pas m’attarder là dessus. Mais pour faire simple, un pare-feu système est un logiciel qui vient contrôler les flux réseaux connectés avec votre machine. Conceptuellement, le firewall va recevoir les flux réseaux, avant la socket. Il va alors appliquer différentes règles sur ce dernier, en fonction des résultats des tests par rapport à ces règles, un firewall laissera passer la connexion vers la socket ou rejettera le flux.

Les firewalls sont indispensables de nos jours en sécurité informatique, il s’agit souvent de la 1ère ligne de défense d’une machine connectée sur internet et dans le cas de réseau d’entreprise, un des éléments vraiment efficace pour limiter les rebonds d’un attaquant dans votre réseau.

Bref, les firewalls c’est bon mangez-en…

Mettre à jour Iptables en 1.6.1

Alors sur une debian 8, c’est la version 1.4.1 qui était présente sur mon serveur.  J’ai profité de ce TP pour la mettre à jour vers la dernière version. Les sources officielles sont disponibles sur le site du projet :

https://www.netfilter.org/projects/iptables/index.html

Et voici comment mettre à jour votre firewall.

Dépendances

Quelques paquets sont nécessaires à la dernière version, certains sont présents dans les dépots debian :

apt-get install libbison-dev, flex

D’autres non, et sont à télécharger et installer depuis netfilter.org .

libmnl

curl -O https://www.netfilter.org/projects/libmnl/files/libmnl-1.0.4.tar.bz2
tar xvf libmnl-1.0.4.tar.bz2
cd libmnl-1.0.4/
./configure && make
make install
cd ..
rm -Rf libmnl-1.0.4*

libnftnl

curl -O https://www.netfilter.org/projects/libnftnl/files/libnftnl-1.0.8.tar.bz2
tar xvf libnftnl-1.0.8.tar.bz2
cd libnftnl-1.0.8/
./configure && make
make install
cd ..
rm -Rf libnftnl-1.0.8*

Mettre à jour iptables 1.6.1

curl -O https://www.netfilter.org/projects/iptables/files/iptables-1.6.1.tar.bz2
tar xvf iptables-1.6.1.tar.bz2
cd iptables-1.6.1
./configure && make
make install

Je vous recommande un petit reboot, suite à l’installation comme on touche à des modules kernel.

shutdown -r now

Et vous pourrez alors vérifier que la dernière version d’iptables est bien installée à l’aide de la commande :

# iptables -V
iptables v1.6.1

Pour les N00bs, quelques règles simples

Conceptuellement, iptables fonctionne avec des « tables » et des « chains« . Si vous débutez avec iptables , considérez qu’il n’existe qu’une table de règles : « filter » dans la chaîne « INPUT« , et ne vous occupez pas (encore) du reste. Et vous devez simplement vous dire qu’un paquet TCP à destination de votre serveur va être analysé par chaque règle présente dans cette table de votre firewall pour décider s’il est accepté ou rejeter. On reviendra sur les autres tables dans la partie configuration avancée du firewall iptables plus tard dans ce tutoriel.

Le b.a.-ba d’un pare-feu c’est « d’ouvrir et de fermer » des ports TCP. Comprendre, autoriser des connexions sur certains ports TCP et les refuser sur les autres.

Pour la suite, je vais considérer qu’on configure le firewall d’un serveur web en ligne (type dedibox) avec seulement une IPv4 et que ce serveur héberge un site web en http (TCP/80) et https (TCP/443) et qu’il est administré en SSH (TCP/22). Tout le trafic TCP en entrée en dehors de ces 3 ports n’est donc pas légitime et ne devrait pas atteindre notre serveur.

Vous pouvez afficher les règles actuellement appliquée avec la commande

iptables -L -v -n

Qui normalement devrait initialement retourner que tout est accepté.

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

On va donc commencer à appliquer des règles en ligne de commande :

iptables -A INPUT -i lo -j ACCEPT # Autoriser les flux en localhost
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # Autoriser les connexions déjà établies,
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT # Autoriser SSH,
iptables -A INPUT -p tcp -m tcp --dport http -j ACCEPT # Autoriser HTTP,
iptables -A INPUT -p tcp -m tcp --dport https -j ACCEPT # Autoriser HTTPS,
iptables -P INPUT DROP # Politique par défaut de la table INPUT : DROP. (i.e bloquer tout le reste).
iptables -P FORWARD DROP # On est pas un routeur ou un NAT pour un réseau privé, on ne forward pas de paquet.

Et c’est tout, qui a dit qu’iptables c’est compliqué à paramétrer ?

Iptables-persistent
Bon c’est bien tout ça mais il reste un petit soucis  : les règles qu’on vient de configurer ne seront pas maintenues entre deux redémarrages de votre serveur. Ce qui vous oblige à les ré-appliquer à chaque reboot. C’est un peu dommage, mais il existe un paquet sous debian qui permet de recharger automatiquement un backup de règles à chaque démarrage du serveur. Il s’installe avec :

apt-get install iptables-persistent
Iptables-persistent applique au démarrage une sauvegarde de vos règles placées dans le fichier : /etc/iptables/rules.v4, et pour sauvegarder votre jeu de règles actuels dans ce fichier il suffit de faire :

iptables-save > /etc/iptables/rules.v4
Ce qui permettra à ces règles de s’appliquer après chaque reboot.

Comprendre Iptables pour les G33K.ette.s
Bon si vous êtes un $crIpT kIddI3, vous devriez vous arrêtez là. Pour les autres, Iptables c’est très très puissant comme outils, vous pouvez lui faire faire beaucoup de choses, du log des connexions sur le systèmes aux règles anti-DDOS et anti-portscan en passant par l’équilibrage charge des connexions entrantes sur vos CPU. Autant vous dire qu’il y a du boulot et qu’on va allègrement dépasser les cinq lignes de configurations précédentes…

Mais avant de recevoir ces règles on va devoir rentrer un petit plus en détails dans le fonctionnement d’Iptables.

Chains & Table
Le site Iptables.info fournis un excellent schéma pour comprendre le cheminement que va faire un paquet dans iptables :

 

Dans le cadre d’un filtrage de sécurité pour le serveur web décrit plus haut, ce sont les chains PREROUTING et INPUT qui vont nous intéresser. Les autres auront un intérêt si vous positionnez votre firewall en coupure (sur un routeur par exemple). Ici seules les connexions entrantes à destination de notre serveur sont intéressantes.

Un paquet à destination de notre serveur va donc passer dans l’ordre par les tables suivantes  :

PREROUTING – raw
PREROUTING – mangle
PREROUTING – nat
INPUT – mangle
INPUT – filter
Et si ce paquet ne se fait pas droper par une de ces table, et atteint une règle finissant en ACCEPT (puisqu’on a mis une policy DROP sur INPUT), il sera transféré vers le service réseau demandé.

Règles, tables, chains  : pourquoi tant d’objets ?
Alors pourquoi définir certaines règles dans une table plutôt qu’une autre ? Et bien pour des raisons de performances, assez logiquement : plus un paquet est « dropé » tôt par iptables et moins il aura consommé de ressources systèmes puisqu’il sera passé par moins de test dans iptables. Mais dans ce cas, pourquoi ne pas mettre toutes nos règles en PREROUTING – raw  ? Simplement parce que les couples « chains-table » d’iptables ne permettent pas tous d’effectuer les mêmes opérations. Si kes règles dans INPUT-filter permettent de définir des règles très complexes, elles seront aussi plus consommatrices de ressources CPU que les règles en PREROUTING qui ne peuvent exprimer que des tests « simples » mais aussi très rapide à traiter.

La conséquence de tout ça c’est que vous avez intérêt à remonter autant que possible vos règles « vers le haut » dans le schéma pour essayer de droper un maximum de paquets en PREROUTING la où cela consommera le moins de ressources et ne garder que les règles compliquées dans INPUT-filter pour bloquer les attaques les plus évoluées.

Et les performances, quand on se mange un attaque DDOS ça compte !

Configuration avancée du firewall iptables… pour les G33K.ette.s
Sysconfig time !
Et malheureusement, une partie des règles que l’on va définir ci-dessous nécessites des réglages noyaux particuliers. Je ne détaille pas tous les réglages : la plupart trouve leur explication dans les sources que j’ai référencées à la fin de cet article. Allons-y, il faut modifier le fichier /etc/sysctl.conf sur votre serveur pour ajouter les réglages suivants :

# Enable Spoof protection (reverse-path filter) Turn on Source Address Verification in all interfaces to prevent some spoofing attacks
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1
# Enable SYN Cookie
net.ipv4.tcp_syncookies=1
# Do not accept ICMP redirects (prevent some MITM attacks)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
# Accept ICMP redirects only for gateways listed in our default gateway list (enabled by default)
net.ipv4.conf.all.secure_redirects = 1
# Do not send ICMP redirects (we are not a router)
net.ipv4.conf.all.send_redirects = 0
# Do not accept IP source route packets (we are not a router)
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
#do not allow ACK pkts to create new connection (normal behavior SYN->, <-SYN,ACK, ACK->)
net.netfilter.nf_conntrack_tcp_loose=0
#enable TCP timestamps as SYN cookies utilize this TCP
net.ipv4.tcp_timestamps=1
#Conntrack Entry Tuning (Calculate your own values ! depending on your hardware)
net.netfilter.nf_conntrack_max=200000
Plus un dernier tweak :

echo ‘options nf_conntrack hashsize=500000’ > /etc/modprobe.d/nf_conntrack.conf # (Calculate your own values ! depending on your hardware)
mais qui nécessite un reboot pour être appliquée, donc on le place directement :

echo 500000 > /sys/module/nf_conntrack/parameters/hashsize
Vous pouvez alors appliquer ces modifications ainsi :

sysctl -p
Passons aux règles iptables.

Configuration avancée du firewall iptables
Note : A partir de maintenant je ne donne plus les règles à appliquer dans le format « ligne de commande » mais dans le format fichier de sauvegarde iptables issue du iptables-save. Pour appliquer ces nouvelles règles il faut alors modifier le fichier/etc/iptables/rules.v4, et exécuter commande suivante :

iptables-restore < /etc/iptables/rules.v4
Ce mode de fonctionnement permet d’appliquer plusieurs règles « en même temps » et en travaillant sur un fichier. Ce qui est plus pratique que d’appliquer des modifs en live sans se rappeler de la ligne précédente…
Règles anti « bordel d’internet »
Vous seriez surpris du nombre de tentatives de connexions TCP bizarres qu’on trouve sur Internet : Xmas Scan par nmap n’est un exemple avec toutes les flags TCP à 1. Du coup, voici un jeu de règles permettant de rejeter sans trop se poser de questions les connexions TCP avec des combinaisons de flag impossibles ou improbables :

*mangle
# paquet avec SYN et FIN à la fois
-A PREROUTING -p tcp -m tcp –tcp-flags FIN,SYN FIN,SYN -j DROP
# paquet avec SYN et RST à la fois
-A PREROUTING -p tcp -m tcp –tcp-flags SYN,RST SYN,RST -j DROP
# paquet avec FIN et RST à la fois
-A PREROUTING -p tcp -m tcp –tcp-flags FIN,RST FIN,RST -j DROP
# paquet avec FIN mais sans ACK
-A PREROUTING -p tcp -m tcp –tcp-flags FIN,ACK FIN -j DROP
# paquet avec URG mais sans ACK
-A PREROUTING -p tcp -m tcp –tcp-flags ACK,URG URG -j DROP
# paquet avec PSH mais sans ACK
-A PREROUTING -p tcp -m tcp –tcp-flags PSH,ACK PSH -j DROP
# paquet avec tous les flags à 1 <=> XMAS scan dans Nmap
-A PREROUTING -p tcp -m tcp –tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
# paquet avec tous les flags à 0 <=> Null scan dans Nmap
-A PREROUTING -p tcp -m tcp –tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
# paquet avec FIN,PSH, et URG mais sans SYN, RST ou ACK
-A PREROUTING -p tcp -m tcp –tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
# paquet avec FIN,SYN,PSH,URG mais sans ACK ou RST
-A PREROUTING -p tcp -m tcp –tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,PSH,URG -j DROP
# paquet avec FIN,SYN,RST,ACK,URG à 1 mais pas PSH
-A PREROUTING -p tcp -m tcp –tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j DROP
On peut également établir d’autres règles de filtrage triviales basées sur les IP sources en dropant tout ce qui arrive d’un réseau privé/réservé. C’est du spoofing d’IP source, c’est très peu probable pour un serveur avec uniquement une IP publique sur Internet.

*mangle
-A PREROUTING -s 224.0.0.0/8 -j DROP
-A PREROUTING -s 169.254.0.0/16 -j DROP
-A PREROUTING -s 172.16.0.0/12 -j DROP
-A PREROUTING -s 192.0.2.0/24 -j DROP
-A PREROUTING -s 192.168.0.0/16 -j DROP
-A PREROUTING -s 10.0.0.0/8 -j DROP
-A PREROUTING -s 0.0.0.0/8 -j DROP
-A PREROUTING -s 240.0.0.0/5 -j DROP
-A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP
Et voilà, après j’ai quelques règles bonus dans le même genre que je vous met à la fin.

Règles anti-DDOS
Le principe d’un DDOS est de saturer le serveur de requêtes jusqu’a ce qu’il s’effondre par manque de ressources. La défense locale au serveur consiste à droper le plus efficacement possible toutes les demandes de connexions anormales. Il existe différent type de DDOS, certains se contente de spammer des SYN vers votre serveur (en espérant ouvrir plein de connexions en attente, et saturer votre machine de connexion en attente) et d’autre allant un peu plus loin dans le 3-way handshake TCP (3WHS) toujours avec le même objectif. L’idée dans la tête de l’attaquant c’est de faire plein d’opérations peu coûteuses pour lui (établir des connexions TCP avec votre serveur et ne pas les suivre) et coûteuses pour votre machine (garder ouvertes tout un tas de connexions en attentes ou inactive)

Loose et invalid state
Un des premières règles consiste à désactiver le mode  « loose » (ça ne s’invente pas) de votre kernel. Ce dernier autorise par défaut un paquet ACK ouvrir une connexion sur votre serveur (sautant ainsi les deux premières étapes du 3WHS).

On a déjà fait ça plus haut en mettant l’option nf_conntrack_tcp_loose à 0 dans le kernel. Combiné ça avec une règle qui drop les connexions dans un état invalide et vous empêchez ces paquets ACK d’établir des connexions avec votre serveur.

*filter
-A INPUT -m state –state INVALID -j DROP
SynProxy
Synproxy est un mécanisme introduit dans la 1.4.1 d’iptables pour permettre de répondre efficacement aux attaques par SYN flooding (i.e. noyer le serveur sous des demandes de SYN qui ne seront pas suivi ACK). Le principe est de sortir les paquets SYN du connection-tracker d’iptables (conntrack) dont les opérations sont assez coûteuses en ressources et d’établir à la places les connexions au travers d’un proxy-TCP optimisé pour traiter spécifiquement ce type de demandes et ne transmettre à votre serveur que les connexions TCP correctement établies.

 

On peut le mettre en place à l’aide des lignes suivantes :

*raw
# 1. en -t raw, les paquets TCP avec le flag SYN à destination des ports 22,80 ou 443 ne seront pas suivi par le connexion tracker (et donc traités plus rapidement)
-A PREROUTING -i eth0 -p tcp -m multiport –dports 22,80,443 -m tcp –tcp-flags FIN,SYN,RST,ACK SYN -j CT –notrack

*filter
# 2. en input-filter, les paquets TCP avec le flag SYN à destination des ports 22,80 ou 443 non suivi (UNTRACKED ou INVALID) et les fais suivre à SYNPROXY.
# C’est à ce moment que synproxy répond le SYN-ACK à l’émeteur du SYN et créer une connexion à l’état ESTABLISHED dans conntrack, si et seulement si l’émetteur retourne un ACK valide.
# Note : Les paquets avec un tcp-cookie invalides sont dropés, mais pas ceux avec des flags non-standard, il faudra les filtrer par ailleurs.
-A INPUT -i eth0 -p tcp -m multiport –dports 22,80,443 -m tcp -m state –state INVALID,UNTRACKED -j SYNPROXY –sack-perm –timestamp –wscale 7 –mss 1460

# 3. en input-filter, la règles SYNPROXY doit être suivi de celle-ci pour rejeter les paquets restant en état INVALID.
-A INPUT -i eth0 -p tcp -m multiport –dports 22,80,443 -m tcp -m state –state INVALID -j DROP
Cette partie mérite qu’on s’y attarde un peu. La première règle se fait en PREROUTING-raw dès la réception du paquet, empêchant ainsi toute consommation inutile de mémoire. Notre paquet passera ensuite en PREROUTING-mangle, permettant de filtrer les paquets anormaux, et arrivera alors à la règle 2 ou SYN-PROXY fera son boulot créer des connexions ESTABLISHED seulement lorsque le client effectue un 3WHS valide. La dernière règle rejette enfin toutes les connexions restantes dans un état INVALID, appliquant au passage la protection contre les états invalides qu’on a vu juste avant.

Maîtrise de charge
Bon on s’est protégé des DDOS simples à base de SYN et de ACK TCP, mais on ne fait rien pour gérer un surnombre de connexions normales qui atteignent l’état ESTABLISHED. Potentiellement toutes ces connexions sont légitimes, du coup soit on laisse tout passer, soit on essaye de limiter la casse.

Pour cela, une technique consiste à regrouper les IP sources par bloc de 256 (i.e par subnet source en /24) et de n’autoriser qu’un nombre maximum de demandes de connexions SYN par seconde pour chaque subnet. On peut faire ça avec le module hashlimit. Cela aura le mérite mettre un plafond de connexion par seconde vers votre serveur par groupe de 256 IP.

*raw
-A PREROUTING -i eth0 -p tcp -m tcp –syn -m multiport –dports 22,80,443 -m hashlimit –hashlimit-above 200/sec –hashlimit-burst 1000 –hashlimit-mode srcip –hashlimit-name syn –hashlimit-htable-size 2097152 –hashlimit-srcmask 24 -j DROP
On peut appliquer une règle similaire sur le nombre de connexions maximum autorisées en simultané par une seule IP source à l’aide du module connlimit.

*filter
-A INPUT -i eth0 -p tcp -m connlimit –connlimit-above 100 -j REJECT
Ce qui empêchera une seule IP de créer un nombre insensé de connexions avec votre serveur.

Blacklisting portscanner
Une technique que l’on a pas abordée pour l’instant c’est le portscan, un petit man nmap vous en dira plus si vous ne savez pas ce que c’est. En gros, un attaquant cherche à découvrir quels sont les services ouverts sur votre serveur et va tenter d’établir une connexion TCP (plus ou moins valide) sur tous les ports courants, voire carrément les 65535 ports, et attendre la réponse du serveur pour détecter ceux ouvert.

Une première technique consiste à limiter le nombre de paquets typique d’un scan, Il y a cet article qui explique bien comment on fait ça. Mais pour ma part, je ne vois pas l’intérêt de limiter ce qu’on peut droper directement… du coup la plupart de mes règles anti « bordel d’internet » plus haut avec le SYNPROXY force déjà l’attaquant à faire un 3WHS dans les règles pour voir ce qui se passe la ou c’est ouvert, et la policy DROP en INPUT jettera tout le reste…

Du coup on peut passer à une règle que je trouve plus rigolote, qui consiste à « piéger des ports » qui ne sont pas utilisés sur la machine, et blacklister pour un certains temps les machines qui essayer de s’y connecter.

On peut faire ça avec les règles suivantes.

*filter
-A INPUT -m recent –rcheck –seconds 86400 –name portscan –mask 255.255.255.255 –rsource -j DROP
-A INPUT -m recent –remove –name portscan –mask 255.255.255.255 –rsource
-A INPUT -p tcp -m multiport –dports 25,445,1433,3389 -m recent –set –name portscan –mask 255.255.255.255 –rsource -j DROP
Alors attention avec cette règle, un attaquant motivé qui s’en rendrait compte, pourrait forger des paquets TCP (qui a dit Scapy ?) à destination d’un de ces ports mais avec des IP sources fausses. Conséquence : votre serveur va se mettre à blacklister tout internet pour 24h si l’attaquant décide de parcourir la plage IPv4 complète… Du coup, c’est une règle qui fonctionne bien sur un petit serveur perso sans prétention mais je n’irai pas la mettre en production sur un frontal-web d’une grande boite… Et pensez à mettre en whitelist votre IP personnelle ou du boulot avec cette règle, ça vous évitera de vous faire jeter pour 24h le jour ou vous l’aurez oublié et que vous lancerez un scan de votre machine :

! -s <IPperso>,<IPboulots>[/NETMASK]Notez aussi que vous pouvez voir quelles sont les IP blacklistées dans le fichier :

/proc/net/xt_recent/portscan
C’est bon moyen de faire une liste d’IP pourries sur lesquels tester un nmap…^^

Et enfin, accepter les connexions sur des port.
Déjà vu plus haut, pour finir on autorise enfin des connexions entrantes :

*filter
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack –ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport –dports 22,80,443 -j ACCEPT
Bonus

Bon il me reste quelques règles bonus ou optionnelles à vous proposer, en liste à la Prévert :

On dégage le ping :

*mangle
-A PREROUTING -p icmp -j DROP
Bloquer la fragmentation TCP

*mangle
-A PREROUTING -f -j DROP
Notez pour finir que Fail2ban ajoute tout seul des règles dans votre firewall iptables, mais j’en ai déjà parlé dans cet article.

Conclusion
Ça vous a paru long ? je n’ai fais qu’effleurer la surface de l’iceberg iptables, je vous invite à parcourir les 2477 lignes du man iptables-extensions pour vous rendre compte des possibilités offerte par iptables. Dans les choses sympa que je vous invite à creuser par vous même :

La target LOG qui vous permettra de journaliser les connexions qui vous intéresses (méfiez-vous ça peut cracher un paquet de lignes)
Le module CPU pour mettre en oeuvre une répartition de charge de l’établissement des connexions TCP sur les différents CPU de votre serveur.
Le module time qui permet par exemple de fermer un service automatiquement le weekend ou à certaines heures.
Voilà, j’ai eu du mal à trouver un ensemble de règles « à peu près correctes » dehors (par contre j’ai trouvé pas mal de n’importe quoi…^^). Donc j’espère que ça en aidera certains, et posez vos questions dans les commentaires !

Trashing files not going to the trash bin

23/11/2017 Comments off

Click on the item in the Finder’s sidebar with the house icon and verify that you are able to write to this folder in the Ownership & Permissions section of the Get Info window, and that it isn’t locked; if it is already set this way and you get that error, open the Terminal in the /Applications/Utilities/ folder and run the following:

mkdir ~/.Trash

If you get a message stating that the folder exists, run the following:

sudo chown $UID ~/.Trash
chmod u+rwx ~/.Trash

The first command in the second set will prompt you for your administrator password; nothing will appear in the Terminal window while it is being typed. In either case, click on the Finder icon in the Dock with the Control and Option keys pressed, and relaunch it.


Categories: Système Tags: ,

How-To Factory Reset MacBook Air and other macs with macOS

21/11/2017 Comments off

There are many reasons why you’d want to reset your MacBook Air to factory settings. Perhaps your Mac is showing just a too much little lag. Maybe you want to reset for better overall performance, are thinking of giving away or selling your MacBook after you purchase or receive the latest Mac model. For whatever reason, you need to set your Mac back to its factory defaults.

 

Since our Macs hold so much of our personal and private data, it’s imperative to clean out our machines when selling or giving away our favorite older Macs. And it’s particularly useful for the new user to have a nice clean machine that’s returned to its native factory state.

 

Lire la suite…

Categories: Système Tags: , ,

Where to Set Environment Variables in Mac OS X

20/11/2017 Comments off

At the command line, environmental variables are defined for the current shell and become inherited by any running command or process. They can determine anything from the default shell, the PATH, the users home directory, to the terminal emulation type, current working directory, where a history file is located, language and localization settings, and going further to include shell variables, which include everything from customizations to the bash prompt, colorized ls output, and changes to terminal appearance, to aliases, and much more.

 

Let’s walk through how to list environment and shell variables, and then how to set and add new environment variables at the command line of Mac OS X.

Displaying Current Environment & Shell Variables in Mac OS X

To quickly get a list of environmental variables, you can use the following command:

printenv

If you want to see a complete list of shell variables, the ‘set’ command can be issued as well:

set

The output of these commands can be lengthy so you may wish to pipe the output through the less or more commands.
Lire la suite…

Categories: Système Tags: , ,

How To Use Apache JMeter To Perform Load Testing on a Web Server

12/11/2017 Comments off

Introduction

In this tutorial, we will go over how to use Apache JMeter to perform basic load and stress testing on your web application environment. We will show you how to use the graphical user interface to build a test plan and to run tests against a web server.

JMeter is an open source desktop Java application that is designed to load test and measure performance. It can be used to simulate loads of various scenarios and output performance data in several ways, including CSV and XML files, and graphs. Because it is 100% Java, it is available on every OS that supports Java 6 or later.

 

Prerequisites

In order to follow this tutorial, you will need to have a computer that you can run JMeter on, and a web server to load test against. Do not run these tests against your production servers unless you know they can handle the load, or you may negatively impact your server’s performance.

You may adapt the tests in this tutorial to any of your own web applications. The web server that we are testing against as an example is a 1 CPU / 512 MB VPS running WordPress on a LEMP Stack, in the NYC2 DigitalOcean Datacenter. The JMeter computer is running in the DigitalOcean office in NYC (which is related to the latency of our tests).

Please note that the JMeter test results can be skewed by a variety of factors, including the system resources (CPU and RAM) available to JMeter and the network between JMeter and the web server being tested. The size of the load that JMeter can generate without skewing the results can be increased by running the tests in the non-graphical mode or by distributing the load generation to multiple JMeter servers.  Lire la suite…

How to Optimize MySQL Performance Using MySQLTuner

05/11/2017 Comments off

Running MySQL at optimal settings for specific resources helps handle larger server loads and prevents server slowdown. Generally, after tuning Apache to handle larger loads, it is beneficial to tune MySQL to additional connections.

MySQL tuning title graphic

Database tuning is an expansive topic, and this guide covers only the basics of editing your MySQL configuration. Large MySQL databases can require a considerable amount of memory. For this reason, we recommend using a high memory Linode for such setups.

The steps in this guide require root privileges. Be sure to run the steps below as root or with the sudo prefix. For more information on privileges see our Users and Groups guide.

Tools That Can Help Optimize MySQL

In order to determine if your MySQL database needs to be reconfigured, it is best to look at how your resources are performing now. This can be done with the top command or with the Linode Longview service. At the very least, you should familiarize yourself with the RAM and CPU usage of your server, which can be discovered with these commands:

1
2
echo [PID]  [MEM]  [PATH] &&  ps aux | awk '{print $2, $4, $11}' | sort -k2rn | head -n 20
ps -eo pcpu,pid,user,args | sort -k 1 -r | head -20

MySQLTuner

The MySQLTuner script assesses your MySQL installation, and then outputs suggestions for increasing your server’s performance and stability.

  1. Download and run MySQLTuner:

    1
    curl -L http://mysqltuner.pl/ | perl
    
  2. It outputs your results:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
     >>  MySQLTuner 1.4.0 - Major Hayden <major@mhtx.net>
     >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
     >>  Run with '--help' for additional options and output filtering
    Please enter your MySQL administrative login: root
    Please enter your MySQL administrative password:
    [OK] Currently running supported MySQL version 5.5.41-0+wheezy1
    [OK] Operating on 64-bit architecture
    
    -------- Storage Engine Statistics -------------------------------------------
    [--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
    [--] Data in InnoDB tables: 1M (Tables: 11)
    [--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
    [!!] Total fragmented tables: 11
    
    -------- Security Recommendations  -------------------------------------------
    [OK] All database users have passwords assigned
    
    -------- Performance Metrics -------------------------------------------------
    [--] Up for: 47s (113 q [2.404 qps], 42 conn, TX: 19K, RX: 7K)
    [--] Reads / Writes: 100% / 0%
    [--] Total buffers: 192.0M global + 2.7M per thread (151 max threads)
    [OK] Maximum possible memory usage: 597.8M (60% of installed RAM)
    [OK] Slow queries: 0% (0/113)
    [OK] Highest usage of available connections: 0% (1/151)
    [OK] Key buffer size / total MyISAM indexes: 16.0M/99.0K
    [!!] Query cache efficiency: 0.0% (0 cached / 71 selects)
    [OK] Query cache prunes per day: 0
    [OK] Temporary tables created on disk: 25% (54 on disk / 213 total)
    [OK] Thread cache hit rate: 97% (1 created / 42 connections)
    [OK] Table cache hit rate: 24% (52 open / 215 opened)
    [OK] Open file limit used: 4% (48/1K)
    [OK] Table locks acquired immediately: 100% (62 immediate / 62 locks)
    [OK] InnoDB buffer pool / data size: 128.0M/1.2M
    [OK] InnoDB log waits: 0
    -------- Recommendations -----------------------------------------------------
    General recommendations:
        Run OPTIMIZE TABLE to defragment tables for better performance
        Enable the slow query log to troubleshoot bad queries
    Variables to adjust:
        query_cache_limit (> 1M, or use smaller result sets)
    

    MySQLTuner offers suggestions regarding how to better the database’s performance. If you are wary about updating your database on your own, following MySQLTuner’s suggestions is one of the safer ways to improve your database performance.

Tuning MySQL

When altering the MySQL configuration, be alert to the changes and how they affect your database. Even when following the instructions of programs such as MySQLTuner, it is best to have some understanding of the process.

The file you are changing is located at /etc/mysql/my.cnf.

Prior to updating the MySQL configuration, create a backup of the my.cnf file:

1
cp /etc/mysql/my.cnf ~/my.cnf.backup

Best practice suggests that you make small changes, one at a time, and then monitor the server after each change. You should restart MySQL after each change:

  • For systems without systemd:

    1
    systemctl restart mysqld
    
  • For distributions which don’t use systemd:

    1
    service mysql restart
    

When changing values in the my.cnf file, be sure that the line you are changing hasn’t been commented out with the pound (#) prefix.

key_buffer

Changing the key_buffer allocates more memory to MySQL, which can substantially speed up your databases, assuming you have the memory free. The key_buffer size should generally take up no more than 25 percent of the system memory when using the MyISAM table engine, and up to 70 percent for InnoDB. If the value is set too high, resources are wasted.

According to MySQL’s documentation, for servers with 256MB (or more) of RAM with many tables, a setting of 64M is recommended. Servers with 128MB of RAM and fewer tables can be set to 16M, the default value. Websites with even fewer resources and tables can have this value set lower.

max_allowed_packet

This parameter lets you set the maximum size of a sendable packet. A packet is a single SQL state, a single row being sent to a client, or a log being sent from a master to a slave. If you know that your MySQL server is going to be processing large packets, it is best to increase this to the size of your largest packet. Should this value be set too small, you would receive an error in your error log.

thread_stack

This value contains the stack size for each thread. MySQL considers the default value of the thread_stack variable sufficient for normal use; however, should an error relating to the thread_stack be logged, this can be increased.

thread_cache_size

If thread_cache_size is “turned off” (set to 0), then any new connection being made needs a new thread created for it. When the connections disengage the thread is destroyed. Otherwise, this value sets the number of unused threads to store in a cache until they need to be used for a connection. Generally this setting has little affect on performance, unless you are receiving hundreds of connections per minute, at which time this value should be increased so the majority of connections can be made on cached threads.

max_connections

This parameter sets the maximum amount of concurrent connections. It is best to consider the maximum amount of connections you have had in the past before setting this number, so you’ll have a buffer between that upper number and the max_connections value. Note, this does not indicate the maximum amount of users on your website at one time; rather it shows the maximum amount of users making requests concurrently.

table_cache

This value should be kept higher than your open_tables value. To determine this value use:

1
SHOW STATUS LIKE 'open%';

 

10 essential performance tips for MySQL

05/11/2017 Comments off

As with all relational databases, MySQL can prove to be a complicated beast, one that can crawl to a halt at a moment’s notice, leaving your applications in the lurch and your business on the line.

The truth is, common mistakes underlie most MySQL performance problems. To ensure your MySQL server hums along at top speed, providing stable and consistent performance, it is important to eliminate these mistakes, which are often obscured by some subtlety in your workload or a configuration trap.

Luckily, many MySQL performance issues turn out to have similar solutions, making troubleshooting and tuning MySQL a manageable task.

Here are 10 tips for getting great performance out of MySQL.

MySQL performance tip No. 1: Profile your workload

The best way to understand how your server spends its time is to profile the server’s workload. By profiling your workload, you can expose the most expensive queries for further tuning. Here, time is the most important metric because when you issue a query against the server, you care very little about anything except how quickly it completes.

The best way to profile your workload is with a tool such as MySQL Enterprise Monitor’s query analyzer or the pt-query-digest from the Percona Toolkit. These tools capture queries the server executes and return a table of tasks sorted by decreasing order of response time, instantly bubbling up the most expensive and time-consuming tasks to the top so that you can see where to focus your efforts.

Workload-profiling tools group similar queries together, allowing you to see the queries that are slow, as well as the queries that are fast but executed many times.

Lire la suite…

How To Improve Database Searches with Full-Text Search in MySQL 5.6 on Ubuntu 16.04

05/11/2017 Comments off

Introduction

Full-text search, or FTS, is a technique used by search engines to find results in a database. You can use it to power search results on websites like shops, search engines, newspapers, and more.

More specifically, FTS retrieves documents that don’t perfectly match the search criteria. Documents are database entities containing textual data. This means that when a user searches for « cats and dogs », for example, an application backed by FTS is able to return results which contain the words separately (just « cats » or « dogs »), contain the words in a different order (« dogs and cats »), or contain variants of the words (« cat » or « dog »). This gives applications an advantage in guessing what the user means and returning more relevant results faster.

Technically speaking, database management systems (DBMS) like MySQL usually allow partial text lookups using LIKE clauses. However, these requests tend to underperform on large datasets. They’re also limited to matching the user’s input exactly, which means a query might produce no results even if there are documents with relevant information.

Using FTS, you can build a more powerful text search engine without introducing extra dependencies on more advanced tools. In this tutorial, you will use MySQL 5.6 to query a database using full-text search, then quantify the results by their relevance to the search input and display only the best matches.

 

Prerequisites

Before you begin this tutorial, you will need:

Lire la suite…

Categories: Système Tags: ,

How To Install and Secure phpMyAdmin on Ubuntu 16.04

05/11/2017 Comments off

Introduction

While many users need the functionality of a database management system like MySQL, they may not feel comfortable interacting with the system solely from the MySQL prompt.

phpMyAdmin was created so that users can interact with MySQL through a web interface. In this guide, we’ll discuss how to install and secure phpMyAdmin so that you can safely use it to manage your databases from an Ubuntu 16.04 system. 

Prerequisites

Before you get started with this guide, you need to have some basic steps completed.

First, we’ll assume that you are using a non-root user with sudo privileges, as described in steps 1-4 in the initial server setup of Ubuntu 16.04.

We’re also going to assume that you’ve completed a LAMP (Linux, Apache, MySQL, and PHP) installation on your Ubuntu 16.04 server. If this is not completed yet, you can follow this guide on installing a LAMP stack on Ubuntu 16.04.

Finally, there are important security considerations when using software like phpMyAdmin, since it:

  • Communicates directly with your MySQL installation
  • Handles authentication using MySQL credentials
  • Executes and returns results for arbitrary SQL queries

For these reasons, and because it is a widely-deployed PHP application which is frequently targeted for attack, you should never run phpMyAdmin on remote systems over a plain HTTP connection. If you do not have an existing domain configured with an SSL/TLS certificate, you can follow this guide on securing Apache with Let’s Encrypt on Ubuntu 16.04.

Once you are finished with these steps, you’re ready to get started with this guide.

Lire la suite…

How To Measure MySQL Query Performance with mysqlslap

05/11/2017 Comments off

Introduction

MySQL comes with a handy little diagnostic tool called mysqlslap that’s been around since version 5.1.4. It’s a benchmarking tool that can help DBAs and developers load test their database servers.

mysqlslap can emulate a large number of client connections hitting the database server at the same time. The load testing parameters are fully configurable and the results from different test runs can be used to fine-tune database design or hardware resources.

In this tutorial we will learn how to use mysqlslap to load test a MySQL database with some basic queries and see how benchmarking can help us fine-tune those queries. After some basic demonstrations, we will run through a fairly realistic test scenario where we create a copy of an existing database for testing, glean queries from a log, and run the test from a script.

The commands, packages, and files shown in this tutorial were tested on CentOS 7. The concepts remain the same for other distributions. Lire la suite…