Lors de l'administration d'une instance SQL Server, il est fréquent de constater une accumulation massive de tentatives de connexion échouées, notamment sur le compte sa. Ces entrées saturent le journal d'erreurs (ERRORLOG), rendant l'analyse manuelle via l'interface graphique de SQL Server Management Studio (SSMS) fastidieuse, voire impossible en raison du volume de données.

Pour extraire efficacement des statistiques, comme les adresses IP sources de ces tentatives d'intrusion, deux méthodes programmatiques sont particulièrement efficaces : l'utilisation de la procédure stockée étendue xp_readerrorlog et l'exploitation de la trace par défaut (Default Trace).

1. Utilisation de xp_readerrorlog pour le filtrage

Avant d'interroger les logs, il est utile de connaître la liste des fichiers disponibles. La procédure xp_enumerrorlogs permet de lister les fichiers de journalisation avec leur date de création et leur taille.

-- Lister les journaux d'erreurs SQL Server
EXEC sys.xp_enumerrorlogs 1; 

-- Lister les journaux de l'Agent SQL Server
EXEC sys.xp_enumerrorlogs 2;

La procédure xp_readerrorlog accepte sept paramètres pour affiner la recherche :

1. ID du fichier : 0 pour le journal actuel, 1 pour ERRORLOG.1, etc.
2. Type de log : 1 pour SQL Server, 2 pour SQL Agent.
3. Filtre 1 : Chaîne de caractères recherchée.
4. Filtre 2 : Seconde chaîne pour affiner la recherche (ET logique).
5. Date de début : Bornage temporel inférieur.
6. Date de fin : Bornage temporel supérieur.
7. Tri : 'ASC' ou 'DESC' pour le classement par date.

Voici un exemple pour isoler les échecs de connexion du compte 'sa' provenant d'une IP spécifique sur une période donnée :

DECLARE @SearchString1 NVARCHAR(100) = N'Login failed for user ''sa''';
DECLARE @SearchString2 NVARCHAR(100) = N'192.168.1.5'; -- Adresse IP cible
DECLARE @StartDate DATETIME = '2023-10-01';
DECLARE @EndDate DATETIME = '2023-10-05';

EXEC sys.xp_readerrorlog 
    0, 
    1, 
    @SearchString1, 
    @SearchString2, 
    @StartDate, 
    @EndDate, 
    'DESC';

2. Filtrage via la Trace par Défaut (Default Trace)

La trace par défaut capture automatiquement certains événements de sécurité, dont les échecs de connexion (EventID 20). Cette méthode est utile si le fichier ERROROLG a été recyclé mais que les fichiers de trace sont encore disponibles.

Pour identifier les événements liés aux échecs de connexion dans le système, on peut interroger les vues de métadonnées :

SELECT 
    trace_event_id, 
    name AS EventName 
FROM sys.trace_events 
WHERE name LIKE '%Login Failed%';

Le script suivant permet d'extraire le chemin du fichier de trace actuel et d'y lire les échecs de conenxion filtrés par base de données et par catégorie de sécurité :

DECLARE @CurrentTracePath NVARCHAR(260);

-- Récupération du chemin du fichier de trace actif
SELECT @CurrentTracePath = [path] 
FROM sys.traces 
WHERE is_default = 1;

SELECT 
    T.StartTime,
    T.ServerName,
    T.LoginName,
    T.ApplicationName,
    T.TextData,
    E.name AS EventCategory
FROM fn_trace_gettable(@CurrentTracePath, DEFAULT) AS T
INNER JOIN sys.trace_events AS E 
    ON T.EventClass = E.trace_event_id
WHERE T.EventClass = 20 -- Audit Login Failed
  AND T.StartTime >= DATEADD(day, -7, GETDATE()) -- 7 derniers jours
ORDER BY T.StartTime DESC;

Considérations techniques

L'utilisation de ces outils permet de mieux comprendre les vecteurs d'attaque. Cependant, la simple lecture des logs ne suffit pas à sécuriser l'instance. Voici quelques points techniques à noter :

• Performance : xp_readerrorlog est plus rapide pour une lecture directe du fichier texte ERRORLOG, tandis que fn_trace_gettable permet des jointures SQL plus complexes.
• Visibilité des procédures : Les procédures comme xp_readerrorlog sont des procédures stockées étendues (DLL externes). Leur code source n'est pas consultable via sp_helptext car elles ne sont pas écrites en T-SQL.
• Stockage : Si les tentatives de connexion sont trop nombreuses, le fichier ERRORLOG peut croître rapidement. Il est conseillé de monitorer sa taille et d'utiliser sp_cycle_errorlog pour archiver régulièrement le fichier courant sans redémarrer le service.

Pour limiter l'impact de ces attaques, il est recommandé de modifier le port par défaut (1433), d'utiliser des politiques de pare-feu strictes et, si possible, de renommer ou désactiver les comptes à privilèges trop connus comme sa.