Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 
 

World's most widely-read security expert speaks on Oracle server security

Oracle Tips by Burleson Consulting
Don Burleson


Adam Haeder, Vice President of the Association for Information Management (AIM) recently commented about security for Oracle servers.  Haeder is the author of the bestselling Conducting the UNIX Job Interview and Conducting the Network Administrator Job Interview books by Rampant TechPress.

 
You can classify an attack into one of these categories:
 
1- Intrusion - someone is able to log in remotely to a system that is not theirs, essentially giving them the privileges of either a regular user or a super user. An example of this would be if someone knew your password to a Unix system, and that system allowed ssh connections from the internet, that person could log in as you. Another example would be a service that has a remotely exploitable vulnerability. Once this vulnerability is identified, exploits can be written that take advantage of this. The exploit is usually a buffer overflow, which when executed on Unix services will normally crash the affected service and give a shell prompt to the executer of the exploit. For more information about buffer overflows, see the article "Smashing the Stack for Fun and Profit" at

http://www.phrack.org/show.php?p=49&a=14.

 
2 - Information harvesting - without actually 'breaking into' a system, some remotely accessible programs can be exploited to return information that was not meant to be available. An example of this was the University of Texas a couple of years ago. They had a web based systems that students could use to check grades or something, and someone figured out that if you passed the right query-string arguments to one of the cgi programs, it would return complete information about a student, including address and SSN.

3 - Denial of Service (DoS) - someone sends so much traffic to a system that it is literally overloaded and unable to respond to any more requests. The extension of this is Distributed Denial of Service, which is many systems across the internet working together to DoS another server.

What to do about each of these?

1 - Don't expose yourself. If you manage a system that is publicly accessible to the outside world (via the internet) you had better know exactly what is running on that box and what services are listening for requests. You have a web server that hosts a cgi program which makes local calls to a database running on the same box. Does that database need to support remote access? No! Don't allow it. My web servers show 2 faces to the world, tcp port 80 and tcp port 443, one for http and one for https.  That's it. If I need remote access to them, I go in through our vpn. So that means that my only potential source of external intrusion is through the apache web server.

2 - Patch your system. The VAST majority of exploits are taking advantage of vulnerabilities that have been known for months (sometimes years). Remember the SQL slammer worm? That hit 6 month after Microsoft issued a patch that prevented it.
 
Laziness is by far the biggest culprit when it comes to remote exploits. www.fbi.gov got cracked? They probably had a lazy admin that didn't pay attention to the latest vulnerability report for the web server software he was running. Serves them right.

 
1 - Audit, audit, audit. Know EXACTLY what processes should be running on your box. Know EXACTLY what ports should be open. Know EXACTLY how the disk usage should grow and change. Use a file system integrity checker like Tripwire to verify that critical system files have not been changed.

2 - More auditing. Make sure you don't store sensitive data on a publicly accessible machine. Take CC numbers for your online store? Put a 2nd network card in your web server and connect the db server to it on a
private IP network. Better yet, use something weird like IPX or NetBEUI to connect those 2 machines. That will foil 99% of the script kiddies out there who have probably never even heard of those protocols.

3 - This one is harder. Standard DoS attacks you can stop because you can tell where they're coming from (single source). You contact your upstream ISP and they block that IP at their routers. Then they work with you to trace back the source and contact that ISP. Distributed DoS is tougher because you have so many machines hitting you at once. Again, a good relationship with your upstream ISP is crucial here, as you'll need their
help in working through it.

Having said all of that, let me end with: you WILL get broken into. It's going to happen. The sysadmins job is to minimize the chances that it will happen (don't be the low-hanging fruit) and have a plan in place for when it does. Fort Knox COULD get broken into. But it would take some massive resources to do it. Don't make yourself the easy target.

Here is a scenario in which one of my webservers could be compromised: Let's say that a new vulnerability was discovered in the Apache web server last night. There is already an exploit available and no patch yet for Apache. The exploit utilizes a buffer overflow attack, allowing the attacker to crash the apache web server and get a shell on my webserver. What do I do?
 
  • I know immediately that this happened, because we monitor all processes on all servers in realtime. As soon as the apache webserver goes down, the IT staff is notified.
     
  • They log in over the vpn and assess the situation. When the attack is discovered (usually through 'something strange' in the log files) the system will immediately be taken offline and a backup system brought up. We have redundant servers in place for all of our publicly accessible systems.
     
  • This system would still be vulnerable, because it's running the same version of Apache, but now we know what to look for. We get the IP of the attacker from the log files of the old system and firewall them off. This is not a permanent solution, but it can slow things down. We go back through the newsgroups and mailing lists (like Bugtraq and SecurityFocus) to look for any news of a new vulnerability. Once details are found, we can assess what the solution will be to fix the vulnerability. With open source software, we have the ability to fix the code directly as soon as
    the fix is known, without waiting for an official vendor package of Apache.
     
So this scenario requires things to happen in a specific order:

 
  • A vulnerability is discovered in a remotely-accessible service
     
  • An exploit is written, tested, and distributed for this vulnerability before a patch is available
     
  • The exploit is used against a vulnerable system


How often does it happen this way? NEVER. Here is the real scenario
 
  • A vulnerability is discovered in a remotely-accessible service, usually by a testing lab like At Stake or EEye Digital Security. The 'juveniles' sitting at home running exploits are NOT the ones that write the exploit, they just download the code, compile it, and run it. Hence the term 'script kiddie'. They have no idea what the exploit actually does and would have no ability to write one themselves.
     
  • The vulnerability is made known to the vendor, giving them a chance to respond and start working on a patch.
     
  • If the vendor responds in a timely manner, the vulnerability is not made public until the patch is available. If they do not respond in a timely manner, the testing lab will eventually make the vulnerability (but not any exploit code) known to the public. This has only happened a few times and the vendor was always Microsoft.
     
  • The vendor announces the vulnerability and the patch at the same time.
     
  • Good sysadmins find out immediately about the patch and put it in place on their test systems, making sure it doesn't break anything else. Bad sysadmins either don't hear about it or are 'too busy' to do it right away.
     
  • Time passes. The longer the vulnerability exists, the more chance that someone has written exploit code for it. The lazy sysadmins get cracked, the good ones don't.

 



 

 

��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster
 
 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational