Subject: Re: identd problem
To: Jukka Marin <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 01/26/2001 14:01:51
[ On Friday, January 26, 2001 at 11:24:47 (+0200), Jukka Marin wrote: ]
> Subject: identd problem
> A company using NetBSD on their servers installed a new firewall. This
> firewall blocks all identd queries (it just eats the packets). Now, when
> someone tries to telnet/ftp/smtp into a NetBSD box through the firewall,
> NetBSD sends out an identd query, gets no response, sends out another
> packet in 5 seconds, gets no response, and proceeds to login after a 10
> second (total) delay.
Telnet? Ftp? Through the firewall? Not so good! Kid's toys do TCP
hijacking these days and unless they are using secure one-time passwords
or something similar then they've probably already been compromised by a
sniffer, not to mention the possibility of typing yet another password
(eg. to "su") or some other sensitive information over an unencrypted
channel. Hopefully you've warned them of the fatal mistake they could
be making here!
> What should the firewall do? Is it ok to just drop the packets or should
> some ICMP packet (or something) be returned? I was told that the firewall
> can not be configured to do this.
Ideally the firewall should pass IDENT queries through both ways and the
servers on the inside should be configured to use encrypted IDENT.
What's silly here is that their firewall seems to be blocking IDENT in
the wrong way.....
If absolutely necessary (i.e. if they've got some reason to use
unencrypted IDENT on the inside and/or they can't turn off identd on
some other box which would reveal inside secrets if allowed to answer to
the outside) then the firewall should return TCP reset (RST) packets for
IDENT connections in-bound towards the severs, but allow the servers on
the inside to make IDENT queries back out to the outsie world.
If their firewall cannot be configured to return RST packets when a
receiving a SYN (or SYN-ACK) packet then it's not a real firewall and
they should probably not be using it. IP-Filter in NetBSD can do this
trivially -- for example to make a remote client think there's no
telnetd listening on the inside hosts:
block return-rst in on <outside-IF> log quick proto tcp from any to any port = 23 flags S/SA
Note that there's little point in trying to return any of the "new" ICMP
unreachable types (host-prohib, net-prohib, filter-prohib) since very
few TCP stacks will notice them and do something appropriate (not even
NetBSD's, so it seems). So you only want to return these types of
packets when refusing connections if you want to foil the client into
wasting time retrying, but still allow someone with a clue and a sniffer
to figure out what's really going on.
> Is it possible to disable the identd query in ftpd, telnetd, sendmail, and
> whatever daemons use it?
In the case of ftpd and telnetd, are you sure it's not inetd that's
doing the query, courtesy some rule in /etc/hosts.allow?
I'm pretty sure you can turn off ident queries in sendmail (you can in
smail for sure). However if a remote administrator (like me! :-) is
using encrypted ident replies then the first thing I'm going to ask for
if you send me a complaint about some message my server delivered to you
is the encrypted IDENT reply your mailer obtained when mine connected to
it.... Without that reply I'm going to argue just on principle that my
mailer didn't even make the connection and of course without that reply
I've got no corroberating evidence to show who did. :-)
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>