I highly recommend ident2. It can be configured to be compliant yet
still return useless information (option -r). Therefore, you can
access services that require an ident server (IRC), but still not reveal
any useful information.

Example:

root@XXXXXXX:~# nmap -I localhost

Starting nmap V. 2.53 by [EMAIL PROTECTED] ( www.insecure.org/nmap/ )
Interesting ports on localhost (127.0.0.1):
(The 1515 ports scanned but not shown below are in state: closed)
Port       State       Service                 Owner
22/tcp     open        ssh                     atdhdo
23/tcp     open        telnet                  brzqgi
25/tcp     open        smtp                    brzqgi
80/tcp     open        http                    atdhdo
111/tcp    open        sunrpc                  atdhdo
113/tcp    open        auth                    atdhdo
3306/tcp   open        mysql                   atdhdo

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second


It returns 6 char random replies. It uses rand() to generate them
which is why all but 2 returned the same reply in a given scan.

-MB


On Sat, Jan 06, 2001 at 04:30:08AM +0100, dethy wrote:

> Using a self made reverse ident scanner based in perl I issued the
> following parameters to test pidentd (too if it answers our replies how i've
> mentioned)
>
> perl id.pl -d XXX.XXX.XXX.XXX  -p 20-25
>
>         port            service          owner
>
>         21              21               root
>         22              22               root
>         23              23               root
>         25              25               root
>
> okay, what we have here is: ports 21 - 25 were open and the PID owner was
> returned.
>
> I quickly tried it on 3 servers, all answered the query.
>
>       Pidentd, version 3.0.10 (compiled for Linux 2.2.5-22smp)
>       Pidentd, version 3.0.10 (compiled for Linux 2.2.16)
>       in.identd, version 2.8.5 FreeBSD 4.2
>
> So which versions don't answer to this request ?
> To my knowledge any RFC compliant identd will answer to this request,
> since the data used in the query is correct use of the EBNF described by
> the RFC.

--
Michael Bacarella <[EMAIL PROTECTED]>
Technical Staff / New York Connect.Net, Ltd
Daytime Phone: (212) 581-2831

Reply via email to