Re: Oracle OS level security
Nothing can prevent an SA from wreaking havoc. The best we can do is narrow the number of people who can and DBAs can be removed from that group, if desired... - Original Message - From: Jared Still [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Tim Gorman [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 5:45 PM Subject: Re: Oracle OS level security On Thursday 28 November 2002 12:03, Tim Gorman wrote: My $0.02... Oracle9i provides the AUDIT_SYS_OPERATIONS parameter, which will audit only to the OS audit trail. Thus, anything that SYSDBA does can be audited. The reason for the OS audit-trail only? Because SYSDBA can always erase a DB audit trail (even if the act of erasure is still audited). All SYSDBA however, can be prevented from reading or modifying the OS audit trail. This doesn't prevent a SA with DBA knowledge from wreaking havoc. I believe the only secure configuration for an Oracle database has the software owner (typically named oracle) and OS_SYSDBA and OS_SYSOPER groups under control of SysAdmins only. Those with SYSDBA do not need access to that OS account or those OS groups. SA's still a problem. The real problem is DBAs ourselves, who seem to treasure day-to-day usage of the Oracle software owner and membership of private accounts in the OS_SYSDBA and OS_SYSOPER groups... Personally, I log into the 'oracle' or 'root' account only as needed. Except on NT of course, where I need admin access to do my job properly. Maybe in a larger shop that wouldn't be necessary, but in a small shop it's very difficult to have an SA at your side when needed for admin level access. Jared - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 4:53 AM Jared, Very interested in the thread you hypothetical raised. I'm working in a pharamceutical site which is subject to FDA and other regualtions part of which is the whole buisness of audit trails. We has a Standard Operating Procedure which states that whilst DBA's have a access to data they will not change it. A recognition of the DBA's capabilties but stating on paper company trust they will behave themselves. On a more practical point with NT/W2K Oracle audit trail can be set to write audit trail records to the event logs. DBA's can be prevented from changing the event logs. So now it would take at least 2 people to instigate a fraud. Hey this might foster even better relations between DBA's and SA's ;) Just my 2 cent worth :) - Seán O' Neill Organon (Ireland) Ltd. [subscribed: digest mode] From: [EMAIL PROTECTED] Date: Tue, 26 Nov 2002 14:40:24 -0800 Subject: Oracle OS level security Dear list, Let me toss a hypothetical situation at you. etc. etc. This message, including attached files, may contain confidential information and is intended only for the use by the individual and/or the entity to which it is addressed. Any unauthorized use, dissemination of, or copying of the information contained herein is not allowed and may lead to irreparable harm and damage for which you may be held liable. If you receive this message in error or if it is intended for someone else please notify the sender by returning this e-mail immediately and delete the message. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: O'Neill, Sean INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Tim Gorman INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You
RE: Oracle OS level security
Jared, Very interested in the thread you hypothetical raised. I'm working in a pharamceutical site which is subject to FDA and other regualtions part of which is the whole buisness of audit trails. We has a Standard Operating Procedure which states that whilst DBA's have a access to data they will not change it. A recognition of the DBA's capabilties but stating on paper company trust they will behave themselves. On a more practical point with NT/W2K Oracle audit trail can be set to write audit trail records to the event logs. DBA's can be prevented from changing the event logs. So now it would take at least 2 people to instigate a fraud. Hey this might foster even better relations between DBA's and SA's ;) Just my 2 cent worth :) - Seán O' Neill Organon (Ireland) Ltd. [subscribed: digest mode] From: [EMAIL PROTECTED] Date: Tue, 26 Nov 2002 14:40:24 -0800 Subject: Oracle OS level security Dear list, Let me toss a hypothetical situation at you. etc. etc. This message, including attached files, may contain confidential information and is intended only for the use by the individual and/or the entity to which it is addressed. Any unauthorized use, dissemination of, or copying of the information contained herein is not allowed and may lead to irreparable harm and damage for which you may be held liable. If you receive this message in error or if it is intended for someone else please notify the sender by returning this e-mail immediately and delete the message. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: O'Neill, Sean INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Oracle OS level security
My $0.02... Oracle9i provides the AUDIT_SYS_OPERATIONS parameter, which will audit only to the OS audit trail. Thus, anything that SYSDBA does can be audited. The reason for the OS audit-trail only? Because SYSDBA can always erase a DB audit trail (even if the act of erasure is still audited). All SYSDBA however, can be prevented from reading or modifying the OS audit trail. I believe the only secure configuration for an Oracle database has the software owner (typically named oracle) and OS_SYSDBA and OS_SYSOPER groups under control of SysAdmins only. Those with SYSDBA do not need access to that OS account or those OS groups. The only occasion that access is needed is during software installation/maintenance and Oracle is doing a reasonably good job with OUI to make even this a task which can be performed by SysAdmins assisted by DBAs. Even when this isn't the case, such access can be temporary and audited at the OS-level. The real problem is DBAs ourselves, who seem to treasure day-to-day usage of the Oracle software owner and membership of private accounts in the OS_SYSDBA and OS_SYSOPER groups... - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 4:53 AM Jared, Very interested in the thread you hypothetical raised. I'm working in a pharamceutical site which is subject to FDA and other regualtions part of which is the whole buisness of audit trails. We has a Standard Operating Procedure which states that whilst DBA's have a access to data they will not change it. A recognition of the DBA's capabilties but stating on paper company trust they will behave themselves. On a more practical point with NT/W2K Oracle audit trail can be set to write audit trail records to the event logs. DBA's can be prevented from changing the event logs. So now it would take at least 2 people to instigate a fraud. Hey this might foster even better relations between DBA's and SA's ;) Just my 2 cent worth :) - Seán O' Neill Organon (Ireland) Ltd. [subscribed: digest mode] From: [EMAIL PROTECTED] Date: Tue, 26 Nov 2002 14:40:24 -0800 Subject: Oracle OS level security Dear list, Let me toss a hypothetical situation at you. etc. etc. This message, including attached files, may contain confidential information and is intended only for the use by the individual and/or the entity to which it is addressed. Any unauthorized use, dissemination of, or copying of the information contained herein is not allowed and may lead to irreparable harm and damage for which you may be held liable. If you receive this message in error or if it is intended for someone else please notify the sender by returning this e-mail immediately and delete the message. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: O'Neill, Sean INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Tim Gorman INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Oracle OS level security
On Thursday 28 November 2002 12:03, Tim Gorman wrote: My $0.02... Oracle9i provides the AUDIT_SYS_OPERATIONS parameter, which will audit only to the OS audit trail. Thus, anything that SYSDBA does can be audited. The reason for the OS audit-trail only? Because SYSDBA can always erase a DB audit trail (even if the act of erasure is still audited). All SYSDBA however, can be prevented from reading or modifying the OS audit trail. This doesn't prevent a SA with DBA knowledge from wreaking havoc. I believe the only secure configuration for an Oracle database has the software owner (typically named oracle) and OS_SYSDBA and OS_SYSOPER groups under control of SysAdmins only. Those with SYSDBA do not need access to that OS account or those OS groups. SA's still a problem. The real problem is DBAs ourselves, who seem to treasure day-to-day usage of the Oracle software owner and membership of private accounts in the OS_SYSDBA and OS_SYSOPER groups... Personally, I log into the 'oracle' or 'root' account only as needed. Except on NT of course, where I need admin access to do my job properly. Maybe in a larger shop that wouldn't be necessary, but in a small shop it's very difficult to have an SA at your side when needed for admin level access. Jared - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 4:53 AM Jared, Very interested in the thread you hypothetical raised. I'm working in a pharamceutical site which is subject to FDA and other regualtions part of which is the whole buisness of audit trails. We has a Standard Operating Procedure which states that whilst DBA's have a access to data they will not change it. A recognition of the DBA's capabilties but stating on paper company trust they will behave themselves. On a more practical point with NT/W2K Oracle audit trail can be set to write audit trail records to the event logs. DBA's can be prevented from changing the event logs. So now it would take at least 2 people to instigate a fraud. Hey this might foster even better relations between DBA's and SA's ;) Just my 2 cent worth :) - Seán O' Neill Organon (Ireland) Ltd. [subscribed: digest mode] From: [EMAIL PROTECTED] Date: Tue, 26 Nov 2002 14:40:24 -0800 Subject: Oracle OS level security Dear list, Let me toss a hypothetical situation at you. etc. etc. This message, including attached files, may contain confidential information and is intended only for the use by the individual and/or the entity to which it is addressed. Any unauthorized use, dissemination of, or copying of the information contained herein is not allowed and may lead to irreparable harm and damage for which you may be held liable. If you receive this message in error or if it is intended for someone else please notify the sender by returning this e-mail immediately and delete the message. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: O'Neill, Sean INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Oracle OS level security
On Thursday 28 November 2002 03:53, O'Neill, Sean wrote: We has a Standard Operating Procedure which states that whilst DBA's have a access to data they will not change it. A recognition of the DBA's capabilties but stating on paper company trust they will behave themselves. Auditors are usually bean counters (accountants). They don't trust anybody. On a more practical point with NT/W2K Oracle audit trail can be set to write audit trail records to the event logs. DBA's can be prevented from changing the event logs. So now it would take at least 2 people to instigate a fraud. Hey this might foster even better relations between DBA's and SA's ;) OS level audit trails won't track block level hacking, such as with BBED. Jared Just my 2 cent worth :) - Seán O' Neill Organon (Ireland) Ltd. [subscribed: digest mode] From: [EMAIL PROTECTED] Date: Tue, 26 Nov 2002 14:40:24 -0800 Subject: Oracle OS level security Dear list, Let me toss a hypothetical situation at you. etc. etc. This message, including attached files, may contain confidential information and is intended only for the use by the individual and/or the entity to which it is addressed. Any unauthorized use, dissemination of, or copying of the information contained herein is not allowed and may lead to irreparable harm and damage for which you may be held liable. If you receive this message in error or if it is intended for someone else please notify the sender by returning this e-mail immediately and delete the message. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Oracle OS level security
--- Jared Still [EMAIL PROTECTED] wrote: On Thursday 28 November 2002 03:53, O'Neill, Sean wrote: We has a Standard Operating Procedure which states that whilst DBA's have a access to data they will not change it. A recognition of the DBA's capabilties but stating on paper company trust they will behave themselves. Auditors are usually bean counters (accountants). They don't trust anybody. Jared -- not necessarily so. Back at the company at which I was employed longest and where I learned to be a DBA, the auditors didn't have a CLUE about how to deal with databases and auditing of them. The data center would say in their audit paperwork database auditing is done via controls installed by the application managers and the application managers would say database auditing is done via controls installed by the data center. And I would be instructed to SHUT UP and tell the auditors only the least amount of information I could get away with. The auditors bought it, year after year. I finally, just before I left, sat down and had a heart to heart talk with one of the auditors, explaining that they had had a development DBA (me) with total production access for years. It was too much work for them to develop a database auditing process, at least, they didn't get one even started before I left. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Oracle OS level security
I believe the BBED tool is being phased out. Regards, Patrice Boivin Systems Analyst (Oracle Certified DBA) -Original Message- Sent: Tuesday, November 26, 2002 8:09 PM To: Multiple recipients of list ORACLE-L Jared: Any one with a reasonable knowledge of Oracle Data Storage Internals can use the Data block Editor (BBED) to update anything in your database without the knowledge of the RDBMS kernel auditing mechanisms. Agreed,BBED is protected by a password in Windoze ports and one need to explicitly make the executable in Unix ports. But the point here is the hacker can do anything using the BBEd and this can be done even while your database is up and running !! What is their take on this kind of attack(!)s? Best Regards, K Gopalakrishnan -Original Message- [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 3:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that. Make your bogus data changes, change the init.ora back and bounce the database again. A somewhat clever person could set this up to automatically take place the next time the DB is bounced. The conclusion I have come to is that the only effective method that could be used to create an audit trail for such a scenario is to create Materialized Views on sensitive tables, and create them on a server that admins are guaranteed to not have access to. Of course, I may be missing something. I'm not always one to catch all the details right off. Input, comments, suggestions, far out ideas are all welcome. If you've read this far, thanks! Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: K Gopalakrishnan INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San
RE: Oracle OS level security
Jared, Nice question. I don't have an answer, but a comment. It all comes down to Risk Management. In my opinion, Risk Management entails identifying all known risks to losing or changing data in an authorized manner. Once the risks are identified and explained to the organization, they decide what needs to be dealt with and what they are willing to risk based on the probability of the event actually happening. In your example, you've identified the risk of allowing other people admin access on the database server machine. If management is unwilling to revoke these privs, then they need to understand the risk that they have accepted. The risk they've accepted is that someone could, thru the use of stolen passwords, the BBED editor, or simply deleting a database file, cause a disruption, loss of service or loss of data to the organization. And there is not much you (as the DBA) can do about it. I'm sure I'm preaching to the choir here. But a lot of what we (DBA's) do comes down to communication and education of management, and explaining things in terms that they can understand. Hope this helps. Tom Mercadante Oracle Certified Professional -Original Message- Sent: Tuesday, November 26, 2002 6:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that. Make your bogus data changes, change the init.ora back and bounce the database again. A somewhat clever person could set this up to automatically take place the next time the DB is bounced. The conclusion I have come to is that the only effective method that could be used to create an audit trail for such a scenario is to create Materialized Views on sensitive tables, and create them on a server that admins are guaranteed to not have access to. Of course, I may be missing something. I'm not always one to catch all the details right off. Input, comments, suggestions, far out ideas are all welcome. If you've read this far, thanks! Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message
RE: Oracle OS level security
Jared - I think Thomas has a good point. Here is the way I look at it: 1. Make the server with critical information as secure as possible. 2. Restrict command line or console access to the minimum number of people. This narrows you down to a few sys admins and DBAs. For them your choices are: 1. Hire trustworthy professionals, people that can be intimidated by the threat of being fired. 2. Hire people too stupid to understand how to break into stuff. 3. Configure a really paranoid system to keep the people that must manage the system from being able to do their job. You could spend a lot of extra effort on this one. And it would have to be designed and audited by people outside the company. Years ago, a company I worked for tried option 3. It was a mainframe system with no interactive access. There were three groups of people that worked there, keypunch operators, programmers, and computer operators. The theory was that to defraud the system would require more than one person. A programmer could write a bogus program, but couldn't run it, would need an operator. And so on. They even had a separate building entrance for each group. Nobody outside of management seemed to think it was all that secure. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Wednesday, November 27, 2002 7:14 AM To: Multiple recipients of list ORACLE-L Jared, Nice question. I don't have an answer, but a comment. It all comes down to Risk Management. In my opinion, Risk Management entails identifying all known risks to losing or changing data in an authorized manner. Once the risks are identified and explained to the organization, they decide what needs to be dealt with and what they are willing to risk based on the probability of the event actually happening. In your example, you've identified the risk of allowing other people admin access on the database server machine. If management is unwilling to revoke these privs, then they need to understand the risk that they have accepted. The risk they've accepted is that someone could, thru the use of stolen passwords, the BBED editor, or simply deleting a database file, cause a disruption, loss of service or loss of data to the organization. And there is not much you (as the DBA) can do about it. I'm sure I'm preaching to the choir here. But a lot of what we (DBA's) do comes down to communication and education of management, and explaining things in terms that they can understand. Hope this helps. Tom Mercadante Oracle Certified Professional -Original Message- Sent: Tuesday, November 26, 2002 6:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save
Re: Oracle OS level security
Hadn't even considered BBED, and I have no idea what their take is on it. Guess I'll have to ask. Jared On Tuesday 26 November 2002 16:09, K Gopalakrishnan wrote: Jared: Any one with a reasonable knowledge of Oracle Data Storage Internals can use the Data block Editor (BBED) to update anything in your database without the knowledge of the RDBMS kernel auditing mechanisms. Agreed,BBED is protected by a password in Windoze ports and one need to explicitly make the executable in Unix ports. But the point here is the hacker can do anything using the BBEd and this can be done even while your database is up and running !! What is their take on this kind of attack(!)s? Best Regards, K Gopalakrishnan -Original Message- [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 3:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that. Make your bogus data changes, change the init.ora back and bounce the database again. A somewhat clever person could set this up to automatically take place the next time the DB is bounced. The conclusion I have come to is that the only effective method that could be used to create an audit trail for such a scenario is to create Materialized Views on sensitive tables, and create them on a server that admins are guaranteed to not have access to. Of course, I may be missing something. I'm not always one to catch all the details right off. Input, comments, suggestions, far out ideas are all welcome. If you've read this far, thanks! Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Oracle OS level security
True, and the question suggests the DBA can be properly vetted while the system administator cannot. I suppose one could try somne type of two-man control. Jared and his system administrator each know a different half of the root and sysdba passwordJust how this could be setup is beyond my ken. Responses to database emergencies would be interesting. If one could implement a system which would fully protect the database from system administrators, one would also need to weigh the costs of that protection against the perceived gain. Ian MacGregor Stanford Linear Accelerator Center [EMAIL PROTECTED] -Original Message- Sent: Wednesday, November 27, 2002 5:14 AM To: Multiple recipients of list ORACLE-L Jared, Nice question. I don't have an answer, but a comment. It all comes down to Risk Management. In my opinion, Risk Management entails identifying all known risks to losing or changing data in an authorized manner. Once the risks are identified and explained to the organization, they decide what needs to be dealt with and what they are willing to risk based on the probability of the event actually happening. In your example, you've identified the risk of allowing other people admin access on the database server machine. If management is unwilling to revoke these privs, then they need to understand the risk that they have accepted. The risk they've accepted is that someone could, thru the use of stolen passwords, the BBED editor, or simply deleting a database file, cause a disruption, loss of service or loss of data to the organization. And there is not much you (as the DBA) can do about it. I'm sure I'm preaching to the choir here. But a lot of what we (DBA's) do comes down to communication and education of management, and explaining things in terms that they can understand. Hope this helps. Tom Mercadante Oracle Certified Professional -Original Message- Sent: Tuesday, November 26, 2002 6:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that. Make your bogus data changes, change the init.ora back and bounce the database again. A somewhat clever person could set this up to automatically take place the next time the DB is bounced. The conclusion I have come to is that the only effective method that could be used to create an audit trail for such a scenario is to create
RE: Oracle OS level security
Jared, It seems to me that you can use these auditors to your advantage. Tell them the security risks that you know about, and let them write their report. You might be able to use the report to coerce management for some changes - like dedicated Database servers with a limited number of people who have access to them. audits can be a good thing. Tom Mercadante Oracle Certified Professional -Original Message- Sent: Wednesday, November 27, 2002 9:09 AM To: Multiple recipients of list ORACLE-L Hadn't even considered BBED, and I have no idea what their take is on it. Guess I'll have to ask. Jared On Tuesday 26 November 2002 16:09, K Gopalakrishnan wrote: Jared: Any one with a reasonable knowledge of Oracle Data Storage Internals can use the Data block Editor (BBED) to update anything in your database without the knowledge of the RDBMS kernel auditing mechanisms. Agreed,BBED is protected by a password in Windoze ports and one need to explicitly make the executable in Unix ports. But the point here is the hacker can do anything using the BBEd and this can be done even while your database is up and running !! What is their take on this kind of attack(!)s? Best Regards, K Gopalakrishnan -Original Message- [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 3:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that. Make your bogus data changes, change the init.ora back and bounce the database again. A somewhat clever person could set this up to automatically take place the next time the DB is bounced. The conclusion I have come to is that the only effective method that could be used to create an audit trail for such a scenario is to create Materialized Views on sensitive tables, and create them on a server that admins are guaranteed to not have access to. Of course, I may be missing something. I'm not always one to catch all the details right off. Input, comments, suggestions, far out ideas are all welcome. If you've read this far, thanks! Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services
RE: Oracle OS level security
Dennis, I must respectfully disagree with 1. I would suggest that the 'can' be changed to a 'cannot'. It is this type of person that will stand up and say 'This is wrong.' Therein lies your security. Dan Fink -Original Message- Sent: Wednesday, November 27, 2002 7:19 AM To: Multiple recipients of list ORACLE-L Jared - I think Thomas has a good point. Here is the way I look at it: 1. Make the server with critical information as secure as possible. 2. Restrict command line or console access to the minimum number of people. This narrows you down to a few sys admins and DBAs. For them your choices are: 1. Hire trustworthy professionals, people that can be intimidated by the threat of being fired. 2. Hire people too stupid to understand how to break into stuff. 3. Configure a really paranoid system to keep the people that must manage the system from being able to do their job. You could spend a lot of extra effort on this one. And it would have to be designed and audited by people outside the company. Years ago, a company I worked for tried option 3. It was a mainframe system with no interactive access. There were three groups of people that worked there, keypunch operators, programmers, and computer operators. The theory was that to defraud the system would require more than one person. A programmer could write a bogus program, but couldn't run it, would need an operator. And so on. They even had a separate building entrance for each group. Nobody outside of management seemed to think it was all that secure. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Wednesday, November 27, 2002 7:14 AM To: Multiple recipients of list ORACLE-L Jared, Nice question. I don't have an answer, but a comment. It all comes down to Risk Management. In my opinion, Risk Management entails identifying all known risks to losing or changing data in an authorized manner. Once the risks are identified and explained to the organization, they decide what needs to be dealt with and what they are willing to risk based on the probability of the event actually happening. In your example, you've identified the risk of allowing other people admin access on the database server machine. If management is unwilling to revoke these privs, then they need to understand the risk that they have accepted. The risk they've accepted is that someone could, thru the use of stolen passwords, the BBED editor, or simply deleting a database file, cause a disruption, loss of service or loss of data to the organization. And there is not much you (as the DBA) can do about it. I'm sure I'm preaching to the choir here. But a lot of what we (DBA's) do comes down to communication and education of management, and explaining things in terms that they can understand. Hope this helps. Tom Mercadante Oracle Certified Professional -Original Message- Sent: Tuesday, November 26, 2002 6:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for
RE: Oracle OS level security
Jared, I realize the following is not really an answer, but it may provide a little food for thought. Practical: 1. Log miner or other log reading tool could be used to track changes made through the transaction layer. Some operations can be done with nologging, but not all and the undo is logged regardless. Yes, it would be complicated and messy. 2. If you don't trust the SAs and DBAs for the systems, they need to be replaced. You are absolutely correct that if a person has the knowledge and motive, almost anything is possible. This is shown time and time again by corporate embezzlement. 3. As a DBA, I never want to know root's password. If I need SA type commands, either use sudo on unix (not sure if there is an equivalent on NT/2K) or provide exact information to the SA. I work on maintaining a good relationship with the SAs so we each respect each other's 'turf' and don't try to do things we are not qualified to do. 4. Changing passwords frequently, especially system generated ones, leads to people writing them down or otherwise storing them somewhere they can be accessed. I wonder how many of us have 1 password (with minor variations) for the overwhelming majority of our systems/logins. 5. Don't make security so onerous and inconvenient that people are constantly looking for ways around it just so that they can do their job. This encourages the creation of security holes and a general disregard for the processes and procedures. 6. If you create a server no admins have access to, how would it be set up and maintained? Theoretical The only truly secure system is the one that is never turned on. Once power is applied and the system is started, it can be compromised. An SA can su - oracle and login as sysdba, a DBA can spoof a user, a developer could insert malicious code. I think that the issue is to create and abide by standards and processes, hire trustworthy personnel and treat them right. As has been shown recently here in the US, there are significant business risks from unethical, greedy people. How are these prevented? Dan Fink -Original Message- Sent: Tuesday, November 26, 2002 4:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that. Make your bogus data changes, change the init.ora back and bounce the database again. A somewhat clever
RE: Oracle OS level security
Jared - I would be very careful about naming specific tools. Having been an NRC auditor and been audited a lot of times, there is sometimes too much specific information, which will leave the auditor with the impression there is no security at all. They will then feel obligated to flunk your system/process/site, or at least give you a ton or corrective action items. If you feel heavily obligated, you might allude to the fact that an expert could access the Oracle data at the O.S. level if they were very determined and leave it at that. I'm sure there are some O.S. tools that can accomplish what BBED can, if not as conveniently. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Wednesday, November 27, 2002 8:09 AM To: Multiple recipients of list ORACLE-L Hadn't even considered BBED, and I have no idea what their take is on it. Guess I'll have to ask. Jared On Tuesday 26 November 2002 16:09, K Gopalakrishnan wrote: Jared: Any one with a reasonable knowledge of Oracle Data Storage Internals can use the Data block Editor (BBED) to update anything in your database without the knowledge of the RDBMS kernel auditing mechanisms. Agreed,BBED is protected by a password in Windoze ports and one need to explicitly make the executable in Unix ports. But the point here is the hacker can do anything using the BBEd and this can be done even while your database is up and running !! What is their take on this kind of attack(!)s? Best Regards, K Gopalakrishnan -Original Message- [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 3:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that. Make your bogus data changes, change the init.ora back and bounce the database again. A somewhat clever person could set this up to automatically take place the next time the DB is bounced. The conclusion I have come to is that the only effective method that could be used to create an audit trail for such a scenario is to create Materialized Views on sensitive tables, and create them on a server that admins are guaranteed to not have access to. Of course, I may be missing something. I'm not always one to catch all the details right off. Input, comments, suggestions, far out ideas are all welcome. If you've read this far, thanks! Jared -- Please see the
RE: Oracle OS level security
My experience with NT security in an environment of any significant size is that it is a hopeless situation. In addition to dealing with admins on the box with the database, it seems that there is always an application support person or two that needs to administrator privs on that box too. Then there are the people that support multiple boxes, so they get domain admin privs. I set the privs on Oracle files so that any administrator would at least have to take ownership of the files in order to delete them. Following strict file and directory naming conventions and teaching everyone to recognize sacred file name patterns helps. We even had certain drive letters throughout the domain that were reserved for Oracle stuff so that people would know which drive letters were danger zones. With all this in place, the only problems we experienced were due to the flakey disk clustering that the admins were using. File systems (or the NT equivalent thereof) had a habit of getting unmounted, and Oracle seems to take offense at files suddenly disappearing. I wasn't all that worried about people going in and deleting files. My biggest worry was that we automate a lot of jobs and a lot of monitoring with scripts. Some of these require information, (such as passwords) be put into files; files that I can't protect on NT. I never had a big problem with admins being administrator (or root on Unix), but on NT it seems that there are always people from development, or people from some department up on 10th floor, that need administrator on the box too in order to support some app. So now you have developers and people you don't even know about that, if they chose to do so, can go nosing around in your stuff. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Stephen Lee INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Oracle OS level security
After pondering this for a few minutes, I came to the conclusion that BED doesn't matter. First, I need to clarify a proposed audit trail. It consists of an audit table on a sensitive table. The audit table is populated via trigger and records all updates/inserts/deletes. The audit table is replicated to a secure server via Materialized View. It doesn't matter *how* fraudulent transactions are entered into the table. The audit trail is still in place, and data in the production system would not correspond with the audit trail. Jared K Gopalakrishnan [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/26/2002 04:09 PM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc: Subject:RE: Oracle OS level security Jared: Any one with a reasonable knowledge of Oracle Data Storage Internals can use the Data block Editor (BBED) to update anything in your database without the knowledge of the RDBMS kernel auditing mechanisms. Agreed,BBED is protected by a password in Windoze ports and one need to explicitly make the executable in Unix ports. But the point here is the hacker can do anything using the BBEd and this can be done even while your database is up and running !! What is their take on this kind of attack(!)s? Best Regards, K Gopalakrishnan -Original Message- [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 3:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that. Make your bogus data changes, change the init.ora back and bounce the database again. A somewhat clever person could set this up to automatically take place the next time the DB is bounced. The conclusion I have come to is that the only effective method that could be used to create an audit trail for such a scenario is to create Materialized Views on sensitive tables, and create them on a server that admins are guaranteed to not have access to. Of course, I may be missing something. I'm not always one to catch all the details right off. Input, comments, suggestions, far out ideas are all welcome. If you've read this far, thanks! Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services
RE: Oracle OS level security
H...just thinking. How much of the sensitive info is encrypted to/from the client? If us SA/DBA folks can't get around system-level and DB-level audits (made more difficult in 9i), network snooping and forging of unencrypted data right from the DB server could be another hole to exploit (one reason why my paranoia prevents me from viewing my paycheck online and unencrypted here at work). BTW, I can't find any hint of a BBDE program on 9iR2/Winders nor 8.1.7 on HP. I would like it to learn more about block level storage (on our TEST DBs, obviously!). Anyone with more info on this? Rich Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA -Original Message- From: Mercadante, Thomas F [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 10:20 AM To: Multiple recipients of list ORACLE-L Subject: RE: Oracle OS level security Let's face it. The SA's have all the privs in the world. Finally, with 9i, and connect internal going away, we can prevent unauthorized connections to the database to prevent data snooping. But we all know that there are ways around everything in this world. It comes down to this simple point: The organization has to trust someone with the keys to the treasury. It is unavoidable. Tom Mercadante Oracle Certified Professional -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jesse, Rich INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Oracle OS level security
Let's face it. The SA's have all the privs in the world. Finally, with 9i, and connect internal going away, we can prevent unauthorized connections to the database to prevent data snooping. But we all know that there are ways around everything in this world. It comes down to this simple point: The organization has to trust someone with the keys to the treasury. It is unavoidable. Tom Mercadante Oracle Certified Professional -Original Message- Sent: Wednesday, November 27, 2002 9:59 AM To: Multiple recipients of list ORACLE-L True, and the question suggests the DBA can be properly vetted while the system administator cannot. I suppose one could try somne type of two-man control. Jared and his system administrator each know a different half of the root and sysdba passwordJust how this could be setup is beyond my ken. Responses to database emergencies would be interesting. If one could implement a system which would fully protect the database from system administrators, one would also need to weigh the costs of that protection against the perceived gain. Ian MacGregor Stanford Linear Accelerator Center [EMAIL PROTECTED] -Original Message- Sent: Wednesday, November 27, 2002 5:14 AM To: Multiple recipients of list ORACLE-L Jared, Nice question. I don't have an answer, but a comment. It all comes down to Risk Management. In my opinion, Risk Management entails identifying all known risks to losing or changing data in an authorized manner. Once the risks are identified and explained to the organization, they decide what needs to be dealt with and what they are willing to risk based on the probability of the event actually happening. In your example, you've identified the risk of allowing other people admin access on the database server machine. If management is unwilling to revoke these privs, then they need to understand the risk that they have accepted. The risk they've accepted is that someone could, thru the use of stolen passwords, the BBED editor, or simply deleting a database file, cause a disruption, loss of service or loss of data to the organization. And there is not much you (as the DBA) can do about it. I'm sure I'm preaching to the choir here. But a lot of what we (DBA's) do comes down to communication and education of management, and explaining things in terms that they can understand. Hope this helps. Tom Mercadante Oracle Certified Professional -Original Message- Sent: Tuesday, November 26, 2002 6:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password
RE: Oracle OS level security
Dan Point taken. I was thinking more of being careful with recently hired employees and consultants that will only be around for a short time. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Wednesday, November 27, 2002 10:10 AM To: Multiple recipients of list ORACLE-L Dennis, I must respectfully disagree with 1. I would suggest that the 'can' be changed to a 'cannot'. It is this type of person that will stand up and say 'This is wrong.' Therein lies your security. Dan Fink -Original Message- Sent: Wednesday, November 27, 2002 7:19 AM To: Multiple recipients of list ORACLE-L Jared - I think Thomas has a good point. Here is the way I look at it: 1. Make the server with critical information as secure as possible. 2. Restrict command line or console access to the minimum number of people. This narrows you down to a few sys admins and DBAs. For them your choices are: 1. Hire trustworthy professionals, people that can be intimidated by the threat of being fired. 2. Hire people too stupid to understand how to break into stuff. 3. Configure a really paranoid system to keep the people that must manage the system from being able to do their job. You could spend a lot of extra effort on this one. And it would have to be designed and audited by people outside the company. Years ago, a company I worked for tried option 3. It was a mainframe system with no interactive access. There were three groups of people that worked there, keypunch operators, programmers, and computer operators. The theory was that to defraud the system would require more than one person. A programmer could write a bogus program, but couldn't run it, would need an operator. And so on. They even had a separate building entrance for each group. Nobody outside of management seemed to think it was all that secure. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Wednesday, November 27, 2002 7:14 AM To: Multiple recipients of list ORACLE-L Jared, Nice question. I don't have an answer, but a comment. It all comes down to Risk Management. In my opinion, Risk Management entails identifying all known risks to losing or changing data in an authorized manner. Once the risks are identified and explained to the organization, they decide what needs to be dealt with and what they are willing to risk based on the probability of the event actually happening. In your example, you've identified the risk of allowing other people admin access on the database server machine. If management is unwilling to revoke these privs, then they need to understand the risk that they have accepted. The risk they've accepted is that someone could, thru the use of stolen passwords, the BBED editor, or simply deleting a database file, cause a disruption, loss of service or loss of data to the organization. And there is not much you (as the DBA) can do about it. I'm sure I'm preaching to the choir here. But a lot of what we (DBA's) do comes down to communication and education of management, and explaining things in terms that they can understand. Hope this helps. Tom Mercadante Oracle Certified Professional -Original Message- Sent: Tuesday, November 26, 2002 6:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's
RE: Oracle OS level security
You may just possibly be the only other DBA besides me who does NOT want root access! I know just enough to be dangerous. I have more than enough work to do without taking over the SA's job as well. theoretical point 2: yes, you should trust your DBAs and SAs. But if you, for whatever reason, have to have a temporary person in, someone you don't know, who leaves and is not reachable/accountable, then it behooves you to put some sort of controls in place. perhaps just logging each session so that what is done can be seen, without making it so onerous that people try to circumvent the rules. We have a hosting company here for our staging and production servers. I have an account on both servers. They have not, as yet, changed the database passwords (we're in the process of going live and they haven't set up a read-only account for me). I *could* go in and fix the problems. That would be the fast way, and the users certainly would appreciate it. I follow the rules. Submit change requests, with scripts attached. It's safer all around. --- Fink, Dan [EMAIL PROTECTED] wrote: Jared, I realize the following is not really an answer, but it may provide a little food for thought. Practical: 1. Log miner or other log reading tool could be used to track changes made through the transaction layer. Some operations can be done with nologging, but not all and the undo is logged regardless. Yes, it would be complicated and messy. 2. If you don't trust the SAs and DBAs for the systems, they need to be replaced. You are absolutely correct that if a person has the knowledge and motive, almost anything is possible. This is shown time and time again by corporate embezzlement. 3. As a DBA, I never want to know root's password. If I need SA type commands, either use sudo on unix (not sure if there is an equivalent on NT/2K) or provide exact information to the SA. I work on maintaining a good relationship with the SAs so we each respect each other's 'turf' and don't try to do things we are not qualified to do. 4. Changing passwords frequently, especially system generated ones, leads to people writing them down or otherwise storing them somewhere they can be accessed. I wonder how many of us have 1 password (with minor variations) for the overwhelming majority of our systems/logins. 5. Don't make security so onerous and inconvenient that people are constantly looking for ways around it just so that they can do their job. This encourages the creation of security holes and a general disregard for the processes and procedures. 6. If you create a server no admins have access to, how would it be set up and maintained? Theoretical The only truly secure system is the one that is never turned on. Once power is applied and the system is started, it can be compromised. An SA can su - oracle and login as sysdba, a DBA can spoof a user, a developer could insert malicious code. I think that the issue is to create and abide by standards and processes, hire trustworthy personnel and treat them right. As has been shown recently here in the US, there are significant business risks from unethical, greedy people. How are these prevented? Dan Fink -Original Message- Sent: Tuesday, November 26, 2002 4:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more
RE: Oracle OS level security
NRC audits, boy those sure are fun to be on the receiving end of. Nothing like getting comfy on the couch and reading 10CFR for pleasure. -Original Message- Sent: Wednesday, November 27, 2002 10:56 AM To: Multiple recipients of list ORACLE-L Jared - I would be very careful about naming specific tools. Having been an NRC auditor and been audited a lot of times, there is sometimes too much specific information, which will leave the auditor with the impression there is no security at all. They will then feel obligated to flunk your system/process/site, or at least give you a ton or corrective action items. If you feel heavily obligated, you might allude to the fact that an expert could access the Oracle data at the O.S. level if they were very determined and leave it at that. I'm sure there are some O.S. tools that can accomplish what BBED can, if not as conveniently. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Wednesday, November 27, 2002 8:09 AM To: Multiple recipients of list ORACLE-L Hadn't even considered BBED, and I have no idea what their take is on it. Guess I'll have to ask. Jared On Tuesday 26 November 2002 16:09, K Gopalakrishnan wrote: Jared: Any one with a reasonable knowledge of Oracle Data Storage Internals can use the Data block Editor (BBED) to update anything in your database without the knowledge of the RDBMS kernel auditing mechanisms. Agreed,BBED is protected by a password in Windoze ports and one need to explicitly make the executable in Unix ports. But the point here is the hacker can do anything using the BBEd and this can be done even while your database is up and running !! What is their take on this kind of attack(!)s? Best Regards, K Gopalakrishnan -Original Message- [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 3:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that. Make your bogus data changes, change the init.ora back and bounce the database again. A somewhat clever person could set this up to automatically take place the next time the DB is bounced. The conclusion I have come to is that the only effective method that could be used to create an audit trail for such a scenario is to create Materialized Views on sensitive tables, and create them on a server that admins are
RE: Oracle OS level security
Just a thought. How about also encrypt the sensitive data. And the one who holds the key to decrypt it doesn't have access to the system. And the one does have access doesn't know the key to decrypt. The two will have to work together to do un-authorized things, but at least it will make it harder. Don't introduce them, ever. :) Richard Ji -Original Message- Sent: Wednesday, November 27, 2002 11:20 AM To: Multiple recipients of list ORACLE-L Let's face it. The SA's have all the privs in the world. Finally, with 9i, and connect internal going away, we can prevent unauthorized connections to the database to prevent data snooping. But we all know that there are ways around everything in this world. It comes down to this simple point: The organization has to trust someone with the keys to the treasury. It is unavoidable. Tom Mercadante Oracle Certified Professional -Original Message- Sent: Wednesday, November 27, 2002 9:59 AM To: Multiple recipients of list ORACLE-L True, and the question suggests the DBA can be properly vetted while the system administator cannot. I suppose one could try somne type of two-man control. Jared and his system administrator each know a different half of the root and sysdba passwordJust how this could be setup is beyond my ken. Responses to database emergencies would be interesting. If one could implement a system which would fully protect the database from system administrators, one would also need to weigh the costs of that protection against the perceived gain. Ian MacGregor Stanford Linear Accelerator Center [EMAIL PROTECTED] -Original Message- Sent: Wednesday, November 27, 2002 5:14 AM To: Multiple recipients of list ORACLE-L Jared, Nice question. I don't have an answer, but a comment. It all comes down to Risk Management. In my opinion, Risk Management entails identifying all known risks to losing or changing data in an authorized manner. Once the risks are identified and explained to the organization, they decide what needs to be dealt with and what they are willing to risk based on the probability of the event actually happening. In your example, you've identified the risk of allowing other people admin access on the database server machine. If management is unwilling to revoke these privs, then they need to understand the risk that they have accepted. The risk they've accepted is that someone could, thru the use of stolen passwords, the BBED editor, or simply deleting a database file, cause a disruption, loss of service or loss of data to the organization. And there is not much you (as the DBA) can do about it. I'm sure I'm preaching to the choir here. But a lot of what we (DBA's) do comes down to communication and education of management, and explaining things in terms that they can understand. Hope this helps. Tom Mercadante Oracle Certified Professional -Original Message- Sent: Tuesday, November 26, 2002 6:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used
RE: Oracle OS level security
Excellent point. I always say, I know enough NOT to be dangerous. Funny, two comments that are syntactically opposite, really mean the same thing. -Original Message- Sent: Wednesday, November 27, 2002 11:45 AM To: Multiple recipients of list ORACLE-L You may just possibly be the only other DBA besides me who does NOT want root access! I know just enough to be dangerous. I have more than enough work to do without taking over the SA's job as well. theoretical point 2: yes, you should trust your DBAs and SAs. But if you, for whatever reason, have to have a temporary person in, someone you don't know, who leaves and is not reachable/accountable, then it behooves you to put some sort of controls in place. perhaps just logging each session so that what is done can be seen, without making it so onerous that people try to circumvent the rules. We have a hosting company here for our staging and production servers. I have an account on both servers. They have not, as yet, changed the database passwords (we're in the process of going live and they haven't set up a read-only account for me). I *could* go in and fix the problems. That would be the fast way, and the users certainly would appreciate it. I follow the rules. Submit change requests, with scripts attached. It's safer all around. --- Fink, Dan [EMAIL PROTECTED] wrote: Jared, I realize the following is not really an answer, but it may provide a little food for thought. Practical: 1. Log miner or other log reading tool could be used to track changes made through the transaction layer. Some operations can be done with nologging, but not all and the undo is logged regardless. Yes, it would be complicated and messy. 2. If you don't trust the SAs and DBAs for the systems, they need to be replaced. You are absolutely correct that if a person has the knowledge and motive, almost anything is possible. This is shown time and time again by corporate embezzlement. 3. As a DBA, I never want to know root's password. If I need SA type commands, either use sudo on unix (not sure if there is an equivalent on NT/2K) or provide exact information to the SA. I work on maintaining a good relationship with the SAs so we each respect each other's 'turf' and don't try to do things we are not qualified to do. 4. Changing passwords frequently, especially system generated ones, leads to people writing them down or otherwise storing them somewhere they can be accessed. I wonder how many of us have 1 password (with minor variations) for the overwhelming majority of our systems/logins. 5. Don't make security so onerous and inconvenient that people are constantly looking for ways around it just so that they can do their job. This encourages the creation of security holes and a general disregard for the processes and procedures. 6. If you create a server no admins have access to, how would it be set up and maintained? Theoretical The only truly secure system is the one that is never turned on. Once power is applied and the system is started, it can be compromised. An SA can su - oracle and login as sysdba, a DBA can spoof a user, a developer could insert malicious code. I think that the issue is to create and abide by standards and processes, hire trustworthy personnel and treat them right. As has been shown recently here in the US, there are significant business risks from unethical, greedy people. How are these prevented? Dan Fink -Original Message- Sent: Tuesday, November 26, 2002 4:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized
RE: Oracle OS level security
Dave - Good to hear from a fellow-sufferer. It suddenly occurs to me that if the war on terrorism continues, the feds may mandate something like 10CFR for computer security. I recall that 10CFR was adapted from something earlier. Whew boy, I can hardly wait. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Wednesday, November 27, 2002 12:49 PM To: Multiple recipients of list ORACLE-L NRC audits, boy those sure are fun to be on the receiving end of. Nothing like getting comfy on the couch and reading 10CFR for pleasure. -Original Message- Sent: Wednesday, November 27, 2002 10:56 AM To: Multiple recipients of list ORACLE-L Jared - I would be very careful about naming specific tools. Having been an NRC auditor and been audited a lot of times, there is sometimes too much specific information, which will leave the auditor with the impression there is no security at all. They will then feel obligated to flunk your system/process/site, or at least give you a ton or corrective action items. If you feel heavily obligated, you might allude to the fact that an expert could access the Oracle data at the O.S. level if they were very determined and leave it at that. I'm sure there are some O.S. tools that can accomplish what BBED can, if not as conveniently. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Wednesday, November 27, 2002 8:09 AM To: Multiple recipients of list ORACLE-L Hadn't even considered BBED, and I have no idea what their take is on it. Guess I'll have to ask. Jared On Tuesday 26 November 2002 16:09, K Gopalakrishnan wrote: Jared: Any one with a reasonable knowledge of Oracle Data Storage Internals can use the Data block Editor (BBED) to update anything in your database without the knowledge of the RDBMS kernel auditing mechanisms. Agreed,BBED is protected by a password in Windoze ports and one need to explicitly make the executable in Unix ports. But the point here is the hacker can do anything using the BBEd and this can be done even while your database is up and running !! What is their take on this kind of attack(!)s? Best Regards, K Gopalakrishnan -Original Message- [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 3:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that.
Re: Oracle OS level security
Very nicely put, Dan. I was thinking about words which have deserted modern vocabulary, such as 'duty' or 'virtue' (in the Latin sense). Somewhere along the line you have to trust people. Dennis, I must respectfully disagree with 1. I would suggest that the 'can' be changed to a 'cannot'. It is this type of person that will stand up and say 'This is wrong.' Therein lies your security. Dan Fink -Original Message- Sent: Wednesday, November 27, 2002 7:19 AM To: Multiple recipients of list ORACLE-L Jared - I think Thomas has a good point. Here is the way I look at it: 1. Make the server with critical information as secure as possible. 2. Restrict command line or console access to the minimum number of people. This narrows you down to a few sys admins and DBAs. For them your choices are: 1. Hire trustworthy professionals, people that can be intimidated by the threat of being fired. 2. Hire people too stupid to understand how to break into stuff. 3. Configure a really paranoid system to keep the people that must manage the system from being able to do their job. You could spend a lot of extra effort on this one. And it would have to be designed and audited by people outside the company. Years ago, a company I worked for tried option 3. It was a mainframe system with no interactive access. There were three groups of people that worked there, keypunch operators, programmers, and computer operators. The theory was that to defraud the system would require more than one person. A programmer could write a bogus program, but couldn't run it, would need an operator. And so on. They even had a separate building entrance for each group. Nobody outside of management seemed to think it was all that secure. Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Wednesday, November 27, 2002 7:14 AM To: Multiple recipients of list ORACLE-L Jared, Nice question. I don't have an answer, but a comment. It all comes down to Risk Management. In my opinion, Risk Management entails identifying all known risks to losing or changing data in an authorized manner. Once the risks are identified and explained to the organization, they decide what needs to be dealt with and what they are willing to risk based on the probability of the event actually happening. In your example, you've identified the risk of allowing other people admin access on the database server machine. If management is unwilling to revoke these privs, then they need to understand the risk that they have accepted. The risk they've accepted is that someone could, thru the use of stolen passwords, the BBED editor, or simply deleting a database file, cause a disruption, loss of service or loss of data to the organization. And there is not much you (as the DBA) can do about it. I'm sure I'm preaching to the choir here. But a lot of what we (DBA's) do comes down to communication and education of management, and explaining things in terms that they can understand. Hope this helps. Tom Mercadante Oracle Certified Professional -Original Message- Sent: Tuesday, November 26, 2002 6:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the
Oracle OS level security
Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that. Make your bogus data changes, change the init.ora back and bounce the database again. A somewhat clever person could set this up to automatically take place the next time the DB is bounced. The conclusion I have come to is that the only effective method that could be used to create an audit trail for such a scenario is to create Materialized Views on sensitive tables, and create them on a server that admins are guaranteed to not have access to. Of course, I may be missing something. I'm not always one to catch all the details right off. Input, comments, suggestions, far out ideas are all welcome. If you've read this far, thanks! Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Oracle OS level security
Jared: Any one with a reasonable knowledge of Oracle Data Storage Internals can use the Data block Editor (BBED) to update anything in your database without the knowledge of the RDBMS kernel auditing mechanisms. Agreed,BBED is protected by a password in Windoze ports and one need to explicitly make the executable in Unix ports. But the point here is the hacker can do anything using the BBEd and this can be done even while your database is up and running !! What is their take on this kind of attack(!)s? Best Regards, K Gopalakrishnan -Original Message- [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 3:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that. Make your bogus data changes, change the init.ora back and bounce the database again. A somewhat clever person could set this up to automatically take place the next time the DB is bounced. The conclusion I have come to is that the only effective method that could be used to create an audit trail for such a scenario is to create Materialized Views on sensitive tables, and create them on a server that admins are guaranteed to not have access to. Of course, I may be missing something. I'm not always one to catch all the details right off. Input, comments, suggestions, far out ideas are all welcome. If you've read this far, thanks! Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: K Gopalakrishnan INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL
Re: Oracle OS level security
jared, no answers... but I did read to the end. Thank YOU, you've given me a lot to think about and to talk to our hosting company about. What really scares me is that I have no way of auditing the hosting company who have total access to production. Rachel --- [EMAIL PROTECTED] wrote: Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that. Make your bogus data changes, change the init.ora back and bounce the database again. A somewhat clever person could set this up to automatically take place the next time the DB is bounced. The conclusion I have come to is that the only effective method that could be used to create an audit trail for such a scenario is to create Materialized Views on sensitive tables, and create them on a server that admins are guaranteed to not have access to. Of course, I may be missing something. I'm not always one to catch all the details right off. Input, comments, suggestions, far out ideas are all welcome. If you've read this far, thanks! Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). __ Do you Yahoo!? Yahoo! Mail Plus Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing
RE: Oracle OS level security
What is BBED? I never heard of it. From: K Gopalakrishnan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: Oracle OS level security Date: Tue, 26 Nov 2002 16:09:27 -0800 MIME-Version: 1.0 Received: from newsfeed.cts.com ([209.68.248.164]) by mc8-f17.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 26 Nov 2002 17:06:39 -0800 Received: from fatcity.UUCP (uucp@localhost)by newsfeed.cts.com (8.9.3/8.9.3) with UUCP id RAA43612;Tue, 26 Nov 2002 17:01:24 -0800 (PST) Received: by fatcity.com (26-Feb-2001/v1.0g-b72/bab) via UUCP id 0050CFBE; Tue, 26 Nov 2002 16:09:27 -0800 Message-ID: [EMAIL PROTECTED] X-Comment: Oracle RDBMS Community Forum X-Sender: K Gopalakrishnan [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Organization: Fat City Network Services, San Diego, California X-ListServer: v1.0g, build 72; ListGuru (c) 1996-2001 Bruce A. Bergman Precedence: bulk Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 27 Nov 2002 01:06:39.0079 (UTC) FILETIME=[3D590770:01C295B1] Jared: Any one with a reasonable knowledge of Oracle Data Storage Internals can use the Data block Editor (BBED) to update anything in your database without the knowledge of the RDBMS kernel auditing mechanisms. Agreed,BBED is protected by a password in Windoze ports and one need to explicitly make the executable in Unix ports. But the point here is the hacker can do anything using the BBEd and this can be done even while your database is up and running !! What is their take on this kind of attack(!)s? Best Regards, K Gopalakrishnan -Original Message- [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 3:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that. Make your bogus data changes, change the init.ora back and bounce the database again. A somewhat clever person could set this up to automatically take place the next time the DB is bounced. The conclusion I have come to is that the only effective method that could be used to create an audit trail for such a scenario is to create Materialized Views on sensitive tables, and create them on a server that admins are guaranteed to not have access to. Of course, I may be missing something. I'm not always one to catch all the details right off. Input, comments, suggestions, far out ideas are all welcome. If you've read
RE: Oracle OS level security
Arup: BBED is B lock B rowser ED itor. Best Regards, K Gopalakrishnan -Original Message- Sent: Tuesday, November 26, 2002 6:24 PM To: Multiple recipients of list ORACLE-L What is BBED? I never heard of it. From: K Gopalakrishnan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: Oracle OS level security Date: Tue, 26 Nov 2002 16:09:27 -0800 MIME-Version: 1.0 Received: from newsfeed.cts.com ([209.68.248.164]) by mc8-f17.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 26 Nov 2002 17:06:39 -0800 Received: from fatcity.UUCP (uucp@localhost)by newsfeed.cts.com (8.9.3/8.9.3) with UUCP id RAA43612;Tue, 26 Nov 2002 17:01:24 -0800 (PST) Received: by fatcity.com (26-Feb-2001/v1.0g-b72/bab) via UUCP id 0050CFBE; Tue, 26 Nov 2002 16:09:27 -0800 Message-ID: [EMAIL PROTECTED] X-Comment: Oracle RDBMS Community Forum X-Sender: K Gopalakrishnan [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Organization: Fat City Network Services, San Diego, California X-ListServer: v1.0g, build 72; ListGuru (c) 1996-2001 Bruce A. Bergman Precedence: bulk Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 27 Nov 2002 01:06:39.0079 (UTC) FILETIME=[3D590770:01C295B1] Jared: Any one with a reasonable knowledge of Oracle Data Storage Internals can use the Data block Editor (BBED) to update anything in your database without the knowledge of the RDBMS kernel auditing mechanisms. Agreed,BBED is protected by a password in Windoze ports and one need to explicitly make the executable in Unix ports. But the point here is the hacker can do anything using the BBEd and this can be done even while your database is up and running !! What is their take on this kind of attack(!)s? Best Regards, K Gopalakrishnan -Original Message- [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 3:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely cover the traces of transactions created to falsify data. The MV Logs could be dropped, but without access to the MV's at the remote server, the MV's would have to be left in place. These could be used as a reference to look for unauthorized transactions in the primary server. If this same admin has access to the remote server where the MV's are, then this can also be circumvented. There is also the logs created as when logging in as internal or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) These can simply be deleted. Some system could be used to save these to a remote server, but it would have to run *very* frequently to be effective. Oracle password files could also be used. While this can prevent someone from logging in as SYS or SYSTEM while in place, all it takes is a change to init.ora, and a database bounce to fix that. Make your bogus data changes, change the init.ora back and bounce the database again. A somewhat clever person could set this up to automatically take place the next time the DB is bounced. The conclusion I have come to is that the only effective method that could be used to create an audit trail for such a scenario is to create Materialized Views on sensitive tables, and create them on a server that admins are guaranteed to not have
RE: Oracle OS level security
Thanks for the info, Gopal. I did find a bbed.exe but it asks for a password. For unix ports it doesn't, per your post. Since you obviously have some experience on this tool; would you mind sharing that - usage and all. From: K Gopalakrishnan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: Oracle OS level security Date: Tue, 26 Nov 2002 19:28:42 -0800 MIME-Version: 1.0 Received: from newsfeed.cts.com ([209.68.248.164]) by mc6-f19.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 26 Nov 2002 19:57:49 -0800 Received: from fatcity.UUCP (uucp@localhost)by newsfeed.cts.com (8.9.3/8.9.3) with UUCP id TAA58357;Tue, 26 Nov 2002 19:52:14 -0800 (PST) Received: by fatcity.com (26-Feb-2001/v1.0g-b72/bab) via UUCP id 0050D21F; Tue, 26 Nov 2002 19:28:42 -0800 Message-ID: [EMAIL PROTECTED] X-Comment: Oracle RDBMS Community Forum X-Sender: K Gopalakrishnan [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Organization: Fat City Network Services, San Diego, California X-ListServer: v1.0g, build 72; ListGuru (c) 1996-2001 Bruce A. Bergman Precedence: bulk Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 27 Nov 2002 03:57:49.0937 (UTC) FILETIME=[27419610:01C295C9] Arup: BBED is B lock B rowser ED itor. Best Regards, K Gopalakrishnan -Original Message- Sent: Tuesday, November 26, 2002 6:24 PM To: Multiple recipients of list ORACLE-L What is BBED? I never heard of it. From: K Gopalakrishnan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: Oracle OS level security Date: Tue, 26 Nov 2002 16:09:27 -0800 MIME-Version: 1.0 Received: from newsfeed.cts.com ([209.68.248.164]) by mc8-f17.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 26 Nov 2002 17:06:39 -0800 Received: from fatcity.UUCP (uucp@localhost)by newsfeed.cts.com (8.9.3/8.9.3) with UUCP id RAA43612;Tue, 26 Nov 2002 17:01:24 -0800 (PST) Received: by fatcity.com (26-Feb-2001/v1.0g-b72/bab) via UUCP id 0050CFBE; Tue, 26 Nov 2002 16:09:27 -0800 Message-ID: [EMAIL PROTECTED] X-Comment: Oracle RDBMS Community Forum X-Sender: K Gopalakrishnan [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Organization: Fat City Network Services, San Diego, California X-ListServer: v1.0g, build 72; ListGuru (c) 1996-2001 Bruce A. Bergman Precedence: bulk Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 27 Nov 2002 01:06:39.0079 (UTC) FILETIME=[3D590770:01C295B1] Jared: Any one with a reasonable knowledge of Oracle Data Storage Internals can use the Data block Editor (BBED) to update anything in your database without the knowledge of the RDBMS kernel auditing mechanisms. Agreed,BBED is protected by a password in Windoze ports and one need to explicitly make the executable in Unix ports. But the point here is the hacker can do anything using the BBEd and this can be done even while your database is up and running !! What is their take on this kind of attack(!)s? Best Regards, K Gopalakrishnan -Original Message- [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 3:05 PM To: Multiple recipients of list ORACLE-L Dear list, Let me toss a hypothetical situation at you. Say some auditors looked at some of your primary systems, and concluded that they had no assurance that someone with admin access to the server had not changed financial information to benefit themselves, or to falsify financial records for the gain of the company. Not that they might have any proof that something like that had been done, but rather, just not proof that it had *not* been done. I've been pondering this for a bit, and it seems to me that if someone had good knowledge of both the OS and the database (Oracle), as well as having admin rights on the server, there are few things you can do to prevent such a person from changing data in the database, and completely covering his or her tracks. The platforms in question are Unix, Windows NT and Windows 2000. I've limited it to those as most database systems use one of those, and besides, that's all I know. :) Consider what steps you might take to audit unauthorized transactions performed by an admin. Oracle Auditing could be used, but someone with admin access to the server and database could easily alter the records created by system auditing. You could create an audit table, using a trigger to audit sensitive tables. A materialized view on a remote database could be created on sensitive tables to remotely log all actions. In the case of the audit table, that could easily be disabled, and then re-enabled after the nefarious DML had completed. The materialized views might be more difficult to circumvent. If the remote end is using a dblink to the server employing a password that is *different* than that of it's own account at the remote server, it should be impossible for someone to completely
