Disabling UnSecure IP Services 1

[itsp1965]

Folks I have been provided an audit checklist for securing our Linux boxes and one of the requests is to ensure that the following IP services are disabled

CHARGEN, DAYTIME, DISCARD, ECHO, FINGER, SYSTAT, WHO, NETSTAT

Now if I am not mistaken, aren't these disabled by default? (I am working with RHEL3 here). How can I ensure that they cannot be enabled? I have checked /etc/services and they exist as available services, but I want to ensure that they are not activated in any way. Thanks.

 

[itsp1965]

Okay, I figured it out by using the chkconfig command. Would it be prudent though to delete the services altogether
ex) chkconfig --del chargen (for instance)

 

[thedaver]

OK, let's review this from a requirements standpoint.

The auditor is probably reading from a punch list of things that represent "risks". You've done the right thing to disable those services on startup through 'chkconfig'. However, unless you expressly 1) shutoff those services if they WERE running or 2) rebooted, then those services are most likely still running. Deal with that first so you can be honest with the auditor.

Next, the security controls and audit are probably driven by a POLICY that describes why/how/to-what-degree you are required to secure your system.

Normally, those services that represent risks are the services offered on ports 1-1023, which are largely controlled through the root user. If the security policy is effective in controlling 'root' and 'sudo su' and 'su -' access then you have gone a long way towards maintaining your secure position.

The specific services you noted are *generally* of little or no value in most environments. You could optionally kill them off through removal via your package manager. It would not be effective to remove their startup scripts in /etc/init.d since those scripts are essentially just shells to the *real* daemons/programs. Again, to remove them, use your package manager.

I WOULD ARGUE, however, that if you find yourself removing services to be "compliant" with a security policy, then you should actually be removing all non-essential services from the machine. This would represent a larger list than the few oldies-but-goodies you listed.

My advice (yes, it's free advice) is that you first return to the audit/security people with confirmation that you have met the stated criteria of the audit through the first steps, and THEN you should press them to get real clarity on what "securing the machine" means.

Again, neither removal from the 'chkconfig' registry nor deleting the /etc/init.d script for 'fingerd' (example) is going to ensure that 'fingerd' cannot or will not be restarted somehow. Removal is required.

Also note, that with 'root' privs to restart 'fingerd', you would also have the required privs to re-install 'fingerd' from a package - this is a facet of security that I believe eludes a number of audit personnel. Further, you could also recompile from source if you've left automake/compiler support on the machine.

Ultimately, a real security solution looks at hardening the system, appropriate access controls, removal of unnecessary services, understanding the risks of the remaining services, controls around package management, and the use of tools like tripwire and chkrootkit to stay vigilant for unexpected changes. And then there's firewalls, selinux, resource limits, separation of duties, ......



Good luck!
D.

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[piti]

as i do agree with thedaver, maybe the audit was just about to edit the /etc/inetd.conf and disable what was mentioned ...

 

[itsp1965]

Thanks guys, since inetd.conf hasn't been used since RH6.2 (apparently -- since I was looking for it), I verified that it was indeed disabled via the chkconfig command (this it the default behavior in RHEL 3). Now the checklist does not indicate that the service be removed just disabled. I will need to back to the auditors and see what they really mean by all this.

 

[thedaver]

RH EL is going to be using xinetd, xinetd.conf and xinetd.d for the new services configuration files.

Good luck w/the auditors and security ppl.

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/