0

An internal server in the company I work for has been compromised and I would like to harden CentOS machines in the organization in order to avoid any future incidents so I've been reading about securing your CentOS machine and I've came across all kinds of ways to secure your OS.

We're not using SELinux or IPtables within the domain.

One thing I plan on doing is to limit access to servers within the domain to specific services by using TCP wrappers (editing /etc/hosts.allow/ and hosts.deny).

From CentOS official documentation site:

Using TCP Wrappers

TCP wrappers can provide a quick and easy method for controlling access to applications linked to them. Examples of TCP Wrapper aware applications are sshd, and portmap. A restrictive example is below. This example blocks everything but ssh.

echo "ALL:ALL" >> /etc/hosts.deny

echo "sshd:ALL" >> /etc/hosts.allow

My question is:

I need the server to be able to serve requests on ports:

1099 (Java RMI) 
5666 (NRPE)
22 (SSH)

Java RMI is started manually and not by a daemon and it is specified correctly in /etc/services:

[root@srv4 scripts]# grep 1099 /etc/services
rmiregistry 1099/tcp            # RMI Registry

In addition, NRPE is configured to work under xinetd rather than a manual daemon

So how would my hosts.allow lines would look like?

  • Have you tried running Java RMI through xinetd? – Gmck Dec 22 '15 at 13:58
  • No, i'm not sure how to do it and i'm not sure this solution will be accepted as there's a baseline of how to start Java RMI across all company's products. – Itai Ganot Dec 22 '15 at 14:42
  • If you cannot use xinetd, and you do not have log analysis of some kind already installed and, try something like OSSEC http://ossec.github.io/ which has active blocking features if suspicious activity is detected. – Gmck Dec 22 '15 at 16:39
1

The CentOS 5 docs have a good write up for for xinetd*. Something like

hosts.allow

xinetd: .example.com

hosts.deny

xinetd: ALL

should allow all hosts in example.com and deny access to everything else for processes controlled by xinetd. Order is important, the files are scanned in the order allow, deny and the first match wins.

A quick look at the output of ldd /usr/bin/java shows that java isn't libwrap aware so you can't use tcpwrappers directly with it. Perhaps wrapping it in xinetd will work.

You should definitely consider internal firewalls and SELinux too as these will help limit lateral movement after a compromise.

*There may be one for later versions too but it's unlikely to be much different

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.