Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 873
  • Last Modified:

Security Audit on Linux Server

It has been recommended to me to have a security audit performed on a Linux Server that is being hosted an outside hosting company. This server is running Apache, Tomcat, & Oracle. Can you please provide me with a checklist of things to look for. Is it worth hiring an outside company to perform this security audit for me? If so, do you have any recommendations.
  • 2
1 Solution

I would strongly recommend nessus:


Nessus scans machines for vulnrerbilitys and will report its finding to you in a report
While nessus is a good tool, you will also want to investigate other tools as well such as NMAP. You may wish to also check the file permissions in the trees, and other issues, which some distro's have great tools for. For example Mandriva has "MSEC", etc..

If you can provide more information I can better direct you. Please provide the output of these commands:

uname -a

If you are using RedHat, then

cat /etc/redhat-release

If you are using another version of Linux, say SuSe or whatever, you can find your distro with

ls /etc/*yourosname*


Then cat that file and send over the version information. In many cases we can just set you up with a find statement that looks at the permissions.

Mostly you will have to look at versions of software such as Apache, Oracle, SSH, and other system deamons. If it's too far behind the times you might be in trouble.

If you have nmap installed please post the output of 'nmap localhost' as well.

Bear in mind that if the hosting is done by an outside hosting company, typically they are responsible for security on the host, and should data be comprimised then you would have legal recourse against the provider for not protecting your data.

For what purpose was the audit recommended? Is there some suggestion that security was lax? Do you have any evidence to compel you to audit?


~K Black~
scott_m_rubyAuthor Commented:
I have 2 servers with different versions of Linux:

uname -a:   "Linux  2.4.20-18.8smp #1 SMP Thu May 29 07:20:32 EDT 2003 i686 i686 i386 GNU/Linux"
                  "Linux  2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:08:39 EDT 2005 i686 i686 i386 GNU/Linux"

cat /etc/redhat-release:  "Red Hat Linux release 8.0 (Psyche)"
                                     "Fedora Core release 4 (Stentz)"  

nmap localhost:

"Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on localhost.localdomain (
(The 1593 ports scanned but not shown below are in state: closed)
Port       State       Service
21/tcp     open        ftp
22/tcp     open        ssh
25/tcp     open        smtp
111/tcp    open        sunrpc
443/tcp    open        https
1521/tcp   open        oracle
8009/tcp   open        ajp13
8080/tcp   open        http-proxy

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second"

"Starting Nmap 4.03 ( http://www.insecure.org/nmap/ ) at 2006-06-02 11:50 CDT
Interesting ports on localhost.localdomain (
(The 1663 ports scanned but not shown below are in state: closed)
21/tcp    open  ftp
22/tcp    open  ssh
25/tcp    open  smtp
111/tcp   open  rpcbind
199/tcp   open  smux
443/tcp   open  https
1521/tcp  open  oracle
8000/tcp  open  http-alt
8009/tcp  open  ajp13
8080/tcp  open  http-proxy
32771/tcp open  sometimes-rpc5

Nmap finished: 1 IP address (1 host up) scanned in 0.359 seconds"  
Okay I'll just give you the first things I notice right off the top. Firstly, the Redhat box is version 8, and has a behind the times kernel. This will make the box an easy victim for exploits which have since been patched. I strongly suggest you look at using up2date or similar tool to make sure that the system's packages are recent, as well as updating the kernel.

Next I notice the boxes are running standard FTP. Were I an attacker, that's where I'd begin. Since standard FTP is sending information in clear text, a man in the middle attack would be very easy. All that an attacker would have to do is use Ethereal or TCPDump, and trap data transmissions moving across the wire to that system on port 21, and before long they could capture log in data. Not to mention the payload of whatever you are sending or receiving. Granted you'ld have to have some kind of data that has a "paydirt" feel like credit card data or similar, but if the motive exists...the means is there.

Standard FTP has long been abandoned, and you/they should be using SSH for SFTP. This sends and receives data in a secure fashion using encryption, and server side fingerprinting called 'keys'. Since these ports and services appear enabled on the servers, there is not any good excuse to still have standard FTP running.

Also, I notice the systems are running SunRPC ports. RPC, or remote procedure controls, are *extremely* dangerous. It was originally designed to control Sun based servers within a friendly network, so that admins could remotely issue commands to the boxes, and even do system intensive work remotely. This is almost NEVER a good thing. If these services ARE in fact being exported (and it's not just some other service using port 111) then there's a good chance they could be perverted to work against the server...

The Fedora box is probably a lot less of a victim at first peek, but in either case it's clear you were given good advice. An independent security audit is expensive, typically I charge a minimum of a couple of thousand for this. The reason is that the entire service set of the system must be examined. What services are running, what versions of those services, right down to the nuts and bolts of the system, including the permissions, and determining if it's already been comprimised.

Looking for rootkits : http://en.wikipedia.org/wiki/Rootkit
Looking at rouge scripting. Examining software versions for older or susceptible versions such as SSH exploits, kernel hacks, deep zone shell code, and so on.

Probably at this point your best bet is to confront the hosting provider with your new found knowledge, and insist they tighten the belt substantially, or switch. It's possible they are aware of everything I have mentioned and have legitimate explainations for this. However, make no mistake about it, it's not a question of IF but of WHEN.

This is the tip of the iceberg, a full audit is much much more intensive...

High regards,

~K Black
If Linux were my God, my religion would be Slackware!

Featured Post

Veeam Disaster Recovery in Microsoft Azure

Veeam PN for Microsoft Azure is a FREE solution designed to simplify and automate the setup of a DR site in Microsoft Azure using lightweight software-defined networking. It reduces the complexity of VPN deployments and is designed for businesses of ALL sizes.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now