[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ale] identd : privacy concerns
- Subject: [ale] identd : privacy concerns
- From: mhw at wittsend.com (Michael H. Warfield)
- Date: Sat, 9 Jan 1999 22:48:28 -0500 (EST)
Jim Kinney enscribed thusly:
> I was under the opinion that identd is used to verify that the machine
> accepts mail for and individual user as well as the "problem" stuff you
> refered to. I see lots of identd lines in my logs being called from the
> mail gateway I talk to.
Identd is used to ask a remote system the user associated with a
specified socket. The original poster has that much very correct.
> James Kinney M.S.Physics jkinney at emory.edu
> Educational Technology Specialist 404-727-4734
> Department of Physics Emory University http://teller.physics.emory.edu
> On Sat, 9 Jan 1999, Joe Bayes wrote:
> > Seeing some unknown hostnames in my system logs inspired me to read up
> > on identd. As I understand it, identd allows anyone who knows the
> > local and remote ports of a TCP connection to find out the username of
> > the process which is running that connection.
> > I don't see a real use for this service, other than web sites
> > collecting email addresses to spam. RFC 1413 states that, "The use of
> > the information returned by this protocol for other than auditing is
> > strongly discouraged." Somehow I don't think the spammers feel too
> > discouraged about this.
If you make an assumption, which is strongly discouraged, that
the other system is "honest" then you can log and audit who is making
remote requests. This really can be handy. The primary user of ident
is sendmail. When mail passes from one system to the next, sendmail
calls back to the requestor to try and determine the identity of the
requesting process. It is an extremely BAD idea to rely on this information
for authentication and authorization, because you have no real assurance
that the requesting party isn't lying to you. In fact there are a number
of ident daemons out there which are deliberately designed to lie for you.
It is very handy for trouble shooting and tracing, though.
Even with "dishonest" systems, ident can be handy since you can
then track back through systems until you run into a system which is either
not supporting it (at which time you stop) or you run into a "dishonest"
system. In the later case, the rubber hose protocol then works better
than ident, but at least you have identified a target.
> > Can anyone give me a legit and necessary use of identd, or some other
> > reason why I shouldn't disable it?
Careful how you disable it. Simply turning it off will probably
work fine. Then the requestor gets rejected quickly and knows that you
are not supporting that protocol. Sometimes, it's very tempting to
"deny" rather than "reject" a connection, as can be done with lots of
filtering firewalls. This would be done by overing the ident protocol
with a deny rule. The result of that is that the request gets silently
dropped on the floor and the requestor never hears back and has to time out.
This can introduce some nasty delays in sending mail, especially with systems
which are not spooling mail before attempting initial delivery.
I'm not aware of any spammers who are going to the level of trouble
to try and use ident to identify potential E-Mail addresses. It's much
more cute to embed "ftp://foo.spammer.slim/pub/stupid1pixel.gif" in the
corner of a page and get your browser to do an anon ftp login to their
site and get your browser to cough up what it has for your E-Mail address.
They can do that without a lot of system programming skills or even any
real serious access on the server. To fake out an ident process, they
have to be the administrator of the system where the web server is (the
ftp server could be some mickey mouse WinBlows box they have set up just
for that purpose). The ident trick requires root control of the web server,
while the embedded ftp trick only requires a host page and an ftp server
somewhere else. The hit ratio for the ftp trick is better too.
Spammers can get as good or better address trolling just by doing
RedEx's through mail list archives, web pages, and general E-Mail traffic.
They can get better and larger lists with good hit ratios with little
efforted invested. It's not much worse that doing an over glorified
"grep" on any pages or content encountered on the web.
Just subscribe to any reasonable mailing list and feed the entire
list, content and all into a perl regex filter like this:
That probably has a few bugs in it but the intent is to scan a
text for a string with some character set valid for a local name, followed
by an at sign, "@", followed by some close approximation of a fully
qualified domain name. That filter above should even limited the hits
to those ending in 2 or 3 alpha characters following a dot which should
give you good filtering on your primary TLDs (Top Level Domains) including
the 2 letter geographical domains.
If you want to REALLY get fancy, the regex can even automagically
filter out the silly ass "foo-nospam" into "foo" and catch the dummies
who think that adding "-nospam" or "-removethis" or any other common pattern
is going to make it less likely that they get on lists. BTW... That
also applies to putting that into your browser address as well. The filters
on the ftp logs can filter that out too. No help there.
Ident is the least of your worries there!
> > thanks,
> > --joe
Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com
(The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!