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.
 |
|
Need Oracle training?
- Get Oracle training from a practicing Oracle
expert
- Get custom training designed to
fit your needs
- Conveniently offered at your
workplace, anywhere in the USA
BC Oracle training offers some of the
USA's most respected Oracle experts and authors. Why spend
thousands on cookie cutter Oracle classes when you can have the
personalized attention of a real Oracle
guru? Just call now: |
|
