Discussion :

[nicolas23]

Bonjour,

Un utilisateur cherche a se connecter avec un compte Oracle sur ma base de Prod. Il cherche à utiliser un compte "USER1" auquel est rattaché une focntion Secure qui le bloque apres 3 tentatives.
Depuis 1 semaine ce compte se bloque plusieurs fois par jour mais impossible de mettre la main sur celui qui cherche a faire ca.
Comment puis-je detecter le Hostname et osname du responsable

Merci d'avance

[13thFloor]

Crée un trigger sur logon sur compte USER1 et fais un select sur v$session qui va alimenter une table que tu auras préalablement créée. Ca devrait aider.
Si c'est fait plusieurs fois par jour, c'est sans doute un batch ou un agent.

[scheu]

J'avais déjà rencontré un problème similaire et apparemment le trigger "after log on" ne marchera pas pour son problème car il ne logue que les connexions réussies (et non pas les tentatives ratées à cause d'un mauvais password par exemple)

N'existerait-il pas plutôt un fichier de log qui archive les tentatives de connexions qui ont échoué ?

[scheu]

Une solution existe pour ton problème : activer l'audit (paramètre audit_trail qui nécessite un redémarrage de l'instance pour être pris en compte)
Ensuite lance l'audit pour tracer les tentatives de connexions frauduleuses :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AUDIT CONNECT WHENEVER NOT SUCCESSFULL

Tu verras les infos des connexions échouées (avec notamment l'IP du client)dans la table SYS.AUD$ si le paramètre audit_trail vaut TRUE ou DB, sinon s'il vaut OS, c'est stocké dans un fichier disque dans le répertoire défini par le paramètre audit_file_dest

[pifor]

On peut aussi éventuellement se servir du log du listener qui enregistre par défaut toutes les demandes de connexion de la façon suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<DD-MMM-YYYY> <HH:MI:SS> * 
(CONNECT_DATA=(SID=<ORACLE_SID>)(CID=(PROGRAM=<executable client>)
(HOST=<machine client>)(USER=<compte OS sur la machine client))) * 
(ADDRESS=(PROTOCOL=tcp)(HOST=<IP machine client>)(PORT=<nnnn>)) * establish * XXX * 0

L'inconvénient c'est qu'il ne fait pas la différence entre une connexion qui est refusée par l'instance et une connexion qui est acceptée par l'instance car le listener n'enregistre que la demande de connexion par le réseau avant de passer la main à l'instance.

[LeoAnderson]

ou encore faire trigger de niveau database mais sur l'évènement SERVERERROR et trapper l'erreur "invalid username/password" !

(l'audit est le mieux mais si le paramètre audit_trail n'a pas été positionné au démarrage de l'instance, son utilisation impliquerait un stop/start pas toujours possible)