Service Guard and ident

[Naveej.K.A]

Hello,

I have been challenged by the Network Security team to disable ident services on some of my cluster servers. I have clusterA running SG 11.17 on HP-UX 11.23 and clusterB running SG 11.16 on HP-UX 11.11. Both the clusters have ident enabled in /etc/inetd.conf.

What I would like to know is, what is the best practice of using authentication. Is it
1) to enable ident as recommended by HP?
2) or to disable ident and use the additional options documented in "Securing Service Guard" - which is extra options to hacl-probe and hacl-cfg stream and the extra patches for COM & sendmail.

I would also like to know, why HP recommends using ident, when a network security experts just goes mad when he sees the ident service running?

Cheers!
-Naveej

[Stephen Doud]

The "Securing Serviceguard" document at http://docs.hp.com/en/5874/securingserviceguard_nov2005.pdf
states this on page 7:

4.4. Is identd a security threat?
Security experts sometimes recommend that identd be disabled, because it gives out information about users on that computer. The information given out is "login name" (as recorded in /etc/passwd, or whatever local technology is replacing /etc/passwd). If two login names share the same UID, the name reported is usually, but not always the first one in /etc/passwd. Given the nature of the trust required inside the firewall, the Serviceguard development team sees no compromise to security by enabling identd to identify users who hold TCP connections to other computers.

Serviceguard does not require the external firewall to pass any identd traffic, either incoming or outgoing. For sites which do not wish to expose to the external internet the limited information which identd provides, we recommend blocking, at the external firewall, all incoming packets destined for auth on any protected node (port 113).

4.5. Stronger alternatives to identd
Stronger authentication mechanisms than identd exist, based on credentials
which must be configured and, depending on the level of security required,
themselves certified by contact with a trusted third party. Such measures
require significant administrative load at configuration and maintenance time.
Serviceguard has selected the use of identd as more appropriate for our
customers. Serviceguard is evaluating the future potential to supply an
option to use stronger security for those customers who seek to use
Serviceguard in a more hostile context.

--- end quote ---

So, the threat level is related to the safety of the network on which the cluster is placed. HP does not recommend disabling Serviceguards' dependency on identd. However the administator has the choice.

[Todd McDaniel_1]

At my old company, (ie large telecom firm), our standard was to disable ident and have a more secure version of sendmail and other configured items to make our services more secure.

I have never had a box where we allowed ident to run. It was always disabled.

[Naveej.K.A]

Thanks Stephen, Thanks Tod.

I had read that document and found it confusing with regards to the usage of identd. I will try to clarify my questions again.

1) If identd is disabled, how does the nodes authenticate? Is it using cmclnodelist? or is it becuase of the "-i" option to cmclconfd and cmmod in following lines in /etc/inetd.conf?

hacl-cfg stream tcp nowait root /usr/lbin/cmclconfd cmclconfd -c -i
hacl-probe stream tcp nowait root /opt/cmom/lbin/cmomd /opt/cmom/lbin/cmomd -i -f /var/opt/cmom/cmomd.log -r /var/opt/cmom

what does "-i" option do?

2)Reading Section 4.6 of the document,

"4.6. Weaker alternatives to identd
Serviceguard strongly recommends the use of identd. However, a weaker alternative, not requiring identd, exists which is suitable for installations where all users are trusted not to be attempting hostile activity. Please see the Serviceguard manual and patch documentation for details."

Does this mean that you would be better off using identd than disabling it??

I don't have a test server to play around.

Cheers!!
-Naveej

[John Bigg · Accepted solution]

Let me try and explain.

There are no real alternatives to using identd right now. The alternative is to disable the use of identd and run the risk since you are not checking the authenticity of the connection then.

What identd allows us to do is to verify that the sender of the connection is who he says he is.

Security experts may abstractly say that this is useless since just like a connection can be spoofed the response from identd can be spoofed too. This is true when you do not know anything about the node the connection comes from but this is not true within a cluster. Within a cluster we know we can trust identd since we set it up and it runs on a trusted port which can only be accessed by a root process.

So, within a cluster we can trust what identd tells us so this should be used. If you can completely trust all users within your cluster then you do not need this extra level of security and identd can be disabled by using the -i option within inetd.conf on the cmomd and cmclconfd daemons.

When it is explained what Serviceguard uses identd for a security expert should understand. Unfortunately many so called security experts do not understand the real issues with identd and have just got it into their heads that this is wrong and should be disabled in all circumstances. This is simply not true.

At the end of the day this is up to you. Hopefully this explanation will allow you to make a balanced judgement. Only you know what level of trust exists within your cluster and what level of security is appropriate. We cannot do this for you.

[John Bigg]

One point I neglected to explain clearly enough is that if you have identd enabled extra security checking is performed. If identd is disabled, Serviceguard does not do something else instead, it simply does less. This is why I was saying there is no real alternative.

The alternative is doing less, not doing something else instead.

[Matti_Kurkela]

With ServiceGuard, I'd recommend keeping ident enabled, but using inetd.sec and/or the (optional but free) ipfilter package to allow access to ident service for localhost and cluster nodes only.

If you use ipfilter or another firewall to block ident requests, you should make sure the filter/firewall sends an appropriate "connection refused" response (TCP Reset or ICMP Port-Unreachable).

Just dropping the packets incoming to the ident port will cause the requesting host to retry the ident request several times, as per standard TCP behaviour.

This causes the following sequence of events:
1.) host A connects to host B for whatever reason
2.) host B accepts the connection but places it on hold
3.) host B sends an ident request to host A for the connection established in step 2
4.) host A (or firewall in between hosts) drops the ident request, causing host B to retry. Meanwhile the connection established in step 2 approaches a time-out condition too.
5.) host B times out the ident request. At this time the original connection (step 2) has also timed out
6.) host A reports failure of the original connection because of a time-out condition.

I've seen this in action several times. It's a bit tricky to troubleshoot, because the error logs usually won't give you a good clue of what's happening.

To prevent this, ident requests should not be simply dropped in a firewall, but instead rejected with a proper response. When the host that sent the ident request receives an explicit proof that ident service is not available, it will not retry.

The application that sent the ident request can then decide whether to service the request without the ident response data or to reject it. If the application chooses to reject the request at this point, the error message or connection log entry will usually be more meaningful in this situation.

If the firewall administrator is afraid that someone malicious might use the "connection refused" responses as a part of a denial-of-service attack, the firewall should be configured to limit the sending rate of rejection responses to a tolerable level.

MK

[Naveej.K.A]

Thanks John and Matti,

Very very Informative!!

What I think I would ultimately do is keep identd enabled and restrict it just to the cluster node using /var/adm/inetd.sec.

-Cheers!
Naveej