= OFF to your listener.ora file.
Be aware that securing the listener in 11g deviates from this advice! In 11g, the default listener can only be administered locally. Furthermore, the listener utilizes the local OS authentication to determine which user started the listener, and only allows that user (and super users) to administer the listener. However, setting a password for the 11g listener will ALLOW remote administration! For the Oracle 11g listener, you will actually reduce the database's network security posture by enabling a listener password. It is counter-intuitive, but this is a huge security improvement for the listener. There are many actions you can take to further harden your listener from attack, but these can be quickly and easily implemented on most systems with no adverse effects.
Second, ensure your OS permissions are set properly. Access should be appropriately, and strictly controlled to all the Oracle binaries, system files, archived redo logs and backups. Archived redo logs can easily be mined to divulge data that has been entered into your database using the Oracle LOGMNR utility, and cold backups or raw datafiles can be effectively read using a simple hex editor.
Lastly, and probably the most unobvious -- control physical access to your database server! If an attacker can gain physical access to your system, they can get to your data. Even Full Disk Encryption (FDE) can be defeated if someone gains access to the hardware. Depending on the size of your business, this may be as simple as changing out a few doorknobs. For a large organization, this is not a quick and easy endeavor – it requires considerable planning and implementation. However, it requires very little Oracle expertise to significantly mitigate this critical risk.
