Il y a d’abord la perpétuelle fuite en avant d’Oracle qui donne le sentiment que, quand on commence à être serein sur une version, la suivante débarque. Il y a également la mémoire qui joue des tours lorsqu’on ne pratique pas…

J’avais oublié jusqu’à l’existence du paramètre TCP.VALIDNODE_CHECKING et si je n’avais pas mes notes, je pourrais dire que je ne l’ai jamais su. Si un jour vous n’arrivez pas à démarrer vos listeners à cause d’une erreur très étrange ou si vous voulez restreindre tous les accès à votre base Oracle au serveurs X, Y ou Z, (re)paramétrez la restriction des accès réseaux à Oracle en utilisant les paramètres TCP.* du fichier sqlnet.ora

Généralité

La mise en oeuvre est très simple : il existe 3 paramètres TCP.VALIDNODE_CHECKING, TCP.INVITED_NODES et/ou TCP.EXCLUDED_NODES que vous pouvez configurer directement depuis netmgr comme vous le voyez ci-dessous :

Le détail de l’utilisation de ces paramètres est disponible dans la section suivante de la documentation : Configuring Database Access Control – 12 Configuring Profiles, Oracle® Database Net Services Administrator’s Guide – 11g Release 2 (11.2).

Par exemple, vous pouvez utiliser les paramètres ci-dessous dans le fichier sqlnet.ora pour ne permettre l’accès distant qu’aux serveurs red, black et blue :

TCP.VALIDNODE_CHECKING = YES
TCP.INVITED_NODES= (red, black, blue)

Note:
Pour que ça fonctionne, il faut que l’ensemble des alias des machines soient résolvables par le DNS, le fichier hosts quelque soit la méthode que vous utilisez. C’est le prix à payer pour éviter que quelqu’un, simplement en renommant sa machine, puisse accéder au serveur Oracle ; dans le cas contraire, vous rencontrerez l’erreur suivante lors de vos tentatives de démarrage :

lsnrctl start

LSNRCTL for Linux: Version 11.2.0.2.0 - Production

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=black)(PORT=1521)))

The command completed successfully

LSNRCTL for Linux: Version 11.2.0.2.0 - Production 
Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Starting /u01/app/oracle/product/11.2.0/db_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 11.2.0.2.0 - Production
System parameter file is /u01/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
Log messages written to /u01/app/oracle/diag/tnslsnr/black/listener/alert/log.xml
Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=black)(PORT=1521)))
TNS-12560: TNS:protocol adapter error
 TNS-00584: Valid node checking configuration error

Listener failed to start. See the error message(s) above...

Accès non autorisé

Si vous tentez désormais de vous connecter depuis votre ordinateur ou un serveur non autorisé, vous rencontrerez l’erreur pas très évidente à comprendre qui suivant :

$ sqlplus sys/change_on_install@pink as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Sat May 7 05:37:38 2011

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

ERROR:
ORA-12537: TNS:connection closed


Enter user-name: sys/change_on_install@pink as sysdba
ERROR:
ORA-12547: TNS:lost contact

La réponse est dans le fichier de log du listener :

Sat May 07 05:38:13 2011
07-MAY-2011 05:38:13 * 12546
TNS-12546: TNS:permission denied
 TNS-12560: TNS:protocol adapter error
  TNS-00516: Permission denied

S’assurer que la machine locale peut utiliser le listener

N’oubliez pas que vous aurez besoin de vous connecter au listener via le serveur lui-même ; si vous oubliez, toute sorte de problèmes risquent de vous arriver à commencer par un message d’erreur au démarrage… et malgré le démarrage :

$ lsnrctl start

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 07-MAY-2011 05:49:58

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Starting /u01/app/oracle/product/11.2.0/db_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 11.2.0.2.0 - Production
System parameter file is /u01/app/oracle/product/11.2.0/db_1/network/admin/listener.ora
Log messages written to /u01/app/oracle/diag/tnslsnr/black/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=black.easyteam.fr)(PORT=1521)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=black)(PORT=1521)))
TNS-12547: TNS:lost contact
 TNS-12560: TNS:protocol adapter error
  TNS-00517: Lost contact
   Linux Error: 104: Connection reset by peer

Vous aurez également des erreurs dès que vous voudrez utiliser lsnrctl comme ci-dessous :

$ lsnrctl stop

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 07-MAY-2011 05:52:02

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=black)(PORT=1521)))
TNS-12537: TNS:connection closed
 TNS-12560: TNS:protocol adapter error
  TNS-00507: Connection closed

$ lsnrctl status

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 07-MAY-2011 05:52:08

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=black)(PORT=1521)))
TNS-12537: TNS:connection closed
 TNS-12560: TNS:protocol adapter error
  TNS-00507: Connection closed

Conclusion

C’est la première fois que je vois ce type de configuration en production. Celle là n’est surement pas Unbreakable mais nécessite pour un accès autorisé à usurper une adresse réseau (IP spoofing) ou à prendre le contrôle du DNS avant de pouvoir accéder à une base Oracle. En outre, bien souvent, ce sont les firewalls qui effectuent ce type de contrôle, pour de bonnes raisons…

Cela dit, si on prend comme préalable que mettre en oeuvre de la sécurité sur les bases de données, consiste à rendre le plus compliqué possible la vie des pirates potentiels, ça peut sans aucun doute faire partie de vos outils.

N’oubliez pas de le dire à vos collègues qui eux gèrent les accès, sinon vous allez les faire tourner au minimum quelques minutes…