Explications sur le blog bientôt

Posts similaires

• Modifier les droits récursivement
• Script de modification de texte dans un répertoire

On peut s’occuper de sécurité mais on ne pourra jamais l’atteindre complètement. L’aspect sécuritaire sur un site web couvre deux aspects. Il y a tout d’abord l’interface web qui est présentée au public, et qui peut comporter des failles de programmation (sql injection, mauvaise sécurisation de la zone administrateur, …), et ensuite le serveur lui même, qui peut comporter des failles de sécurité (système d’exploitation, droits d’utilisateurs, …).

Cet article couvrira uniquement les aspects “serveur”. Je traiterai peut être les aspects logiciels dans un autre article. Il sera question d’un serveur Apache avec php et mysql installés tournant sous linux.

Il faut considérer la sécurité comme un oignon, pour sécuriser un système on le fera par couches successives. Pour sécuriser le serveur on considérera les deux couches suivantes (qui se sépareront en sous couches lorsque l’on voudra sécuriser encore mieux le système) : l’aspect réseau, et l’aspect système de fichiers.

A lire :

http://www.soyo123.com/HardeningLinux

http://www.freesoftwaremagazine.com/articles/hardening_linux

Le Réseau :

On va tenter de sécuriser les logiciels qui servent d’interface entre le serveur et le web.

Ecoute des ports :

La première chose à faire est d’écouter les ports de son serveur. Pour cela deux outils : netstat et nmap.

$ netstat -l -n -p -t -u -w

-l pour écouter (listenning)

-n pour voir des informations sur l’IP

-p sert à recueillir des informations sur le processus qui utilise le port

-t, -u, -w pour les connections TCP, Udp, et Raw

$ nmap -sS 127.0.0.1

Starting Nmap 4.20 ( http://insecure.org ) at 2008-04-26 19:52 CEST
 Interesting ports on localhost.localdomain (127.0.0.1):
 Not shown: 1689 closed ports
 PORT STATE SERVICE
 22/tcp open ssh
 25/tcp open smtp
 80/tcp open http
 143/tcp open imap
 631/tcp open ipp
 3306/tcp open mysql
 8000/tcp open http-alt
 8080/tcp open http-proxy

Sert à recueillir des informations sur les ports ouverts par les processus du serveur.

Configuration du pare-feu :

(A lire : guide OVH)

Iptables est un pare-feu élémentaire qui nous servira à protéger l’accès à notre serveur. Iptables est configuré par un ensemble de règles qui vont définir les comportements à suivre pour les instructions entrantes, sortantes et transmises. Pour afficher les règles en cours :

$ iptables --list

Nous allons les effacer, afin de reprendre au début la configuration :

$ iptables -F

Pour donner une structure globale du paramétrage du pare-feu serait le suivant :

1. Permettre les connexions sortantes initiées par le serveur
2. Autoriser les connexion entrantes en ssh sur le port 22 (obligatoire sinon vous ne pourrez plus accéder à votre serveur à distance)
   
3. Autoriser les connexion entrantes en http sur le port 80
4. Autoriser le https sur le port 443
5. Autoriser les requêtes internes
6. Bloquer toutes les connexions ssh sortantes
7. Bloquer tout le reste

Ce qui donne :

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
iptables -A INPUT -s 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 22 -j DROP
iptables -A INPUT -j REJECT
iptables -A FORWARD -j DROP

Enfin, je sauve ces règles que je pourrai restaurer :

iptables-save > /root/firewall
iptables-restore -c /root/firewall

NB : pour mon serveur, j’ai rajouté les requêtes entrantes sur les ports qui m’intéressent

ATTENTION : il est possible de restaurer le pare feu au démarrage de la machine. Or si celui-ci a été mal réglé (accès au ssh impossible par exemple ), il vous sera impossible d’accéder à votre serveur. Si jamais vous avez vérifier que toutes les requêtes aboutissaient, le lancement automatique se fera dans le dossier : /etc/init.d (voir articles dédié plus tard).

NOTE : Chez OVH il est important de mettre le rejet des input en REJECT. En effet,à la différence de DROP, les paquets sont traités lors d’un REJECT, et l’envoyeur reçoit un message d’erreur. Les services de OVH se basant sur un ping régulier des serveurs qu’ils hébergent, si vous placez un DROP à cet endroit, OVH pensera que votre machine s’est débranché du réseau, et la fera rebooter sans vous demander votre avis.

Sécuriser SSH :

Changer le port de connexion : fichier de configuration : /etc/ssh/sshd_config.

Remplacer la ligne :

# What ports, IPs and protocols we listen for
Port 22

par

# What ports, IPs and protocols we listen for
Port 2200

IMPORTANT : n’oubliez pas de rajouter le nouveau port en lecture sur iptables, et de retirer l’ancien :

 & iptables -A INPUT -p tcp -m tcp --dport 2200 -j ACCEPT
$ iptables -D INPUT "numéro de la règle concernant le port 22"

Redémarrez ensuite le processus :

$ /etc/init.d/ssh restart

Les fichiers de configuration :

Si votre système n’est pas encore envahi (le mieux étant donc de réaliser les étapes de sécurisation avant la mise en ligne du serveur si possible), il est intéressant de vérifier que vos fichiers de configuration restent inchangés dans le temps. Si cela n’est pas le cas, il s’agit sûrement d’un intrus qui a modifié les fichiers de base de votre système.

Il existe plusieurs Intrusion Detection System (IDS). Leur rôle est d’enregistrer dans une base de données des informations concernant les répertoires que vous aurez sélectionnés (configuration et autre), afin de vérifier rapidement si ces fichiers ont subi une modification depuis la création de la base de données. De manière grossière, ce type de logiciel vérifie la date de création et la taille des différents fichiers contenus dans les répertoire cibles afin de vérifier la concordance.

On utilisera ici le logiciel fcheck.

Installer le (compilation / apt-get install) et vérifier que la configuration indique bien :

# Directories that will be monitored
# if there is a trailing / it will be recursive

Directory = /etc/
Directory = /bin/
Directory = /sbin/
Directory = /lib/
Directory = /usr/bin/
Directory = /usr/sbin/
Directory = /usr/lib/
TimeZone = PST8PDT # For Pacific Standard

# Database of file signatures

DataBase = /usr/local/fcheck/sol.dbf
Logger = /usr/bin/logger -t fcheck

# Utility to determin file type
FileTyper = /bin/file

# What to use to create signatures Database of
# file signatures

$Signature = /usr/bin/md5sum#
DataBase = /usr/local/fcheck/sol.dbf
Logger = /usr/bin/logger -tfcheck

# Utility to determin file type

FileTyper = /bin/file

A présent, il faut initialiser la base de données pour qu’elle possède ses signatures à jour :

$ fcheck -cadsx

A suivre…

Posts similaires

• Configurer Apache
• Prévenir les pirates grâce aux erreurs 404
• Protection contre les spameur de liens

Les Virtual Hosts

Article à lire ici :

http://www.unix-girl.com/geeknotes/apache_virtual_host_conf.html

Ressource officielle ici :

http://httpd.apache.org/docs/1.3/vhosts/

Configuration sous OVH :

Sur mon serveur OVH, le fichier de conf se trouve à l’adresse : /etc/apache2/apache2.conf ( et non pas httpd.conf comme d’habitude). La gestion des virtual hosts se fait d’une manière un peu différentes par rapport aux sites présentés ci-dessus.

En effet, chaque virtual hosts correspond à un fichier (vous lui donner le nom qui va bien pour qu’on puisse facilement le reconnaitre), et les fichiers correspondant aux virtual hosts se trouvent à l’adresse : /etc/apache2/sites-available

Chaque fichier correspond à une DNS. Donc, j’ai préféré séparer chaque site par un fichier différent : site1, site2, perso, public, privé, etc…

Pour dire à apache de prendre en compte ces sites web, il faut placer un lien symbolique qui pointe vers un de ces fichier dans : /etc/apache2/sites-enabled :

Explication : ln -s crée un lien symbolique, du premier fichier, vers le deuxième fichier.

Voilà, à présent on redémarre apache pour que les changements soient pris en compte :

Rediriger les http://site.com vers un http://www.site.com

Pour cela j’ai séparé en plusieurs parties mes virtual hosts. On trouve dans le dossier site-enabled les liens vers les virtual hosts à proprement parler, et j’ai rajouté un ficher redirect qui contient les redirections.

Chaque virtual host”de base” contient les informations nécessaires à la sécurité, à la gestion des erreurs et aux fichiers de log de chaque site. Le fichier redirect contient lui toutes les informations de redirection (http://site.com -> http://www.site.com ou http://www.site.fr -> http://www.site.com).

Voilà le contenu du fichier pour un site où l’on veut rediriger les navigateur vers : www.site.com.

ServerName www.site.fr

ServerAlias *
#The previous line allow to avoid the two following
#ServerAlias site.fr
#ServerAlias site.com

Redirect permanent / http://www.site.com/

Faire du SEF et diriger les URL :

Voir l’article suivant : http://www.webmaster-hub.com/publication/Mod-rewrite-ou-la-reecriture-des.html

Posts similaires

• Configurer vos noms de domaines sous Apache (Virtual Hosts)
• Préliminaires
• Subdomains Wildcard Rewriting / Gestion de sous-domaines à la volée
• Sécuriser son serveur
• Prévenir les pirates grâce aux erreurs 404

http://www.impulseadventure.com/web/404-error-hackers.html

Posts similaires

• Sécuriser son serveur
• Configurer Apache
• Protection contre les spameur de liens

Points à retenir :

• Mettre des champs “hidden” qui contiennent un code de vérification (que l’on passe à la page de validation du commentaire). On peut par exemple associé un ensemble de mots aléatoires avec l’id de l’article commenté, on peut passer tout ça dans un script de crypto, pour empêcher lea détection facile, et le décodage se fera en page de validation. Cette procédure empêche, une fois la page de validation découverte par le logiciel de spam, les envois massifs grâce à une commande HTTP_Post
• Vérifier les champs que peut entrer le posteur : par exemple vérifier que l’adresse email entrée est bien une adresse email, ou que
• Analyser le contenu ‘important’, le commentaire généralement.

Posts similaires

• Sécuriser son serveur
• Configurer Apache
• Prévenir les pirates grâce aux erreurs 404