Please note the following corrective to my earlier posting on listener security from Paul Vallee. Thanks, Paul.

Setting up a vip on a firewall to allow sqlnet requests to pass through is ill-advised. The protocol was really designed for the corporate intranet, not the world at large. If you really want to do it, set it up to only accept requests from certain IP addresses, and definitely set it up to only allow encrypted sqlnet connections. Otherwise, all of your data will pass, in the clear, over every hop between you and every client. Including the SID and the username. With version 8, the password no longer goes in the clear (thank goodness). I've attached a sniff of sqlnet traffic for your reference, it's not something you want going over the internet in the clear IMHO.

I recently checked; there is no discovery mechanism to query a listener for SIDs that it answers for (this is good.) However, brute-force tools can easily be built to attempt connections to every possible combination of SIDs on a listener. Sqlnet has no facility for detecting, let alone stopping, that kind of brute force attack (you can write something custom to parse the log file and page out). Once the correct SID is identified, brute force password checkers can be used. Mind you, that's rarely needed, because very few people bother to get rid of the variety of default passwords that you can try (especially dbsnmp/dbsnmp - very effective). Even then, brute force checking can be used; I seem to remember that there is a setting for disabling accounts once a limit of wrong passwords are submitted; I don't know how comfortable you are with your accounts being disabled either.

There are better solutions to this problem:
1) Use ssh (www.openssh.com is a good, free, secure build) and port-forward through the encrypted, authenticated ssh tunnel to get to sqlnet.
2) Use a hardware ipsec solution such as Redcreek's ravlin 3200 (www.redcreek.com) to provide a secure, encrypted, persistent tunnel between all sites that need access.

Here is part of the sniff ...

    (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.237.1)(PORT=1521))
    (CONNECT_DATA=(SID=tpgl8)(CID=(PROGRAM=)(HOST=herc)(USER=vallee))))
    Linuxi386/Linux-2.0.34-8.1.0
    Linuxi386/Linux-2.0.34
    #C##
    vallee
    AUTH_TERMINAL
    pts/0
    AUTH_PROGRAM_NM
    sqlplus@herc (TNS V1-V3)
    AUTH_MACHINE
    herc
    AUTH_PID
    21156
    AUTH_SESSKEY
    FACC0ACA0129CEDC
    vallee
    AUTH_PASSWORD
    3E02A46DE09A00070
    AUTH_TERMINAL
    pts/0
    AUTH_PROGRAM_NM
    sqlplus@herc (TNS V1-V3)
    AUTH_MACHINE
    herc
    AUTH_PID
    21156
    AUTH_ACL
    4096
    AUTH_VERSION_STRING
    - Production
    AUTH_VERSION_SQL
    AUTH_XACTION_TRAITS
    AUTH_VERSION_NO
    134238208
    AUTH_VERSION_STATUS
    AUTH_CAPABILITY_TABLE
    AUTH_SESSION_ID
    AUTH_SERIAL_NUM
    12106
    AUTH_NLS_LXLAN
    AMERICAN
    AUTH_NLS_LXCTERRITORY
    AMERICA
    AUTH_NLS_LXCCURRENCY
    AUTH_NLS_LXCISOCURR
    AMERICA
    AUTH_NLS_LXCNUMERICS
    AUTH_NLS_LXCDATEFM
    DD-MON-YY
    AUTH_NLS_LXCDATELANG
    AMERICAN
    AUTH_NLS_LXCSORT
    BINARY
    AUTH_NLS_LXCCALENDAR
    GREGORIAN
    Oracle8 Release 8.0.5.0.0 - Production
    PL/SQL Release 8.0.5.0.0 - Production

I am not aware of any security concerns, but I am neither a security expert or a networking expert. Of the top of my head, I would suggest that you use a non-standard port number (not that it would take a real hacker long to figure it out) and run the listener as "nobody" or some such user instead of as "oracle". Of course your Oracle password security will be very important.

List,

If you have anything to add, please reply-to-all to this email.