Database Reference
In-Depth Information
The signature for a remote brute-force attack on SYS is as follows (multiple 1017 events in quick succession
on the SYS account). You can see such an attack in the following log output, with many events occurring in the
same second:
[root@localhost ~]# tail -f /var/log/boot.log
Mar 9 00:26:40 localhost Oracle Audit[15819]: LENGTH : '162' ACTION :[7] 'CONNECT' DATABASE
USER:[3] 'sys' PRIVILEGE :[4] 'NONE' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/1' STATUS:[4]
'1017' DBID:[10] '1229390655'
Mar 9 00:26:40 localhost Oracle Audit[15823]: LENGTH : '162' ACTION :[7] 'CONNECT' DATABASE
USER:[3] 'sys' PRIVILEGE :[4] 'NONE' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/1' STATUS:[4]
'1017' DBID:[10] '1229390655'
Mar 9 00:26:40 localhost Oracle Audit[15823]: LENGTH : '162' ACTION :[7] 'CONNECT' DATABASE
USER:[3] 'sys' PRIVILEGE :[4] 'NONE' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/1' STATUS:[4]
'1017' DBID:[10] '1229390655'
Mar 9 00:26:40 localhost Oracle Audit[15827]: LENGTH : '162' ACTION :[7] 'CONNECT' DATABASE
USER:[3] 'sys' PRIVILEGE :[4] 'NONE' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/1' STATUS:[4]
'1017' DBID:[10] '1229390655'
It is important to be alert to and act on any audit-trail entry such as this. If an attacker does break into the SYS
account, they can then silently turn off auditing using the oradebug tool. Then they can decrypt the link passwords to
enter other databases. Hence, you really do want to nip in the bud any attack on the SYS login.
The pattern of multiple 1017 events in succession may not necessarily indicate an attack. Here are the
possibilities:
Someone is doing some security testing.
You have a batch script that has gone wild.
A DBA has forgotten the SYS password and is trying to log in using that account.
You are under attack.
Chapter 16 will deal with forensic techniques to ascertain which of these is the case. It is, of course, that last case
that is most worrisome. The security of the database estate (large collection of databases within an organization)
is resting on every DBA remembering to set a secure SYS password on every database and then to change them
regularly. DBAs are busy, and this need to change passwords will be forgotten—it is human nature. A DBA might not
even be using the remote SYS password, as that DBA may be accessing through *nix and is therefore unaware that the
remote password is just the letter “a” for example.
One piece of advice given publicly by some Oracle experts has been to avoid using SYS, but a lot of DBA tasks
need SYS. For example:
Schema changes to SYS, e.g., new password function
Avoiding public synonyms for executing packages
DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE
(see http : // kr.forums.oracle.com/forums/thread.jspa?threadID=540770 )
Use of
DBMS_CRYPTO needs SYS to execute
SYS.USER_HISTORY$ needs SYS to select
GRANT SYSDBA needs SYS to grant
Dataguard and Grid need both need SYS and root
Purging DBA recycle bin needs SYS to do
 
Search WWH ::




Custom Search