Why do we still use IDENTD?

Wakko Warner asks: "So anyway, I was on IRC the other day (as I am often wont to do), and, as I was being banned from the network for not running 'identd', I thought to myself: 'Why do we still use this???' Can anyone come up with a valid reason why, in 2002, ident is still considered by some people to be a necessary component of the Internet? Most people use Windows for everything, and Windows has no identity services. Most UNIX folks I know disable it for security reasons. So, why do people still insist we run it in order to connect to their network? Is it still 1993 in some part of the world?"

Comments

Plenty of identd servers for Win32

[aderuwe]

There are plenty of identd servers for Win32:

http://identd.sourceforge.net/
http://freeware.teledanmark.no/identd/
http://sourceforge.net/projects/winidentd/
http://identd.dyndns.org/identd/

But on the other hand, here are some reasons why your question is valid...

Re:Plenty of identd servers for Win32

[aderuwe]

Heh, that last link even has some funny source code I didn't notice at first glance. ;)

Re:Plenty of identd servers for Win32

[Wakko Warner]

Now, which do you think is the more likely scenario: All the l-users here that have never run an IRC server and are taking out of their ass know best, or that hundreds of experienced server and network ops know what they're doing and require identd for a reason?

I've run several IRC servers since 1996. I am an "experienced server and network op", and I still can't figure it out. Speaking as an admin, I can assure you that ident buys me absolutely nothing in terms of dealing with problematic users. Every single one of them has spoofed a valid ident response, either by changing their "Username" value in mIRC, or by running a randomizing ident server. The commonly-held belief among IRC admins that ident provides security and some sort of audit trail is unquestionably false.

I turned off ident checking on my servers a few months ago, and encourage others I know to do the same.

- A.P.

Pretty Simple

[SmallFurryCreature]

First of ident is not insecure by itself. Some implementations had buffer overflow problems, but then wich server software hasn't. It can also provide login information like the username but this depends on the setup. For correct working, IRC related, it just needs to return a string on query.

So why? IRC is well known for countless attacks against the servers and the users of it. It really seems to bring out the worst in a large group of people who, perhaps encouraged by anonymity(?), feel they can do anything to make other peoples use of the service a hassle.

So how to defend against it? Knowing who a user is is the easiest defence. You can then ban that person from entering youre chatroom/network. There are a couple of pieces of information that are known when you use IRC.

1. Youre nick. Obviously needs to be there but can be easily randomly changed or be changed to the nicks of other people. Useless for identification therefore. Ban on nick is useless except to stop unwanted nicknames.
2. Youre IP/hostname. Not really unique, think proxy situations and for some people extremely easy to change. Modem users and users of shell accounts. Ban on IP doesn't work since it could also affect a large group of innocent users who use the same network.
3. Ident. This is an extra service run on port 113 it reports on query a string containing data corresponding to user information. In fact all you can be really certain of is that if it runs it will return something when you connect to it. Mine for instance always responds the same info. It can also be setup to return a random string each time. Pretty useless therefore as well.

So why require ident to be running? Can't it be as easily changed as the nick? Yes it can, on certain setups. However if you are using/abusing a shell account then the Ident service should be fixed by the admin. It makes therefore the misuse of a certain kinda setup harder (University accounts). Shell accounts are popular for abuse since you are using someone elses IP for youre abuse.

Other posts have indicated that there are plenty of Ident servers for windows around. Saying just because windows does not support something it is obsolete is stupid. There are plenty of things on windows you need third party apps for.

Perhaps the real problem with this question is that to many people feel they have a right to use/abuse a service run by someone else. IRC is a free service run by people who out of their kindness of their hearts run one of the most attacked services on the net. If they then require you to run a tiny little program to make their live easier then so be it. Don't like the rules? Don't use the service. Think you can do better? Run youre own.

Re:Pretty Simple

[sql*kitten]

Perhaps the real problem with this question is that to many people feel they have a right to use/abuse a service run by someone else. IRC is a free service run by people who out of their kindness of their hearts run one of the most attacked services on the net. If they then require you to run a tiny little program to make their live easier then so be it.

But does it make their lives easier? Consider: Unix reserves ports up to 1024 for the superuser. The theory was always that you could trust these ports on a remote host, if you trusted the sysadmin, because no ordinary user could bind a process to them. If the sysadmin was an employee of a university or a major corporation, then it was quite reasonable to do so. Barring man-in-the-middle attacks, this system worked quite well. At the time this convention was created, it was considered highly unlikely that you could buy your own Unix host for under $500! You could trust the owners of the machine because machines were expensive, and the owners would take adequate action to ensure that only legitimate users had accounts. The convention also allowed the designers of TCP/IP to cut corners; unlike DECnet they only needed to route by port and IP address, not by the username/process name of the source and destination processes. (That's a seperate rant of mine, how brain-dead the designers of TCP/IP were, and how DECnet is infinitely superior).

Nowadays, identd is useless for confirming the identity of a remote user, since you cannot trust the sysadmin of a remote host any more than you can trust an ordinary user, because in the Linux world, they are most likely one and the same.

The logical successor to identd is PKI, but no-one's quite sure how to make that work seamlessly yet.

Re:Pretty Simple

[Wakko Warner]

First of ident is not insecure by itself. Some implementations had buffer overflow problems, but then wich server software hasn't. It can also provide login information like the username but this depends on the setup. For correct working, IRC related, it just needs to return a string on query.

Not true. The real ident servers need to run as root (since they're running on a low port), or if you want to be fancy, they can be started by root and assume another (perhaps jailed) user's identity. Let's assume they all running as root, since I've not seen one that doesn't do so. They need to access /etc/passwd (or the NIS equivalent) as well. Some day or another, someone will figure out a way to exploit the most common version of the ident server(s). It's happened before, it'll happen again.

I tend to treat every service I run on my machines as exploitable. To this end, I disable as many as possible, and, if I have to run a service, I make sure I keep up with it from a security standpoint. Running ident is more work for me, for no real reason.

That someone requires I run a useless service like identd in order to connect to their network has always bugged me. In this day and age, when ident responses are faked far more often than they aren't (EVERY Windows IRC client fakes ident!!), what's the point of opening up a low port and exposing my systems to even more abuse?

So why require ident to be running? Can't it be as easily changed as the nick? Yes it can, on certain setups.

On just about every setup, you mean.

However if you are using/abusing a shell account then the Ident service should be fixed by the admin. It makes therefore the misuse of a certain kinda setup harder (University accounts).

Very few people use their university shell accounts to IRC these days.

Shell accounts are popular for abuse since you are using someone elses IP for youre abuse.

So are Wingate hosts, but there are other ways of dealing with that kind of abuse, as well. If someone's fucking with my server from a shell account (or from anywhere else), banning that hostname or IP range is more than enough.

Other posts have indicated that there are plenty of Ident servers for windows around. Saying just because windows does not support something it is obsolete is stupid. There are plenty of things on windows you need third party apps for.

Yes, and others have noted that "ident" is built into most Windows IRC clients. In nearly all cases, on Windows, ident is faked; I can type whatever I want into the "Username" box in mIRC.

- A.P.

Why identd is used

[0x0d0a]

The reason identd is required is pretty straightforward, actually.

Say I get on an IRC server and start abusing it. It's pretty easy to just ban my IP (or in extreme cases, up to my class B if dynamic IPs are in use and there's no better solution). So single-user machines are pretty easy to handle.

A not-unreasonable people still use public access machines, however. And you can't just ban their IPs without potentially screwing a lot of people -- if I ban MITs or CMU's public access UNIX boxes, I'm going to hurt a lot of people to block one baddie. However, these machines can be trusted to run a legtimate identd, so I can say "Don't block *everyone* on these machines...just this one user".

Granted, the utility value of identd is less now that Windows machines and single-user UNIX machines are dominant, but it still does solve a nasty problem sometimes.

However, even given that identd helps, I don't see why it's *required*. You can just say "if the remote host isn't running identd, just ban the entire IP if we get a baddie on that machine".