Since I'm currently suffering ISP troubles and checking everything my side,
I'm wondering if anyone still runs an ident server?
I told the firewall to send a reset in response to ident, quite a few
sites still send an ident request, for example ftp to nori.apnic.net
triggers an auth (113/tcp) request.
Thanks,
Grant.
--
http://bugsplatter.id.au/
> I'm wondering if anyone still runs an ident server?
Yes.
> I told the firewall to send a reset in response to ident, quite a few
> sites still send an ident request, ...
Instead of sending a reset, you could have it answer on behalf of your
client system, no?
--
----------------------------------------------------------------------
Sylvain Robitaille s...@alcor.concordia.ca
Network and Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
> I'm wondering if anyone still runs an ident server?
Yes.
> I told the firewall to send a reset in response to ident, quite a few
> I'm wondering if anyone still runs an ident server?
Yes.
> I told the firewall to send a reset in response to ident, quite a few
> I'm wondering if anyone still runs an ident server?
Yes.
> I told the firewall to send a reset in response to ident, quite a few
> Since I'm currently suffering ISP troubles and checking everything my
> side, I'm wondering if anyone still runs an ident server?
Nope.
> I told the firewall to send a reset in response to ident, quite a few
> sites still send an ident request, for example ftp to nori.apnic.net
> triggers an auth (113/tcp) request.
Some IRCd does that occasionally, but that's just to tease the kids.
S.
>Grant wrote:
>
>> I'm wondering if anyone still runs an ident server?
>
>Yes.
>
>> I told the firewall to send a reset in response to ident, quite a few
>> sites still send an ident request, ...
>
>Instead of sending a reset, you could have it answer on behalf of your
>client system, no?
Sure, but I don't know what to let it say these days, some suggest even
leaking username is a bad idea?
Grant.
--
http://bugsplatter.id.au:8080/ dodo, for internet that dies
> Sure, but I don't know what to let it say these days, some suggest
> even leaking username is a bad idea?
The point of the ident server is for the sysadmin on the local machine
to know who was accessing a remote machine, when a report comes in of
specific access ("our logs show access to our financial data from your
system, user foo...@yoursystem.domain, at such and such a time ...").
The username need not be meaningful in any way to the remote sysadmin.
Have it respond with "foobar", for all it matters, so long as you're
able to relate that connection back to the correct user account, should
anyone report inappropriate activity from your system.
Leaking usernames is a "bad" idea only if those usernames can be
associated with trivially guessed passwords.
>> I'm wondering if anyone still runs an ident server?
>
> Nope.
Hrmmm.... incorrect.
Rfc1413. You could sent a USERID:OTHER response to prevent leaking
usernames.
Jerry
fauxident.py will randomize all of it in any way you can imagine.
Most ident servers I've seen just want an ACK and don't much care if
it's a valid one. fauxident.py gives 'em a contentless ACK. Very
simple to install (/usr/local/). Google.
--
Any technology distinguishable from magic is insufficiently advanced.
(*) http://blinkynet.net/comp/uip5.html Linux Counter #80292
- - http://www.faqs.org/rfcs/rfc1855.html Please, don't Cc: me.
> Most ident servers I've seen just want an ACK and don't much care if
> it's a valid one. ...
The ident "server" is running on the "client" system, that is, the one
doing the connecting to the remote service. The one being queried for
an identity associated with a connection attempt to the querying system.
Your proposed "fauxident" acts as an ident "server".
The ident *client*, running on the system being connected to, has no
way of knowing whether the response from the ident server is "valid".
All it knows is whether it got a response or is still waiting (until
a timeout) for one. Some ident queries are done for authorization
(such as can be done by TCP_Wrappers, given suitable configuration),
but usually the point is simply to log the connection.
The validity of the response (usually) matters only to the system
administrator of the system the ident server runs on. If someone using
Grant's computer tries to connect to my system (for example), I could
refer to the log line produced by that attempt, and the response from
his ident server would be included in that log line. We then would
presume that the response from Grant's ident server is meaningful to
Grant (it needn't be meaningful to me at all), and that he would be able
to associate that connection attempt with a human being permitted to
use his computer (more correctly, an account username on his computer;
whether or not the human that belongs to that username was indeed using
the computer at the time is not proven by the ident server response).
I hope that helps clarify the matter ...
I haven't tested it in that exact situation, but this little writeup
might prove useful for you:
http://rlworkman.net/howtos/irc-identd
-RW
>The validity of the response (usually) matters only to the system
>administrator of the system the ident server runs on. If someone using
>Grant's computer tries to connect to my system (for example), I could
>refer to the log line produced by that attempt, and the response from
>his ident server would be included in that log line. We then would
>presume that the response from Grant's ident server is meaningful to
>Grant (it needn't be meaningful to me at all), and that he would be able
>to associate that connection attempt with a human being permitted to
>use his computer (more correctly, an account username on his computer;
>whether or not the human that belongs to that username was indeed using
>the computer at the time is not proven by the ident server response).
>
>I hope that helps clarify the matter ...
I just turned the thing on with slack's default identd.conf, sends
numeric uid ;)
So the firewall shows:
15:35:44 JLE:out:okay - TCP 36753 -> 21 (ftp) TTL=64 SYN ppp0->
deltree -> nori.apnic.net (AP:Asia Pacific)
15:35:44 JLE:inp:okay ident TCP 47767 -> 113 (auth) TTL=55 SYN ->ppp0
nori.apnic.net (AP:Asia Pacific) -> deltree
machine facing Internet here is deltree, aka bugsplatter.id.au.
Grant.
--
For linux system scripts, linux-kernel configs and dmesg, ipv4 geoip
and firewall tools: http://bugsplatter.id.au/
Google Groups is evil? See: http://improve-usenet.org/
Hey thanks for that, it ties in nicely with some ideas I'm trying out on
the new firewall script :) So far I've used ipt_recent as a way to jail
individual IPs without DoSing the service (eg. web) for others as a simple
limit rule does. Didn't think of linking expected return traffic with
ipt_recent as I see so few ident requests, and the other host seems to
accept a reset.
But then, I opened port 25 a couple weeks ago, installed leafnode
yesterday talking to ISP's + motzarella servers, so maybe I'll look at
IRC again.
The ISP trouble I had last week (no incoming port 80) was fixed Wednesday.
I started writing that concept into my firewall rules then decided I
don't get enough ident hits to warrant putting in special rules for them.
I did steal your ssh limiting, and added a port knock to it :) Another
post.
Grant.
--
http://bugsplatter.id.au/