This is a discussion on Re: [fw-wiz] identd, revisited - Firewalls ; > ArkanoiD wrote: > So if you > do trust host users separation (and if it is compromised at root level no > method is good enough anyways), ident info can be used as well. And it is > up ...
> ArkanoiD wrote:
> So if you
> do trust host users separation (and if it is compromised at root level no
> method is good enough anyways), ident info can be used as well. And it is
> up to you what to do with it.
Marcus J. Ranum responded:
> That's the standard argument in favor of identd. And, if you shuffle
> the words around and preserve meaning it boils down to "on the
> occasions that it's useful, it'll be useful." The problem is that it's
> not - and never has been - useful enough to be useful.
It occurs to me that this discussion seems to be side-stepping the actual
utility of the identd service. Don't focus on the tragically flawed
projected uses (for example, a remote host being able to draw _any_
conclusion from the information passed back from identd). Instead think
of identd as a service for distributing log data from the server machine.
The ident information should be viewed as a blob that can only be assigned
meaning by the issuing server.
In the event that something odd happens (a local-to-the-identd-server
user account is compromised, and attacks are launched from that account),
the ident information can be provided back to the host that generated it,
at which point some possibly useful conclusion can be supported.
So, to restate: ident information is useful only to the server
that generated it in the first place, and any attempt at external
interpretation of this information is of this information is misguided.
Good identd servers are those that enforce this model, by giving out
encrypted / timestamped / authenticated blobs that can only be verified
and interpreted by the generating machine.
firewall-wizards mailing list