Protéger votre système

utiliserez rarement le compte sa.
Par conséquent, vous pouvez donner
au mot de passe la longueur maximale.
Par exemple, SQL Server 2000 et 7.0
permettent un mot de passe de 128 caractères.
Si un mot de passe aussi long
vous rebute, vous pouvez utiliser les
premières phrases d’un livre ou d’un
manuel d’utilisation comme mot de
passe, afin que la personne qui a les
permissions sa ne soit pas obligée de
mémoriser le mot de passe. Si vous optez
pour un mot de passe plus court,
donnez-lui au moins 12 caractères
combinant des minuscules, des majuscules,
des chiffres et (si possible) des
caractères ALT spéciaux. Très peu d’outils
pratiquant le passage en force peuvent
casser des mots de passe qui
contiennent des caractères ALT
comme © et ®. (Pour obtenir la liste
des caractères ALT existants, employez
l’utilitaire Windows intégré Character
Map – charmap.exe).

Auditer les logins.
L’audit est la
pierre angulaire d’une administration
de sécurité pro-active. SQL Server permet
d’auditer les logins, ou de superviser
les connexions, en utilisant le journal
Application et SQL Server Profiler.
Le journal Application présente une lacune
importante : SQL Server journalise
tous les événements de login,
qu’ils réussissent ou non, comme
Category (4) et Event ID 17055.
Plusieurs autres types d’événements
utilisent aussi ce couple Category et
Event ID. Par conséquent, à  moins de
recourir à  un autre utilitaire capable
d’analyser plus en détail les logs de
l’Event Viewer pour trouver les descriptions
d’événements, vous devez
lire chaque entrée du log pour déceler
si quelqu’un est en train d’essayer de
deviner les logins SQL Server : quel
boulot ! De plus, le journal Application
n’enregistre pas l’adresse IP du client
qui se connecte. Dommage, car les
DBA pourraient utiliser cette information
pour débusquer les assaillants.
Profiler peut suivre les tentatives de login
infructueuses de manière plus granulaire,
en donnant à  l’administrateur
des renseignements intéressants :
échecs de login spécifiques, nom de
compte qu’un client a utilisé, et parfois
un nom d’hôte.

Détecter les intrus de manière
proactive.<
Pour compenser l’absence d’un bon mécanisme de login SQL
Server, les entreprises doivent songer à 
déployer un système de détection d’intrusion
tel que le IDS Snort opensource
(disponible à  http://www.
snort.org). Snort enregistre la date,
l’heure et l’information IP pour les
clients qui se connectent à  SQL Server.
Il est facile de voir si quelqu’un essaie
obstinément d’accéder à  votre système.
Si vous configurez SQL Server en
vue d’utiliser le Windows Application
Log pour les événements d’audit, songez
à  utiliser une fonction syslog
(comme celle que propose Kiwi
Enterprises à  http://www.kiwisyslog.
com) pour explorer les événements
d’audit SQL Server et découvrir les tentatives
d’accès à  répétition. Il existe
beaucoup d’outils syslog pour les serveurs
Windows.

Bloquer le SQL Advertisement
Service.
Comme les assaillants peuvent
facilement localiser et interroger
les serveurs SQL Server 2000 disponibles
en consultant le SQL Advertisement
Service, vous pouvez protéger
votre système en empêchant SQL
Server de répondre à  ces requêtes.
Ouvrez le SQL Server Network Utility
et cliquez sur TCP/IP, Properties. Puis
cochez la case Hide server et cliquez
sur OK. Pour que les changements
prennent effet, il faudra redémarrer
SQL Server. Quand vous changez le paramètre
Hide server, sachez que vous
changez le port TCP que SQL Server
utilise, du port 1433 au port 2433. Le
fait de changer le port d’écoute par défaut
de SQL Server complique un peu
les choses pour les applications ASP
qui se connectent à  SQL Server, parce
qu’il faut configurer ces applications
pour qu’elles utilisent le port non standard.
En raison de cette opération supplémentaire,
la plupart des administrateurs
ne procèdent pas à  ce
changement.

Limiter l’accès client.
Vous pouvez
aussi contribuer à  protéger votre
système en étudiant la manière dont
les clients interagissent avec SQL
Server et à  quel point vos SQL Server
sont ouverts aux requêtes de clients
bienvenus ou pas. Dans de nombreux
environnements, n’importe quel client
du réseau Internet peut accéder à  SQL
Server. En réduisant le nombre de
clients qui peuvent accéder directement
au système, on diminue le potentiel
d’attaques. Dans la mesure du
possible, placez les SQL Server sur un
réseau segmenté qui n’accorde l’accès
qu’aux serveurs ou aux clients qui doivent
accéder aux données de SQL
Server. Pour limiter l’accès direct, vous
pouvez aussi déployer une application
multiniveau dans laquelle le seul système
qui accède à  SQL Server est le
serveur qui exécute le code d’accès aux
données de l’application.

Neutralisez les défauts qui
vous rendent vulnérables.
Dès lors
qu’un pirate s’est introduit dans un
système SQL Server par le biais du
compte sa, tout le serveur est en péril.
Par défaut, SQL Server installe de nombreuses
procédures stockées pour effectuer
des tâches OS comme lire et
écrire dans le registre Windows. La
plus puissante d’entre elles est la procédure
stockée étendue xp_cmdshell,
qui permet à  SQL Server d’exécuter
des outils ligne de commande. Si SQL
Server est configuré pour démarrer
comme LocalSystem ou comme un
compte dans le groupe Windows
Administrators local, un assaillant peut
utiliser l’ensemble de commandes SQL
suivantes pour créer un compte utilisateur
Windows dans le groupe Windows
Administrators local :

xp_cmdshell _net user SQL Pen
/add

xp_cmdshell _net localgroup
Administrators SQLPen /add

Un assaillant peut aussi utiliser
xp_cmdshell pour invoquer l’utilitaire
client Trivial FTP (tftp.exe) dans le
répertoire system32. Les attaquants
peuvent se servir de cet utilitaire pour
installer des programmes malveillants
comme des chevaux de Troie, un logiciel
de contrôle à  distance, des keyloggers
ou des rootkits. Les rootkits sont
peut-être les logiciels malveillants les
plus pernicieux parce que beaucoup
d’entre eux peuvent se cacher aux
yeux des DBA pendant qu’ils donnent
aux assaillants libre accès à  l’OS.
Enlevez donc l’utilitaire tftp.exe sauf si
votre SQL Server a besoin de TFTPclient.
Vous pouvez éliminer l’accès à 
xp_cmdshell en ouvrant Query Analyzer
et en exécutant la commande suivante
:

DROP PROCEDURE xp_cmdshell

Cependant, cette commande ne
supprime pas la procédure stockée.
Pour la supprimer, le seul moyen
consiste à  désenregistrer le fichier
xplog70.dll. Mais comme des procédures
stockées légitimes dépendent
de ce fichier .dll, cette action n’est pas
réaliste. Et même si vous supprimez la
commande, un assaillant qui possède
l’accès sysadminlevel peut réactiver
xp_cmdshell. Si vous désactivez cette
procédure stockée, vous pouvez utiliser
Profiler pour détecter si quelqu’un
l’a réactivée – un signe certain d’intrusion.