Rule:  --Sid: 1679-- Summary: This event is generated when a command is issued to an Oracle database server that may result in a serious compromise of the data stored on that system.-- Impact: Serious. An attacker may have gained superuser access to the system.--Detailed Information:This event is generated when an attacker issues a special command to an Oracle database that may result in a serious compromise of all data stored on that system.Such commands may be used to gain access to a system with the privileges of an administrator, delete data, add data, add users, delete users, return sensitive information or gain intelligence on the server software for further system compromise. This connection can either be a legitimate telnet connection or the result of spawning a remote shell as a consequence of a successful network exploit. Oracle servers running on a Windows platform may listen on any arbitraryport. Change the $ORACLE_PORTS variable in snort.conf to "any" if thisis applicable to the protected network.--Attack Scenarios: Simple. These are Oracle database commands.-- Ease of Attack: Simple.-- False Positives: This event may be generated by a database administrator logging in and issuing database commands from a location outside the protected network.--False Negatives:Configure your ORACLE_PORTS variable correctly for the environment you are in. In many situations ORACLE negotiates a communication port. This means that 1521 and 1526 are not used for communication during the entire transaction. A new port is negotiated after the initial connect message, all communication after that uses this other port. If you are in an environment such as this, you should set ORACLE_PORTS to "any" in snort.conf.  Otherwise, there are no known false negatives.-- Corrective Action: Use a firewall to disallow direct access to the Oracle database from sources external to the protected network.Ensure that this event was not generated by a legitimate session then investigate the server for signs of compromiseLook for other events generated by the same IP addresses.--Contributors: Original Rule Writer UnknownSourcefire Research TeamNigel Houghton <nigel.houghton@sourcefire.com>-- Additional References:--