HP OSMS white paper: Security of Open Source Middleware Stacks

• Prohibit shared accounts and generic account names, which defeat
non-repudiation.
— Lost knowledge of exactly who is using an account prevents
accountability from being a deterrent.
— Accounts such as tester, guest, and admin defeat
non-repudiation, and make user account names easy to guess.
• Log failed login attempts.
Auditing the logs alerts you to password-guessing attack activity.
• Consider using certificate-based authentication.
This type of authentication operates just like passwords and provides
stronger security through encryption.
Configuration tasks Actively clean up user accounts.
Remove accounts that are dormant or belong to ex-employees and
those that do not belong to known users.
•
• Do not allow high-risk services to run in privileged mode.
A server might need considerable privileges, but it does not need to
run as root. By creating a special account for exposed servers, you
limits the damage an intruder can accomplish by compromising the
exposed service.
The Apache Web server needs access to many potentially vulnerable modules, CGI
scripts, and Web applications. This need establishes Apache as a target of attackers.
Therefore, you should not run the Apache process with the root account or else a
successful attacker can also gain root privilege. Instead, run Apache with the www-data
account and give this account ownership of the minimum resources Apache requires to
operate. Put simply, it is better for an intruder have control of the www-data account
than to have control of the root account.
• Deter fingerprinting, which is the remote identification of systems.
Do not let network-available services respond by giving away
information that can identify them in any way. This includes their
version, name, or other information.
Turn off, or otherwise prevent, any error or debugging messages
from being visible remotely.
The JBoss application server can post errors to the Web interface. Although this might
be helpful for debugging purposes, it also gives attackers a view of the inner workings
of the JBoss server and provides sensitive information, such as version, build numbers,
and error messages that can help guide an attack.
For more information, see the JBoss Web site at:
http://www.jboss.org
• When possible, change the default network ports for services.
You cannot change ports for services that require the use of a standard
port. Although, if you have to connect remotely, try to use SSH to an
unexpected port of your own choosing, such as 10022 instead of to
port 22. Port scanners might not correctly detect the running service
on nonstandard ports, especially if the service has been limited to
suppress fingerprinting information. This technique can deter
attackers, especially automatic scanning engines that expect services
on standard ports, by adding one more layer of security.
• Remove risky network services (Telnet, RSH, NFS, FTP, and others).
Some services are notoriously insecure due to repeated flaws. Other
services were designed under the assumption that they would be
18