Version imprimable
Salut,
je suis en stage architecture reseau, je ne connais pas grand chose en programmation. Ma question est la suivante:
Comment connaître le nombre de connection sur un serveur oracle.
En fait, je dois écrire un scripte shell qui me permettrai de remonter ces informations sous forme de graphique en sur se servant de cacti:
cacti est un logiciel de supervion.
merci.
Ca sert à rien de faire une requête Oracle, cherche juste avec un 'netstat -a' tous les éléments du type :
En gros, sur une de mes machines :Code:<mon ip>.<port du listener> <autre ip>.<un port> x x x x ESTABLISHED
Avec un 'wc' :Code:
2
3
Code:
2
La partie SQL de la réponse est en partie dans la FAQ.
S'il n'y a que des connexions distantes, oui. Mais il peut y avoir des connexions locales qui n'utilisent pas Oracle Net mais le protocole IPC.Citation:
Envoyé par philcero
Il parle de surveillance, donc j'en déduis qu'il s'agit de connexions clientes sur un réseau classique...Code:S'il n'y a que des connexions distantes, oui. Mais il peut y avoir des connexions locales qui n'utilisent pas Oracle Net mais le protocole IPC.
pas forcément, on peut avoir un besoin de superviser le nbre de personnes connectés pour diverses raisons (sécurité, licensing, etc.)
et pourquoi pas regarder dans v$sessions ? :koi:
Pour la simple et unique raison qu'un script SHELL automatisé ne doit JAMAIS se connecter à une base pour faire des requêtes. Si il le fait cela veut dire qu'il y a possibilité pour un flux réseau (Qui arrive sur ce compte) de faire un JUMP vers une base de données et roule ma poule, adieu la babase si c'est un pirate.Citation:
et pourquoi pas regarder dans v$sessions ?
alors regarder le nombre de process Oracle DEDICATED s'il a la chance de ne pas être en MTS ;)
Pour compléter ma réponse c'est l'une des raisons qui ont poussés les éditeurs à créer des flux protégés pour piloter et monitorer leurs bases à distance (OEMAGENT).
Il faut bien garder à l'esprit, quand on gère une base, que celle-ci doit être hermétique à tout flux extérieur qui ne passerait pas par son LISTENER (En environnement critique, on crypte également son flux).
Salut à tous,
Si on regarde au niveau process, on peut compter le nombre de sessions dédiées si on compte les process oracleSID
Cela qui sont par IPC ont "(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))"
et celles par oracle*net :
"(LOCAL=NO)"
Rem : Sur ma machine AIX, à cause de la redirection de port si on fait le compte par netstat, il faudra diviser le nombre par 2.
Halifa :Si tu décides de passer quand même par un user oracle , n'oublies pas de créer un compte avec des droits restreints.
@+
Je dirais même plus créé un compte qui ne puise pas avoir de login (shell=/bin/false).
Au moins ce sera un début de sécurisation...
pardon...
Citation:
Envoyé par orafrance
Moi je pense qu'ilest possible d'utiliser v$session (et non v$sessions) dans unscript quiest soumis au serveur oracle comme une tache...Citation:
Envoyé par philcero
Le problème n'est pas technique, il est philosophique. Si tu as la responsabilité d'une base, tu as également la responsabilité de qui y entre. Donc il faut limiter les entrées au compte maître de la base qui lui doit être blindé comme personne et ensuite tous les autres accès ne doivent être que via SQL*Net.
Pourquoi ?
Si tu fais un compte dans un coin qui a la possibilité de lancer un script sur ta base c'est que tu réponds au moins à une des deux possibilités suivantes :
Dans les deux cas tu as tout faux car même si ta solution semble propre, tu offres là une voir royale pour une attaque...
- Tu as un compte et un mot de passe en clair dans un fichier texte visible de ce compte, et bien souvent de plein d'autres car les gens lancent du SQL*Plus avec compte et mot de passe sur la ligne de commande (ps -aef et zou je voie tout).
- Ton compte fait partie du groupe assimilé DBA de ton OS et peut se connecter à ta base quand il veut.
Alors ensuite on peut dire "Oui, mais statistiquement, j'ai une chance sur un milliard...". Grosse erreur, non pas sur le chiffre, on te donne la responsabilité d'une base c'est équivalent à te donner les clefs du coffre dans une banque ni plus ni moins. Si je laisse les clefs sur le comptoir est-ce normal ?
J'ai un peu du mal à vous suivre:
Citation:
Envoyé par philcero
Cela veut dire que toute connexion Oracle Net peut être piratée dès qu'on utilise toujours le même identifiant/mot de passe sauf si Oracle Net ou TCP/IP encrypte la communication ? Il me semble que le listener n'est utilisé que pour l'établissement de la connexion TCP/IP; après la client est connecté directement à son processus dédié (ou partagé le cas échéant). D'un autre côté, il me semble aussi que le listener est obligatoire dès qu'il y a connexion par Oracle Net.Citation:
Il faut bien garder à l'esprit, quand on gère une base, que celle-ci doit être hermétique à tout flux extérieur qui ne passerait pas par son LISTENER (En environnement critique, on crypte également son flux).
Je n'arrive pas à comprendre ce qui différencie le problème sécurité que vous évoquez dans ce cas spécifique avec le problème général de sécurité Oracle Net.
Si vous avez des liens sur des documents plus détaillés, ils sont les bienvenus.
ou tu as un compte identifié par l'OS et a donc le droit de se connecter comme l'utilisateur OS a le droit de faire un PS :mouarf:Citation:
Envoyé par philcero
Si la sécurité est bien géré (pas d'user SYSDBA et pas utiliser SYSTEM) alors je ne vois pas se qui interdit de lancer des requêtes sur la base même pour du monitoring :? Sinon, tu t'interdis tous les outils de monitoring du marché qui se connecte à la base :? C'est à dire tous sauf data grid control :aie:
J'ai moi aussi dans ma boîte des batches lancés via crontab unix, soit par un compte du groupe DBA (sans mot de passe), soit par compte unix identifié par l'OS sur la base
Personnellement, je ne vois pas non plus où est le mal niveau sécurité ...
Il existe une troisième possibilité ; le wallet.
Le wallet contient, pour un TNS donné, un password. Ce password est donc utilisable sans être connu de l'utilisateur qui établit la connexion.
Ainsi, on profite des deux avantages :
- limitation des privilèges : pas besoin d'avoir un privilège DBA ou SYSDBA
- on ne se limite pas à une authentification OS