Archives de catégorie : Sécurisation

La catégorie Sécurisation contient différents principes permettant de sécuriser un objet informatique, de façon théorique (par rapport à un concept) ou pratique (en réponse à une actualité).

SQL Express (Sauvegarde)

SQL Express

Tout d’abord il faut un script SQL du genre :

BACKUP DATABASE jean TO DISK=N'G:SQLMaBase.bak'GO

On peut faire un peu plus complexe, avec cet exemple généré par SQL Exress :

BACKUP DATABASE [base] TO  DISK = N'C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBackupbase.bak' WITH NOFORMAT, NOINIT,  NAME = N'base-Complète Base de données Sauvegarde', SKIP, NOREWIND, NOUNLOAD,  STATS = 10GO

Ensuite il faut automatiser ce script. Pour lancer un script SQL sous Windows, il faut utilisre osql :

sqlcmd -S nom_instance -E -i requete.sql -o fichier_sortie.txt

Par exemple :

@echo off 
: copie
sqlcmd -S .SQLEXPRESS -E -i svg_base.sql -o svg.log
rename "C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBackupbase.bak" svg_%date:~6,4%%date:~3,2%%date:~0,2%.bak
: supp
if not exist "C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBackupbase.bak" goto fin
del "C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLBackupbase.bak"
: fin

Plus d’infos :

  • http://fadace.developpez.com/mssql/sauve/
  • http://www.asp-php.net/tutorial/sql-server/sauvegarder-bases-de-donnees-sql-express.php?page=1

Plesk (Sauvegarde)

Backup/Restore sur Plesk.
Les utilitaires permettant les sauvegardes/restauration sont dans /usr/local/psa/bin/pleskbackup.

Sauvegarde

C’est simple, une seule commande pour tout sauvegarder :

./pleskbackup all  

Restauration

Je n’indique ici que la restauration complète. Il est possible de ne restaurer qu’une partie de la machine (domaine, client, etc). Il y a deux étapes, une première où est créé un fichier indiquant ce qu’il y a à restaurer (map file name, qui est donc un nouveau fichier créé par pleskrestore), puis la restauration elle-même.

./pleskrestore --create-map   -map 

./pleskrestore --restore  -map  -level all

Pare-feu

Un pare-feu (je sais : pare-feu pour les petits français) est une des bonnes pratiques de sécurité que je recommande. Bon sang de bonsoir, c’est même l’outil de base le plus indispensable et surtout (alors que ça ne semble pas évident au premier abord) le plus efficace pour lutter contre les attaques sur votre serveur web.
Un firewall (en français : pare-feu) est un dispositif (qui peut être logiciel ou matériel) permettant de filtrer ce qui peut passer sur un réseau ou sur une machine.

Pare-feu réseau

Quel firewall utiliser ?

Pour un ordinateur personnel ou un petit serveur web, il s’agit souvent d’un programme qui va se loger dans un recoin du système et qui filtre selon des règles qu’on peut paramétrer. Il en existe plein, mais dans le cadre d’un petit serveur web de type Linux, je recommande shorewall qui se base sur iptables

L’outil iptables est considéré comme fiable et efficace. Pourquoi rajouter une couche avec Shorewall ? Parce qu’iptables est assez pénible à paramétrer, et que shorewall le fait pour vous à partir de règles un peu plus simples.

L’avantage de Shorewall est qu’il permet relativement simplement de paramétrer un outil très puissant et très efficace, IPTables. Pour simplifier, IPTables est la partie accessible de netfilter qui est le mécanisme de filtrage du noyau Linux.

Comme un utilisateur, même root, n’a pas accès directement au noyau, on passe par IPTables pour configurer les règles de filtrage.

Comme ces règles de filtrage sont malgré tout un tantinet complexes à écrire, à vérifier, et surtout à rendre cohérentes, des outils proposent de le faire pour vous. Shorewall en est un parmi d’autres, il a l’avantage de simplifier le travail et d’être en mode texte.

Pare-feu applicatif

mod security est un exemple de pare-feu applicatif.

SSH

Le plus important : oublier telnet

Ce principe est facile à comprendre et à retenir : il ne faut jamais plus utiliser telnet, ni rlogin ni rsh !

Si ces utilitaires ont eu leur heure de gloire, il faut totalement les proscrire de tout serveur (et de toute machine) reliée à internet. En effet, tous les flux circulent en clair, y compris le couple login/mot de passe. Ça n’est pas très grave pour un réseau purement interne, mais dès qu’une machine est visible de l’extérieur, il faut supprimer ces commandes (si c’est possible) et les interdire via votre pare-feu. Pas de question à se poser !

SSH = Secure Shell

Comme son nom l’indique, SSH est un outil qui permet d’avoir accès à un shell de manière sécurisée sur une machine distante. Enfin, sécurisée, c’est vrai mais faut faire attention.

SSH désigne à la fois l’outil qui permet de se connecter mais aussi la norme utilisée pour réaliser cette communication.

Chiffrement

SSH est chiffré : tout ce que vous ferez une fois connecté n’apparaîtra pas en clair. Si rien n’est impossible, un pirate aura cependant beaucoup de difficulté à déchiffrer ce flux, et tout ce qui complique la vie d’un pirate est bon à prendre.

Sécurisation de SSH

Protocole V1

Comme tout n’est pas parfait du premier coup, il faut savoir qu’il existe 2 versions majeures de protocole SSH : la v1 et la v2. Logique, mais hélas la v1 souffre de quelques problèmes qui la rendent fragile et sensible à certaines attaques.
Conséquence : N’autorisez que la version 2 du protocole.

Comment se limiter à la v2 (sur le serveur)

C’est tout simplement un paramètre de SSH. Pour cela, il suffit d’éditer /etc/ssh/sshd_config, et décommenter la ligne Protocol en ne laissant que 2.

La fichier doit donc contenir quelque chose qui ressemble à :

... 
Compression yes
Protocol 2
RSAAuthentication yes
...

Attention au piège !

Il y a un piège ? Oui, dans certaines conditions : il faut faire attention côté client. Si vous êtes sous Windows, vous utilisez certainement PuTTY pour vos connexions SSH. Or si vous ne spécifiez pas de rester uniquement en version 2 de SSH, le serveur pourrait demander à passer en version 1, vulnérable, en indiquant qu’il ne connaît que celle là. Et PuTTY acceptera, si vous ne spécifiez pas 2 only.

Or dans le cas d’une attaque man-in-the-middle, le fraudeur aura tout intérêt à tenter de passer par la version la moins sécurisée de SSH ! Ce genre de crypto downgrade attack est également utilisé dans le cas de Freak.

Interdire l’accès à root ?

Il existe plusieurs façons de le faire. Mais d’abord, pourquoi le ferait-on ? Et bien parce que si vous interdisez l’accès à root, vous serez obligé de faire du su ou du sudo pour lancer des commandes d’administration. Donc un 2e mot de passe à saisir, donc à deviner. Donc double difficulté pour l’attaquant.

Ca n’est pas un impératif absolu, si vous avez un mot de passe suffisamment fort. Cela dit, on n’est jamais trop prudent.

Changer de port

Les ports (tcp ou udp) les plus utilisés et les plus courants sont répertoriés1 et donc, pour des questions de commodité évidente, sont connus de tous. On parle même de well-known ports pour les les ports allant de 0 à 1023 (ports systèmes). Il est ainsi facile de savoir quel port utiliser pour un service donné, et cela empêche également que deux services se marchent sur les pieds en utilisant le même.
Il ne s’agit toutefois que d’une recommandation : libre à vous d’utiliser un port habituellement attribué à un autre service ou de modifier le numéro de port habituel d’un service.

Cela peut être une bonne pratique sur des services attaqués par force brute, comme SSH : le port 22 (celui de SSH habituellement) est probablement le premier et le plus attaqué. Donc autant ne pas faciliter la tâche aux attaquants est positionner le service SSH (sshd sur Linux) sur un autre port, afin de rendre inopérante les attaques automatiques.

En général ça se passe dans le fichier /etc/ssh/sshd_config, dans les toutes premières lignes :

# The strategy used for options in the default sshd_config shipped with 
# OpenSSH is to specify options with their default value where 
# possible, but leave them commented.  Uncommented options change a 
# default value. 
Port 4567

Limiter l’accès à SSH

Vous pouvez aussi limiter l’accès à SSH via le pare-feu, en n’autorisant que certaines adresses IP. C’est plus sûr, mais ça n’est pas toujours pratique, si vous avez besoin d’accéder à votre machine depuis un endroit inhabituel ou si l’adresse IP de votre connexion internet n’est pas fixe (ce qui arrive avec les connexions par fibre).

Autres articles

Message d’accueil

Lorsqu’un utilisateur se connecte à un système dont vous avez la responsabilité, il est de bon ton de le saluer, mais il est également utile de lui rappeler qu’il n’est pas dans un domaine public et qu’il doit avoir été autorisé à venir. Pour cela, un petit rappel dans le message d’accueil peut être bienvenu. S’il n’empêchera pas un utilisateur mal intentionné de poursuivre, il évitera les maintiens accidentels de connexion, et il aura aussi son utilité en cas de poursuites judiciaires, car le pirate ne pourra pas dire qu’il n’était pas prévenu.

Pour cela, il suffit d’éditer un fichier /etc/motd (si vous avez la main sur celui-ci) et y mettre son commentaire, de manière suffisamment claire pour qu’il n’y ait pas d’ambiguïté… En voici un (ancien) exemple que j’ai utilisé :

##    ##  ######     ###         ######   #######  ##     ##
### ## ## ## ## ## ## ## ## ## ### ###
#### ## ## ## ## ## ## ## #### ####
## ## ## ###### ## ## ## ## ## ## ### ##
## #### ## ######### ## ## ## ## ##
## ### ## ## ## ## ### ## ## ## ## ## ##
## ## ###### ## ## ### ###### ####### ## ##


This computer system is for authorized users only. All activity
is logged and regulary checked by systems personal. Individuals
using this system without authority or in excess of their authority
are subject to having all their services revoked. Any illegal
services run by user or attempts to take down this server or its
services will be reported to local law enforcement, and said user
will be punished to the full extent of the law. Anyone using this
system consents to these terms.

L’usage de ce serveur est réservé aux personnes autorisées. Toute
activité est journalisée et régulièrement vérifiée par le système.
Toute personne utilisant ce serveur sans autorisation ou en outre-
passant ses droits risque la fermeture des services concernés.
Toute activité illégale ou tentative de corruption ou d’intrusion
du serveur sera passible de poursuites dans la juridiction compétente.
Tout utilisateur de ce système informatique accepte ces
conditions d’utilisation.

=================================================================================
Contact : acebox_com@yahoo.fr ou admin@ace-box.com
=================================================================================

Serveur : acebox
IP : 88.191.32.128
Add MAC : 00:40:63:e5:c3:de
OS : Fedora Core release 4 (Stentz) installe le 2006-07-04 12:02:18

Pour sécuriser encore plus la connexion, vous pouvez également vous envoyer un e-mail d’alerte.

Plesk (Maintenance)

Sauvegarde et restauration

Sauvegarde

Je conseille de sauvegarder l’ensemble des sites et des éléments qui sont gérés par Plesk. Pour cela, la procédure est très simple puisqu’une seule ligne de commande suffit :

./pleskbackup all <backup file name>

Cet éxecutable se trouve dans le répertoire principal de Plesk, généralement /usr/local/psa/bin/pleskbackup.

Restauration

C’est un peu plus compliqué. Il faut d’abord créer un fichier « map » qui contiendra la liste des éléments à restaurer. Attention, car c’est indispensable et souvent ça prend du temps.

./pleskrestore --create-map  <backup file name> -map <map file name> 

Ensuite, on demande de restaurer le fichier de backup, en utilisant ce qu’il y a dans ce fichier « map ». On peut modifier à la main ce fichier ; on peut également changer le niveau de restauration (via le paramètre -level, qui peut prendre plusieurs valeurs comme domain, client, etc).

./pleskrestore --restore  <backup file name> -map <map file name> -level all

Vérifier le système de quota

Pour pouvoir mettre en œuvre le système de gestion des quotas de disque par utilisateur, il peut être nécessaire de modifier les paramètres du système de fichiers.

  1. Activez les quotas par système de fichiers en modifiant /etc/fstab qui doit contenir LABEL=/var /var ext3 defaults,usrquota,grpquota 1 2 pour le file system sur lequel sera stocké les fichiers des utilisateurs (clients) de Plesk (qui est par défaut /var).
  2. Remontez le(s) système(s) de fichiers (par un reboot)

Tout ceci se fait normalement automatiquement lors de l’installation de Plesk, mais cela ne coûte rien de vérifier.

Test d’intrusion

Déroulement du test

Découverte du périmètre

Retrouver l’ensemble des adresses IP exposées, des noms de domaines, etc.

Reconnaissance

Inventaire des matériels utilisés (routeurs, serveurs, etc) ainsi que des applicatifs (OS, serveurs web, serveurs applicatifs) et surtout leur versions. Recherche des failles et vulnérabilités potentielles.

Attaque

Exploitations des failles découvertes. Elévation de privilège ou parcours des différentes machines

Progession

En fonction des premiers résultats de l’attaque, approfondissement du périmètre, de la collecte, de manière itérative (souvent).

Analyse et retour

Analyse technique

Pour lister les failles et indiquer comment les corriger

Retour vers le management

Pour mesurer et mettre en perspective les risques encourus, pour prendre les mesures organisationnelles nécessaires.

Liens et références