Call: +44 (0)7759 277220 Call
Forum

Welcome, Guest. Please Login.
Nov 23rd, 2024, 12:12pm
News: Welcome to Pete Finnigan's Oracle security forum
Home | Help | Search | Members | Login
   Pete Finnigan's Oracle Security Forum
   Oracle Security
   Oracle Security
(Moderator: Pete Finnigan)
   A few security questions
« Previous topic | Next topic »
Pages: 1  Reply | Notify of replies | Send Topic | Print
   Author  Topic: A few security questions  (Read 4750 times)
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
A few security questions
« on: Sep 28th, 2005, 7:00pm »
Quote | Modify

I have a few security related questions and would like to hear from you if these are really an issue in the real world.  If yes what their  Huhrisks are.  Any comments are appreciated.  
 
 
1. In the init.ora file, is it mandatory that we need to have the entries REMOTE_OS_AUTHENT and OS_AUTHENT_PREFIX.  If yes, what values  
should be set?  True or False?  
 
 
2. Using grep -i dba/etc/group and I have the following result: dbadev::511: and dba::510:secadm.  Would these be appropriate?  If not, what would be the risk?  
 
 
3. In the dba_profiles table, the SESSIONS_PER_USAER is set to  
unlimited.  
 
 
4. In the dba_profiles table, the password settings are all set to DEFAULT.   How to set up to force a password when an account is created?  
 
 
5. In the system tablespace, we have a lot of objects that are owned by non SYS account.  
 
 
6. Have a few entries in the sys.link$ whose passwords are not null.  
 
7. What would be the best practices to manage the system accounts?  Would it be an idea to keep track of each system account when it is created? The tracking includes creation date, associated applications, and so forth.
 
Does Oracle have any offical recommendations on these items?  Thanks.  
 
 
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: A few security questions
« Reply #1 on: Sep 29th, 2005, 8:26am »
Quote | Modify

Miloann,
 
Ad 1) REMOTE_OS_AUTHENT should be set to FALSE. For an explanation see http://www.petefinnigan.com/weblog/archives/00000071.htm
I don't think the setting of OS_AUTHENT_PREFIX is very important. The default is OPS$ (not true or false!).
 
Ad 2) Can't answer that without knowing what use dbadev has. The same for user secadm.
 
Ad 3) Set sessions_per_user to an appropriate value. Unlimited could cause problems. Not necessarily as a consequence of an hacker but application problems. One time we had a MS access applications selecting from a Oracle table and creating a new session for each record returned. It was a bug in the odbc driver combined with some programming errors. I don't remember the details.
But always test first before changing anything!!
 
Ad 4) You could define a password policy. Take a look to
$ORACLE_HOME/rdbms/admin/utlpwdmg.sql for an example.
When you create an account you have to give it a password. You could also force a password change by the user with a : ALTER USER <user> PASSWORD EXPIRE.
 
Ad 5) owned by which users? Depending your Oracle versions there are some users like outln and system that have table in the system tablespace.
No one else should have objects in the system tablespace.
 
Ad 6) You are using database links with connect to current_user or connected user db-links. This is no a security threat.
 
ad 7) The system account is created when you create a database. I don't understand your question. Maybe you want to audit (see Oracle audit command) system?
 
 
And don't forget to test before changing!
 
regards,
 
Ivan
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: A few security questions
« Reply #2 on: Sep 30th, 2005, 12:04am »
Quote | Modify

Thanks for the information.  I have one more question:
 
I noticed that the PUBLIC execute privilege is not revoked on the following files:
utl_file, utl_tcp, utl_http, utl_smtp.  
 
Would this be a security threat?  My DBA told me these files have to be there to let one of the applicaitons run.   Would this make sense?
 
Thanks.  
 
Thanks.
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: A few security questions
« Reply #3 on: Sep 30th, 2005, 8:34am »
Quote | Modify

Miloann,
 
Public execute privilege could be a security threat and if possible revoke execute priv from public. See
http://www.oracle.com/technology/deploy/security/oracle9i/pdf/9ir2_check list.pdf
for more information and look at
sql_injection_forms_us.pdf
for an example of how utl_http could be used in combination with a forms sql-injection problem.
Your DBA is probably right but maybe he can grant execute to the users that run the application?
 
regards,
 
Ivan
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: A few security questions
« Reply #4 on: Sep 30th, 2005, 6:10pm »
Quote | Modify

hi,
 
I would concur with Ivan,these four packages have been documented as a security risk if they are left with public execute privileges. See my [url http://www.petefinnigan.com/orasec.htm]oracle security white papers page[/url] in the checklists section, the CIS benchmark and the SANS SCORE documents both list them. The reasons that they are a risk is that potentially they allow any authenticated user even via a remote connection such as a web page to use the functions. These functions allow the writing and reading of files or networks. Data can be extracted, sent externally or files created that can be used to gain privileges. The most obvious method is SQL Injection.  
 
Definately remove the PUBLIC execute privileges and grant it back to those specific users that do need access to these packages.
 
hth
 
cheers
 
Pete
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: A few security questions
« Reply #5 on: Oct 3rd, 2005, 10:51pm »
Quote | Modify

Thanks for the info.  
 
Would like to talk about the system account management I mentioned earlier.  
 
What would be the general practice to manage the system/application accounts?  Can these accounts be used by a regular user to access the Oracle system?  
 
The reason I ask again is we have a good number of system/application accounts and I am not very comfortable if each one is used for its intended purposes.  Is there a way to control these accounts?  
 
 
Thanks again.
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: A few security questions
« Reply #6 on: Oct 4th, 2005, 9:17am »
Quote | Modify

Miloann,
 
I don't know if there are general pratices for managing system and application accounts. Maybe this can be taken into account when designing an Open Oracle Security Standard.
My best practice for system account: it is only for the dba and no one else. Give it a good password and keep it to yourself.  
You also could audit it for succesful and unsuccesful logins. I think that the system account can be locked. I'm not sure about that.
When you talk about application user do you mean schema owner? if so then only the dba should be able to login as the schema owner. Give any one else a developers database where they can login a the schema owner if they want so they can create, drop, etc objects. In these developers databases change sensitive data if needed. Developers should give the dba ddl's, dml's that the dba can implement in the test database so that end-users and developers together can test the applications. When tests are ready then the dba can apply the changes to the production system but only after a formal approval by the project management.
 
regards,
 
Ivan
Noone needs to have access to the application (= schema owner?)
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: A few security questions
« Reply #7 on: Oct 5th, 2005, 10:28pm »
Quote | Modify

Hi,
 
I would lock the SYS and SYSTEM accounts and store the passwords in a safe. Each DBA should have their own account. I would audit all SYS connections as well - see initialisation parameter audit_sys_operations. Also audit all connections successful and not to the database and review the audit trail. Also write off the audit trail to write once media. Use password management features to protect all accounts especially the DBA accounts. For application schema accounts lock them and set the failed_login_attempts to 1 and also set sessions_per_user to 1. It should not be possible to connect to a schema owner account unless a release is being done. Also ensure you audit connections to all schema accounts.  
 
Also audit for use of any system privileges especially object creation or alter privileges.
 
Basically control access to database accounts and lock those that should not be used regularly and also audit all connections/disconnections and use of system privileges.
 
hth
 
cheers
 
Pete
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: A few security questions
« Reply #8 on: Oct 14th, 2005, 4:48am »
Quote | Modify

Thanks for the info.  It all works.  Now, I ran into another questions:
 
I compared the employement records with the user account and found there are totally 250 user accounts owned by employees who are  terminated.  I showed the list to our Info Sec and here is the interesting part that they responded:
 
"We have very effective procedures to revoke Windows and Unix accounts when employees departure.  As long as we have a very tight process on that part, we are not worried about the Oracle accounts."
 
We all know disgruntled employees may use these accounts to access.  But with restrictions on the OS level, are we safe?  
 
Also, they indicated that those terminated user accounts cannot be removed but set an expiry date because some Oracle applications may still need to reference these accounts.  Is this correct?  
 
Thanks again.
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: A few security questions
« Reply #9 on: Oct 14th, 2005, 9:28am »
Quote | Modify

Miloann,
 
I don't think that a restriction on the OS level is enough. Maybe those ex-employees can use someone else OS account to log in Oracle with their old account? If possible you could lock the oracle accounts and also change their passwords (in case someone unlocks the account).  
Your question regarding applications referencing Oracle accounts : it's possible. I've seen it before in applications so I wouldn't be surprised. I don't think it is correct but sometimes the cost to redesign an application is just to high.
 
regards,
 
Ivan
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: A few security questions
« Reply #10 on: Oct 14th, 2005, 6:58pm »
Quote | Modify

Hi,
 
I think your issue would be if application auditing references the username or some other database logging does then you could have broken links between tables. this would apply if they are also talking about removing users at an application level. I would guess that maybe there are links between oracle usernames and audit in the applications?
 
I would do a few things:
 
o  - lock the accounts
o - change the passwords to impossible passwords using the values clause of alter user
o - revoke create session from the users and if possible revoke all privileges
o - use audit for login and alter user system privilege - at least
 
cheers
 
Pete
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Pete Finnigan
PeteFinnigan.com Administrator
*****




Oracle Security is easier if you design for it

   
View Profile | WWW | Email

Gender: male
Posts: 309
Re: A few security questions
« Reply #11 on: Oct 17th, 2005, 2:00am »
Quote | Modify

Something else to think about.
 
If your userids follow some sort of naming standard, what happens if a new employee joins with the same (or similar) name to a terminated employee ? Will they definately get a 'brand-new' userid, or might they get the same userid as the old employee.
 
You need a mechanism to avoid the new employee picking up the privileges of the old. Ideally you wouldn't reuse a userid and if you keep and lock the old account, it should highlight any attempted re-use (ie you'll get an error on CREATE USER). Then you can decide whether you can get a new userid, or whether you have to get your fingers dirty in the application to make sure any 'old' privileges are removed.  
 
IP Logged

Pete Finnigan (email:pete@petefinnigan.com)
Oracle Security Web site: http://www.petefinnigan.com
Forum: http://www.petefinnigan.com/forum/yabb/YaBB.cgi
Oracle security blog: http://www.petefinnigan.com/weblog/entries/index.html
Pages: 1  Reply | Notify of replies | Send Topic | Print

« Previous topic | Next topic »

Powered by YaBB 1 Gold - SP 1.4!
Forum software copyright © 2000-2004 Yet another Bulletin Board
  • PFCLScan PFCLScan

    Simply connect PFCLScan to your Oracle database and it will automatically discover the security issues that could make your Oracle database vulnerable to attack and to the potential loss of your data.

  • PFCL Obfuscate PFCLObfuscate

    PFCLObfuscate is the only tool available that can automatically add license controls to your PL/SQL code. PFCLObfuscate protects your Intellectual Property invested in your PL/SQL database code.

  • PFCLCode PFCLCode

    PFCLCode is a tool to allow you to analyse your PL/SQL code for many different types of security issues. PFCLCode gives you a detailed review and reports and includes a powerful colour syntax highlighting code editor

  • PFCLForensics PFCLForensics

    PFCLForensics is the only tool available to allow you to do a detailed live response of a breached Oracle database and to then go on and do a detailed forensic analysis of the data gathered.

  • Products We resell PFCLReselling

    PeteFinnigan.com Limited has partnered with a small number of relevant companies to resell their products where they enhance or compliment what we do

  • PFCLATK PFCLATK

    PFCLATK is a toolkit that allows detailed pre-defined policy driven audit trails for your Oracle database. The toolkit also provides for a centralised audit trail and centralised activity reporting

  • PFCLCookie PFCLCookie

    PFCLCookie is a useful tool to use to audit your websites for tracking cookies. Scan websites in a natural way using powerful browser driven scanner

  • PFCL Training PFCLTraining

    PFCLTraining is a set of expert training classes for you, aimed at teaching how to audit your own Oracle database, design audit trails, secure code in PL/SQL and secure and lock down your Oracle database.

  • PFCL Services PFCLServices

    Choose PFCLServices to add PeteFinnigan.com Ltd to your team for your Oracle Security needs. We are experts in performing detailed security audits, data security design work and policy creation

  • PFCLConsulting PFCLConsulting

    Choose PFCLConsulting to ask PeteFinnigan.com Limited to set up and use our products on your behalf

  • PFCLCustom PFCLCustom

    All of our software products can be customised at a number of levels. Choose this to see how our products can be part of your products and services

  • PFCLCloud PFCLCloud

    Private cloud, public cloud, hybrid cloud or no cloud. Learn how all of our services, trainings and products will work in the cloud

  • PFCLUserRights PFCLUserRights

    PFCLUserRights allows you to create a very detailed view of database users rights. The focus of the reports is to allow you to decide what privileges and accounts to keep and which to remove.

  • PFCLSTK PFCLSTK

    PFCLSTK is a toolkit application that allows you to provide database security easily to an existing database. PFCLSTK is a policy driven toolkit of PL/SQL that creates your security

  • PFCLSFTK PFCLSFTK

    PFCLSFTK is a toolkit that solves the problem of securing third party applications written in PL/SQL. It does this by creating a thin layer between the application and database and this traps SQL Injection attempts. This is a static firewall.

  • PFCLSEO PFCLSEO

    PFCLSEO is a web scanner based on the PFCLScan technology so that a user can easily scan a website for technical SEO issues