Database Reference
In-Depth Information
Bypasses : DBA may find and/or change their own password and log on directly, thus
bypassing the hub. For instance, a DBA can dump a packet capture of their logon and then
find their own password hash and combine those to gain their current plaintext password,
as follows:
a.
alter system set events '10079 trace name context forever, level 2';--dump packet
capture http://books.google.co.uk/books?id=g1R96D2uO7kC&lpg=PA87&vq=10079
&pg=PA88#v=onepage&q=10079&f=false
Then use UTL_FILE or similar to read the OS trace file into the DB session
b.
select passwd from SYS.EXU8USRU; -- gain hash
Then use this link— http://soonerorlater.hu/index.khtml?article_id=512—to
decrypt the packet capture and hash back to the plaintext (note this is can be
achieved for 12c as well, though not published yet).
These forms of bypass are made easier by the commonly open topology of organizational internal networks.
Open topologies provide efficient and nimble enterprises but also make the terminal hub system difficult to enforce;
therefore, most implemented systems are simply password hubs, not terminal hubs.
External DBA Access
Typical external DBA access will be a single point of entry from the outsourcer to the client, therefore it is possible to
make admins go through the single terminal hub, as it is their only possible entry point. A good example of this type
of system is Pythian's Adminiscope, which is used globally for DBA consultants to log on to client systems through a
central hub with constant real-time monitoring. Adminiscope has keyboard logging, which avoids the Xterm hiding
issue, but currently does not have blocking capability such as that offered by Xceedium. Xceedium's command
blocking uses regex pattern matching but cannot currently include server variables like $ORACLE_HOME within the
regex, so we can see there is still an improvement process even with market leaders.
Pros and Cons of Terminal Hub
There are advantages to the terminal hub system in that the single point of logon makes correlated logging of user
activity at the various targets a lot easier. Xceedium's PAC appliance will send plain syslog to an aggregator like Splunk,
which is excellent, especially given Oracle's ability to send activity monitoring to syslog along with the Unix root
activity as well. This is great for PAC, as we can see the Unix users log on and then enter the DB.
Terminal hub systems also avoid the need to re-enter passwords. Most manufacturers allow initiation of SSH and
RDP sessions through a mouse click.
Most PAC systems rely on there being a secondary PAC admin account in case the target server password
becomes out of sync with the copy on the terminal hub server.
This dual control at the account level is very useful, though of course a user could attempt to reset that PAC
admin account's password, thus locking out the terminal server. PAC servers with the ability to block have the
advantage of attempting to mitigate this user behavior.
The generic problem with a terminal hub server is that it relies on users not trying to bypass it and go directly to
the target server.
 
Search WWH ::




Custom Search