Re: a BSD identd
And pidentd will still be supported. Eventually, I'd like to have those huge majority who do not use DES tokens with pidentd move to the inetd identd (when committed)... How about a standalone identd with DES `tokens' and any other nice to haves that it doesn't make sense to implement in a built-in identd? Regards, Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Wed, 14 Jul 1999, Garance A Drosihn wrote: At 11:47 PM -0400 7/13/99, Brian F. Feldman wrote: We don't _need_ pidentd anymore. It will load down a system more than the inetd's implementation of ident will. Therefore, pidentd should be phased out. Other than that, pidentd should be using http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm. I am not sure I understand what you are saying. pident is currently a port, under 'security'. I can understand the idea that maybe it should be under 'net' instead (in fact, that's where I first looked for it when I went to install it on my machine). I agree that it shouldn't be under security, but if we move it now there will be a lot of complaining from the people who already know where it is. Not that that is necessarily a bad thing, but there you have it. As for the rest of it, you've wandered into the middle of a fairly silly argument. One camp says, "We don't need to have a built-in FreeBSD version of ident because we have a port of it available to those who need it." The other camp seems to be saying get rid of the port, but what they are really saying is that, "The current ident options all suck, so it would be nice to have a freebsd version that we know will work, and once we have that then people won't need the port, but they can install it if they want to." Frankly I don't see why we're still discussing this, but then again, I do. Hope this helps, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Tue, Jul 13, 1999 at 11:47:33PM -0400, Brian F. Feldman wrote: We don't _need_ pidentd anymore. It will load down a system more than the inetd's implementation of ident will. Therefore, pidentd should be phased out. Other than that, pidentd should be using http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm. pidentd supports DES-encrypted tokens as replies instead of the plaintext usernames. As long as your identd (or any other replacement) does not support this, there is still valid use for pidentd. bye, Harold -- Shabby Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Thu, 15 Jul 1999, Harold Gutch wrote: On Tue, Jul 13, 1999 at 11:47:33PM -0400, Brian F. Feldman wrote: We don't _need_ pidentd anymore. It will load down a system more than the inetd's implementation of ident will. Therefore, pidentd should be phased out. Other than that, pidentd should be using http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm. pidentd supports DES-encrypted tokens as replies instead of the plaintext usernames. As long as your identd (or any other replacement) does not support this, there is still valid use for pidentd. And pidentd will still be supported. Eventually, I'd like to have those huge majority who do not use DES tokens with pidentd move to the inetd identd (when committed)... bye, Harold -- Shabby Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
At 11:47 PM -0400 7/13/99, Brian F. Feldman wrote: We don't _need_ pidentd anymore. It will load down a system more than the inetd's implementation of ident will. Therefore, pidentd should be phased out. Other than that, pidentd should be using http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm. I am not sure I understand what you are saying. pident is currently a port, under 'security'. I can understand the idea that maybe it should be under 'net' instead (in fact, that's where I first looked for it when I went to install it on my machine). It sounds like you want it removed from the ports collection. Given that I have yet to see a real specific complaint against it (vague comments about it loads down the system or it's really buggy have not convinced me of much), I do not see why anyone would care if it remains in the ports collection. There are certainly other ports with bugs (hell, the base OS has bugs), and there are other things which load down a system (funny, my system does not seem to be loaded down by pident). What is it with this crusade to completely eridicate (phase out) pident? Or am I missing something here? --- Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu Senior Systems Programmer or dro...@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Wed, 14 Jul 1999, Garance A Drosihn wrote: At 11:47 PM -0400 7/13/99, Brian F. Feldman wrote: We don't _need_ pidentd anymore. It will load down a system more than the inetd's implementation of ident will. Therefore, pidentd should be phased out. Other than that, pidentd should be using http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm. I am not sure I understand what you are saying. pident is currently a port, under 'security'. I can understand the idea that maybe it should be under 'net' instead (in fact, that's where I first looked for it when I went to install it on my machine). I agree that it shouldn't be under security, but if we move it now there will be a lot of complaining from the people who already know where it is. Not that that is necessarily a bad thing, but there you have it. As for the rest of it, you've wandered into the middle of a fairly silly argument. One camp says, We don't need to have a built-in FreeBSD version of ident because we have a port of it available to those who need it. The other camp seems to be saying get rid of the port, but what they are really saying is that, The current ident options all suck, so it would be nice to have a freebsd version that we know will work, and once we have that then people won't need the port, but they can install it if they want to. Frankly I don't see why we're still discussing this, but then again, I do. Hope this helps, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Tue, Jul 13, 1999 at 11:47:33PM -0400, Brian F. Feldman wrote: We don't _need_ pidentd anymore. It will load down a system more than the inetd's implementation of ident will. Therefore, pidentd should be phased out. Other than that, pidentd should be using http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm. pidentd supports DES-encrypted tokens as replies instead of the plaintext usernames. As long as your identd (or any other replacement) does not support this, there is still valid use for pidentd. bye, Harold -- Shabby Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Thu, 15 Jul 1999, Harold Gutch wrote: On Tue, Jul 13, 1999 at 11:47:33PM -0400, Brian F. Feldman wrote: We don't _need_ pidentd anymore. It will load down a system more than the inetd's implementation of ident will. Therefore, pidentd should be phased out. Other than that, pidentd should be using http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm. pidentd supports DES-encrypted tokens as replies instead of the plaintext usernames. As long as your identd (or any other replacement) does not support this, there is still valid use for pidentd. And pidentd will still be supported. Eventually, I'd like to have those huge majority who do not use DES tokens with pidentd move to the inetd identd (when committed)... bye, Harold -- Shabby Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
"Brian F. Feldman" wrote: On Mon, 12 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. [snip] It's "out with the bad, in with the good." Pidentd code is pretty terrible. Agreed, nobody wants a monstrosity of an ident daemon in the base system. The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) Your code is still insecure, I can still obtain 16 characters of the first line of any file in the system just by symlinking to it. I don't see how you expect your checks to defeat that. What you should do is setgid setuid to the user returned by net.inet.tcp.getcred immediately after doing the sysctl. Or even better take out this FAKEID stuff. If anyone wants to audit my code for security, I invite them to. But frankly, I highly doubt anyone will find anything to exploit. Heh, famous last words. And, why would bugtraq advisories against other identds apply to my ident_stream service? This is an entirely different code base. That doesn't matter, different programmers make the same mistakes and assumptions when solving the same problem (there is research into the effectiveness of N-way programming which shows this) and many attacks are against subtle implementation mistakes which you may also make. Regards, Niall To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED], "Bria n F. Feldman" writes: On 13 Jul 1999, Ville-Pertti Keinonen wrote: [EMAIL PROTECTED] (Brian F. Feldman) writes: It's "out with the bad, in with the good." Pidentd code is pretty terrible . The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) If anyone wants to audit my code for security, I invite them to. Did you mean to avoid reading through symlinks using the open + fstat method mentioned earlier in the thread? No, I meant to avoid opening a file the user couldn't, or reading from a dev. Why not actually store the fake ID in a symbolic link? That way you just do a readlink(), which would be safer, neater and faster than reading a file. A user can set up a fake ID with something like: ln -s "Warm-Fuzzy" .fakeid Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In article [EMAIL PROTECTED], Ian Dowse [EMAIL PROTECTED] wrote: Why not actually store the fake ID in a symbolic link? That way you just do a readlink(), which would be safer, neater and faster than reading a file. A user can set up a fake ID with something like: ln -s "Warm-Fuzzy" .fakeid Ick. Please, no more abuse of symbolic links! Once (malloc) was enough. Data is held in files, not in filenames. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
Doug wrote: John Polstra wrote: Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take "NO" for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Really?? Even though their connect() call failed? Ick! I know sendmail doesn't behave that way. I'll take your word about the IRC daemons -- I don't know anything about them. Whether this behavior is good or not begs the question, Agreed. Every ircd i've ever seen will immediately return on a connection refused response. With ident: [15:22] -irc.dragondata.com- Looking up your hostname... [15:22] -irc.dragondata.com- Found your hostname, cached [15:22] -irc.dragondata.com- Checking Ident *** Identd request from 204.137.237.3 *** Identd replied: 1063, 4242 : USERID : UNIX : toasty [15:22] -irc.dragondata.com- Got Ident response PING? PONG! Welcome to Newnet Toasty9 Your host is irc.dragondata.com, running version nn-1.3devel.tmnotefix.noudpspam.hnam Elapsed time was less than 1 second. With no ident: [15:21] -irc.dragondata.com- Looking up your hostname... [15:21] -irc.dragondata.com- Checking Ident [15:21] -irc.dragondata.com- Found your hostname ToastyMan Nickname is already in use. PING? PONG! Welcome to Newnet Toasty9 Your host is irc.dragondata.com, running version nn-1.3devel.tmnotefix.noudpspam.hnam Elapsed time was less than 1 second. (I just tested this in NewNet, DALnet, EFnet, and Undernet) The only time I see it sitting there for 30 seconds is if ircd gets no response at all back, (no 'connection refused') Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Mon, 12 Jul 1999 15:12:49 -0400, "Brian F. Feldman" wrote:
It's "out with the bad, in with the good." Pidentd code is pretty
terrible.
Hi Brian,
I let your comment above go at the time that you said it and I waited
for Kevin Day to substantiate similar claims. Kevin very kindly took
the time to submit a PR which has helped me demonstrate to him that
the problems which he was seeing that led him to declare pidentd buggy
were in fact caused by a bug (bugs?) in the version of inetd that he's
running.
So while I take to heart Mike Smith's comments ("I'm ... worried about
... where the seniority of a code entity is considered more significant
than its functionality") I do think that this exercise serves no purpose
as long as pidentd is doing its job properly.
For detail on the inetd bugs causing apparent pidentd instability, I
invite you to examine PR 12596. If you feel there are other problems
with pidentd, I invite you to take Kevin's lead and file a PR.
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
gr...@freebsd.org (Brian F. Feldman) writes: It's out with the bad, in with the good. Pidentd code is pretty terrible. The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) If anyone wants to audit my code for security, I invite them to. Did you mean to avoid reading through symlinks using the open + fstat method mentioned earlier in the thread? I thought I'd misunderstood, that you had to be discussing something else, since you and whoever else was involved both agreed that open + fstat is sufficient, and I thought that several people can't possibly be so completely confused. If you really want to avoid reading through symlinks, you need to lstat, open and fstat (the order doesn't really matter). To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
Brian F. Feldman wrote: On Mon, 12 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. [snip] It's out with the bad, in with the good. Pidentd code is pretty terrible. Agreed, nobody wants a monstrosity of an ident daemon in the base system. The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) Your code is still insecure, I can still obtain 16 characters of the first line of any file in the system just by symlinking to it. I don't see how you expect your checks to defeat that. What you should do is setgid setuid to the user returned by net.inet.tcp.getcred immediately after doing the sysctl. Or even better take out this FAKEID stuff. If anyone wants to audit my code for security, I invite them to. But frankly, I highly doubt anyone will find anything to exploit. Heh, famous last words. And, why would bugtraq advisories against other identds apply to my ident_stream service? This is an entirely different code base. That doesn't matter, different programmers make the same mistakes and assumptions when solving the same problem (there is research into the effectiveness of N-way programming which shows this) and many attacks are against subtle implementation mistakes which you may also make. Regards, Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On 13 Jul 1999, Ville-Pertti Keinonen wrote: gr...@freebsd.org (Brian F. Feldman) writes: It's out with the bad, in with the good. Pidentd code is pretty terrible. The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) If anyone wants to audit my code for security, I invite them to. Did you mean to avoid reading through symlinks using the open + fstat method mentioned earlier in the thread? No, I meant to avoid opening a file the user couldn't, or reading from a dev. I thought I'd misunderstood, that you had to be discussing something else, since you and whoever else was involved both agreed that open + fstat is sufficient, and I thought that several people can't possibly be so completely confused. If you really want to avoid reading through symlinks, you need to lstat, open and fstat (the order doesn't really matter). I don't care about symlinks. I care about the underlying file. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Tue, 13 Jul 1999, Niall Smart wrote: Brian F. Feldman wrote: On Mon, 12 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. [snip] It's out with the bad, in with the good. Pidentd code is pretty terrible. Agreed, nobody wants a monstrosity of an ident daemon in the base system. The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) Your code is still insecure, I can still obtain 16 characters of the first line of any file in the system just by symlinking to it. I don't see how you expect your checks to defeat that. What you should do is setgid setuid to the user returned by net.inet.tcp.getcred immediately after doing the sysctl. Actually, I need to seteuid and setegid, because a setuid/setgid gives the user access to ident's process space. Anyway, I just forgot to upload the latest version of the patch. I also nuked it on MY system :/ But I just rewrote it (a bit better, too.) It's updated on freefall now. Or even better take out this FAKEID stuff. I'd rather keep it in, non-default, and semi-supported. If anyone wants to audit my code for security, I invite them to. But frankly, I highly doubt anyone will find anything to exploit. Heh, famous last words. Is this my last stand? And, why would bugtraq advisories against other identds apply to my ident_stream service? This is an entirely different code base. That doesn't matter, different programmers make the same mistakes and assumptions when solving the same problem (there is research into the effectiveness of N-way programming which shows this) and many attacks are against subtle implementation mistakes which you may also make. Ahh, but I don't make assumptions on input. I know that anything can happen. so prepare for the worst. Most mistakes are made by programmers when they assume that all input is safe. * Regards, Niall Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ * exploitable security holes To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In message pine.bsf.4.10.9907130946220.76301-100...@janus.syracuse.net, Bria n F. Feldman writes: On 13 Jul 1999, Ville-Pertti Keinonen wrote: gr...@freebsd.org (Brian F. Feldman) writes: It's out with the bad, in with the good. Pidentd code is pretty terrible . The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) If anyone wants to audit my code for security, I invite them to. Did you mean to avoid reading through symlinks using the open + fstat method mentioned earlier in the thread? No, I meant to avoid opening a file the user couldn't, or reading from a dev. Why not actually store the fake ID in a symbolic link? That way you just do a readlink(), which would be safer, neater and faster than reading a file. A user can set up a fake ID with something like: ln -s Warm-Fuzzy .fakeid Ian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Tue, 13 Jul 1999, Ian Dowse wrote: In message pine.bsf.4.10.9907130946220.76301-100...@janus.syracuse.net, Bria n F. Feldman writes: On 13 Jul 1999, Ville-Pertti Keinonen wrote: gr...@freebsd.org (Brian F. Feldman) writes: It's out with the bad, in with the good. Pidentd code is pretty terrible . The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) If anyone wants to audit my code for security, I invite them to. Did you mean to avoid reading through symlinks using the open + fstat method mentioned earlier in the thread? No, I meant to avoid opening a file the user couldn't, or reading from a dev. Why not actually store the fake ID in a symbolic link? That way you just do a readlink(), which would be safer, neater and faster than reading a file. A user can set up a fake ID with something like: ln -s Warm-Fuzzy .fakeid Hysterical raisins. ~/.fakeid being a text file is how it's always been done. That would be a better idea if I didn't mind confusing the hell out of people :) Ian Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Tue, Jul 13, 1999 at 03:12:51PM -0400, Brian F. Feldman wrote: Why not actually store the fake ID in a symbolic link? That way you just do a readlink(), which would be safer, neater and faster than reading a file. A user can set up a fake ID with something like: ln -s Warm-Fuzzy .fakeid Hysterical raisins. ~/.fakeid being a text file is how it's always been done. That would be a better idea if I didn't mind confusing the hell out of people :) You could tell them to do: ln -s `cat .fakeid` .fakeidnew mv .fakeid `cat .fakeid` mv .fakeidnew .fakeid Also - I guess if you're goting to patch inetd to do this stuff it should be runtime configurable to be able to: 1) return the traditional :ERROR:HIDDEN-USER, 2) return the real user always, 3) return the fakeid if it exists, and otherwise use the read user id, You should probably use uname to get the OS name too? David. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In article 199907132004.aa08...@salmon.maths.tcd.ie, Ian Dowse iedo...@maths.tcd.ie wrote: Why not actually store the fake ID in a symbolic link? That way you just do a readlink(), which would be safer, neater and faster than reading a file. A user can set up a fake ID with something like: ln -s Warm-Fuzzy .fakeid Ick. Please, no more abuse of symbolic links! Once (malloc) was enough. Data is held in files, not in filenames. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
Doug wrote: John Polstra wrote: Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take NO for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Really?? Even though their connect() call failed? Ick! I know sendmail doesn't behave that way. I'll take your word about the IRC daemons -- I don't know anything about them. Whether this behavior is good or not begs the question, Agreed. Every ircd i've ever seen will immediately return on a connection refused response. With ident: [15:22] -irc.dragondata.com- Looking up your hostname... [15:22] -irc.dragondata.com- Found your hostname, cached [15:22] -irc.dragondata.com- Checking Ident *** Identd request from 204.137.237.3 *** Identd replied: 1063, 4242 : USERID : UNIX : toasty [15:22] -irc.dragondata.com- Got Ident response PING? PONG! Welcome to Newnet Toasty9 Your host is irc.dragondata.com, running version nn-1.3devel.tmnotefix.noudpspam.hnam Elapsed time was less than 1 second. With no ident: [15:21] -irc.dragondata.com- Looking up your hostname... [15:21] -irc.dragondata.com- Checking Ident [15:21] -irc.dragondata.com- Found your hostname ToastyMan Nickname is already in use. PING? PONG! Welcome to Newnet Toasty9 Your host is irc.dragondata.com, running version nn-1.3devel.tmnotefix.noudpspam.hnam Elapsed time was less than 1 second. (I just tested this in NewNet, DALnet, EFnet, and Undernet) The only time I see it sitting there for 30 seconds is if ircd gets no response at all back, (no 'connection refused') Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Mon, 12 Jul 1999 15:12:49 -0400, Brian F. Feldman wrote: It's out with the bad, in with the good. Pidentd code is pretty terrible. Hi Brian, I let your comment above go at the time that you said it and I waited for Kevin Day to substantiate similar claims. Kevin very kindly took the time to submit a PR which has helped me demonstrate to him that the problems which he was seeing that led him to declare pidentd buggy were in fact caused by a bug (bugs?) in the version of inetd that he's running. So while I take to heart Mike Smith's comments (I'm ... worried about ... where the seniority of a code entity is considered more significant than its functionality) I do think that this exercise serves no purpose as long as pidentd is doing its job properly. For detail on the inetd bugs causing apparent pidentd instability, I invite you to examine PR 12596. If you feel there are other problems with pidentd, I invite you to take Kevin's lead and file a PR. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
We don't _need_ pidentd anymore. It will load down a system more than the inetd's implementation of ident will. Therefore, pidentd should be phased out. Other than that, pidentd should be using http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 22:34:09 +0200, Mark Murray wrote: As long as the documentation is _clear_ that this is not a front-line security tool, but rather a thing to marginally augment logs with user-supplied info, then I'll buy it. This is why I put forward a motion to move pidentd out of security and into net / sysutils last year. The suggestion wasn't well received, but I still think it'd help. I'd also like for the DESCR file for the port to say: "This service offers remote users some identity to report back to the local admin when complaining about abuse / break-ins originating from the local host." Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. I like this suggestion. I worry about a trend I'm seeing, with more and more people keen to replace existing code with their own virgin code which hasn't had any serious field time behind it. This seems like a very Linuxy development trend. It's the way the Bazaar works, but not in a Cathedral. Rather, you have a look at what's already there and try to work on it. You don't start your own wing a few feet from the Cathedral in the hopes that someone will bash down a similar wing elsewhere and join yours to the main building. Waffle waffle. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Mon, 12 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. I like this suggestion. I worry about a trend I'm seeing, with more and more people keen to replace existing code with their own virgin code which hasn't had any serious field time behind it. This seems like a very Linuxy development trend. It's the way the Bazaar works, but not in a Cathedral. Rather, you have a look at what's already there and try to work on it. You don't start your own wing a few feet from the Cathedral in the hopes that someone will bash down a similar wing elsewhere and join yours to the main building. It's "out with the bad, in with the good." Pidentd code is pretty terrible. The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) If anyone wants to audit my code for security, I invite them to. But frankly, I highly doubt anyone will find anything to exploit. And, why would bugtraq advisories against other identds apply to my ident_stream service? This is an entirely different code base. Waffle waffle. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 22:34:09 +0200, Mark Murray wrote: As long as the documentation is _clear_ that this is not a front-line security tool, but rather a thing to marginally augment logs with user-supplied info, then I'll buy it. This is why I put forward a motion to move pidentd out of security and into net / sysutils last year. The suggestion wasn't well received, but I still think it'd help. I'd also like for the DESCR file for the port to say: This service offers remote users some identity to report back to the local admin when complaining about abuse / break-ins originating from the local host. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. I like this suggestion. I worry about a trend I'm seeing, with more and more people keen to replace existing code with their own virgin code which hasn't had any serious field time behind it. This seems like a very Linuxy development trend. It's the way the Bazaar works, but not in a Cathedral. Rather, you have a look at what's already there and try to work on it. You don't start your own wing a few feet from the Cathedral in the hopes that someone will bash down a similar wing elsewhere and join yours to the main building. Waffle waffle. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 22:34:09 +0200, Mark Murray wrote: As long as the documentation is _clear_ that this is not a front-line security tool, but rather a thing to marginally augment logs with user-supplied info, then I'll buy it. This is why I put forward a motion to move pidentd out of security and into net / sysutils last year. The suggestion wasn't well received, but I still think it'd help. I'd also like for the DESCR file for the port to say: This service offers remote users some identity to report back to the local admin when complaining about abuse / break-ins originating from the local host. This issue is way to religious. As long as folk don't do anything blatantly stupid, and as long as the caveats are well documented, it is probably a good idea to just let this one stand, and lean on it gently :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Mon, 12 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. I like this suggestion. I worry about a trend I'm seeing, with more and more people keen to replace existing code with their own virgin code which hasn't had any serious field time behind it. This seems like a very Linuxy development trend. It's the way the Bazaar works, but not in a Cathedral. Rather, you have a look at what's already there and try to work on it. You don't start your own wing a few feet from the Cathedral in the hopes that someone will bash down a similar wing elsewhere and join yours to the main building. It's out with the bad, in with the good. Pidentd code is pretty terrible. The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) If anyone wants to audit my code for security, I invite them to. But frankly, I highly doubt anyone will find anything to exploit. And, why would bugtraq advisories against other identds apply to my ident_stream service? This is an entirely different code base. Waffle waffle. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
Whatever you do with identd, just make it work through NAT. That's the #1 request from folks where this is concerned. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
I like this suggestion. I worry about a trend I'm seeing, with more and more people keen to replace existing code with their own virgin code which hasn't had any serious field time behind it. I'm actually more worried about the opposing trend that you espouse, where the seniority of a code entity is considered more significant than its functionality. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
The whole point of ident was -- and still is -- to authenticate or verify who created a specific TCP connection. If the machine is untouched (i.e., has not had the root account compromised), then ident responses are usually trustworthy enough. It is generally not applicable to single user operating systems like Windows, Mac OS, or DOS. ...in other words it is not applicable to the vast majority of operating systems where it is used. Where is ident used? Predominantly with IRC, with a minority holding in tcp_wrappers and mail servers. In a "hard" wrapping environment, by the time you need ident, it is most likely compromised. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
Just because it's useless in some situations doesn't mean it's not useful in others. Yours is an argument against _misusing_ identd, not an argument against _using_ it. No. It is an argument against trusting it. :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 01:49:59 -0400, "Brian F. Feldman" wrote: inetd already has the built-in equivalent to that. Maybe it's possible to make a REAL ident (*cough* the one I wrote) an option, inetd has that service off by default. That sounds much more like it. I will say that I suspect this is a bad move. The more I think about it, the more I think we don't want the kitchen sink in there. Inetd only offers a limited auth service to prevent delays in the servicing of requests from local users on remote hosts. Anyone who wants to use the auth service for other things should probably use a specialized piece of software to do that. I don't think inetd needs this functionality built in. I think that what you really want is pidentd imported into the base system. And while it's noble to want a GNU-free base system and I applaud efforts in that direction, you should probably slow down and read pidentd's license agreement. :-) Personally, I don't think there's anything wrong with leaving pidentd as a port. Then the user can select one of two lines for a real ident service or a fake one. DES has some interesting ideas in this direction. Take a look at closed PR 11796 if and when you start thinking about how to implement this. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 00:49:59 EST, Kevin Day wrote: However, pidentd is rather buggy of late, and tends to freak out a lot. If we could have an 'official' identd, I'd like it. :) I hope you can back that up with more than a desire to see "an official identd", whatever that means. Can you actually give examples of buggy behaviour? If so, I'd suggest sending in a PR, not discussing it here. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
I don't see a point to that. However, I am finished. Please go to
http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch.
Hmm,
+#ifdef FAKEID
+ snprintf(fakeid_path, sizeof(fakeid_path), "%s/.fakeid",
pw-pw_dir);
+ fakeid = fopen(fakeid_path, "r");
+ if (fakeid) {
$ ln -s /etc/master.passwd ~/.fakeid
Ouch. (One possible saving grace here is that you truncate
after 16 characters).
+ if (!*cp || getpwnam(cp)) {
+ pw = getpwuid(uc.cr_uid);
+ cp = pw-pw_name;
+ goto printit;
+ }
What is this code trying to do? If the ~/.fakeid file is invalid
or the user is attempting to impersonate another then revert? A
comment would be nice. You forget to check for pw == NULL here
(but you don't earlier ;) and I don't think the goto is necessary.
Regards,
Niall
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 00:49:59 EST, Kevin Day wrote: However, pidentd is rather buggy of late, and tends to freak out a lot. If we could have an 'official' identd, I'd like it. :) I hope you can back that up with more than a desire to see "an official identd", whatever that means. Can you actually give examples of buggy behaviour? If so, I'd suggest sending in a PR, not discussing it here. Ciao, Sheldon. Please see: ports/12596 (just added) ports/8042 Thanks, Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 01:49:59 -0400, "Brian F. Feldman" wrote: inetd already has the built-in equivalent to that. Maybe it's possible to make a REAL ident (*cough* the one I wrote) an option, inetd has that service off by default. That sounds much more like it. I will say that I suspect this is a bad move. The more I think about it, the more I think we don't want the kitchen sink in there. Inetd only offers a limited auth service to prevent delays in the servicing of requests from local users on remote hosts. Anyone who wants to use the auth service for other things should probably use a specialized piece of software to do that. I don't think inetd needs this functionality built in. I think that what you really want is pidentd imported into the base system. And while it's noble to want a GNU-free base system and I applaud efforts in that direction, you should probably slow down and read pidentd's license agreement. :-) Personally, I don't think there's anything wrong with leaving pidentd as a port. I find pidentd gross, to say the least. I don't see why not to kill it... And this service is very small, so it doesn't make inetd "huge". It's not feeping creaturism because I replaced the ident service there with a working one. Then the user can select one of two lines for a real ident service or a fake one. DES has some interesting ideas in this direction. Take a look at closed PR 11796 if and when you start thinking about how to implement this. Ciao, Sheldon. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 14:03:29 -0400, "Brian F. Feldman" wrote: And this service is very small, so it doesn't make inetd "huge". It's not feeping creaturism because I replaced the ident service there with a working one. Perhaps this is where we're missing each other. The ident service supplied with inetd isn't "broken", it's just designed to do something different from what your replacement was designed to do. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
John Polstra wrote: In article [EMAIL PROTECTED], Warner Losh [EMAIL PROTECTED] wrote: Some ftpd and sendmail servers make the queries. When I have my fake identd in place, they go much faster... :-) Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take "NO" for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Whether this behavior is good or not begs the question, that is how it works. I'd also like to throw in some thoughts on ident in general, since I have several years of experience both in IRC administration and having been through this debate several times. :) 1. ident is useful as far as it goes. It shouldn't be trusted as authentication, but it can give you a good idea of where to start when tracking down problem users. 2. Most shell services do a good job of keeping ident reliable. They need to do that because most IRC networks heavily penalize clients that don't return any ident. 3. Having a built in version of a "real" ident run out of inetd would be *very* welcome by the people that need it. pidentd is a bloated, buggy pig. 4. I agree with Sheldon that returning "real" responses by default would be a bad thing. The current ability to send fake responses is a good thing, but having the option to do real ident would also be good. Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. HTH, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 12:54:03 EST, Kevin Day wrote: Please see: ports/12596 (just added) ports/8042 Thanks! I've seen 8042 before, but yours looks a lot more useful, as I can't make sense of the older one. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
Doug wrote: John Polstra wrote: Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take "NO" for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Really?? Even though their connect() call failed? Ick! I know sendmail doesn't behave that way. I'll take your word about the IRC daemons -- I don't know anything about them. Whether this behavior is good or not begs the question, Agreed. John --- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
John Polstra wrote: Doug wrote: John Polstra wrote: Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take "NO" for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Really?? Even though their connect() call failed? Ick! I know sendmail doesn't behave that way. I'll take your word about the IRC daemons -- I don't know anything about them. No, they connect(). If it times out (eg: packet filter), it kicks you out. If it gets through and the ident server doesn't respond within the 30 second timeout, it drops you again. If it connects and gets a 'Warm-Fuzzy' or an error of some sort, it drops you. If it gets a non-UNIX username response, it kicks you out. Basically, to use a well connected irc server, you *must* run an identd that returns a valid username response, and that username is used in your conversations. Some servers will let you on without a fully functional identd, but in my experience they seem to be the most unreliable as they are the most abused. ISP's run identd on their shell servers. That's so that when their servers get banned from IRC, they can find out which of their shell users from their shell users to have taken out and shot. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
1. ident is useful as far as it goes. It shouldn't be trusted as
authentication, but it can give you a good idea of where to start when
tracking down problem users.
First thing you say to yourself after a compromise is "trust nothing".
Things like idents can/will/should/are targets.
2. Most shell services do a good job of keeping ident reliable. They need
to do that because most IRC networks heavily penalize clients that don't
return any ident.
This is changing. In the face of ${BIGNUM} Windoze boxes giving ident
answers like "HAX0r", there is little point, except for the administrator
of the box _giving_ the ident. If that was me, it would be _low_ on my
list.
3. Having a built in version of a "real" ident run out of inetd would be
*very* welcome by the people that need it. pidentd is a bloated, buggy pig.
Small set of people. Much larger set of dupes who would believe/trust
this.
4. I agree with Sheldon that returning "real" responses by default would be
a bad thing. The current ability to send fake responses is a good thing,
but having the option to do real ident would also be good.
As long as the documentation is _clear_ that this is not a front-line
security tool, but rather a thing to marginally augment logs with
user-supplied info, then I'll buy it.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Doug wrote: 3. Having a built in version of a "real" ident run out of inetd would be *very* welcome by the people that need it. pidentd is a bloated, buggy pig. Thank you. That's why I wrote it. 4. I agree with Sheldon that returning "real" responses by default would be a bad thing. The current ability to send fake responses is a good thing, but having the option to do real ident would also be good. Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. How in the world could my inetd ident service be exploited? I just fixed the only problematic feature, fake id, to make it not read anything but a regular file and not let you try to use someone else's name. I can't see any way that any part of it could be exploited... HTH, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
: 2. Most shell services do a good job of keeping ident reliable. They need
: to do that because most IRC networks heavily penalize clients that don't
: return any ident.
:
:This is changing. In the face of ${BIGNUM} Windoze boxes giving ident
:answers like "HAX0r", there is little point, except for the administrator
:of the box _giving_ the ident. If that was me, it would be _low_ on my
:list.
ident is extremely useful when taken in the proper context. It doesn't
really matter what a user-owned box returns. An IRC administrator only
cares about two things:
* If the irc client is connecting from an (ISP's) multi-user shell
machine, that the ident contain sufficient information to identify
the user.
* If the irc client is connecting from a single-user machine, such as
a windoz box, the IRC administrator has the IP address and times
involved, which is again sufficient for the user's ISP to identify
the user.
When a user is abusing an IRC server, the IRC administrator has two
choices:
* If it is coming from an ISP who takes abuse seriously, the IRC
administrator need only identify the user sufficiently (IP and time,
or ident info if coming from a shared shell box) such that the ISP
can kick the user off the service.
* If it is coming from an ISP who does not take abuse seriously, the
IRC administrator locks out the entire ISP.
At BEST ident was turned on on all machines and it returned the user's
real user name. It did that because it made it a whole lot easier for us
to handle abuse issues, it cut abuse significantly, and it cut
abuse-related email from remote IRC admins significantly because they
could lockout specific users based on the ident info without having to
contact us.
I don't work at BEST any more, but I would love to see kernel support
for ident lookups. To make identd work reasonably well, I had to hack
the server to timeout after a few seconds worth of cpu-bound searching
through KVM, because it would sometimes get into scanning loops.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
:How in the world could my inetd ident service be exploited? I just fixed :the only problematic feature, fake id, to make it not read anything but a :regular file and not let you try to use someone else's name. I can't see :any way that any part of it could be exploited... Typically the exploitation of identd is in the form of a denial-of-service attack. What we saw at BEST were denial-of-service attacks against identd to prevent users on a particular shell machine from being able to initiate an IRC client session (because the remote IRC server would not be able to obtain ident info). Early versions of Identd could be used for port scanning purposes, but not any more. Since identd will only resolve connections comming from the client IP making the connection, there aren't very many "interesting" ways to abuse it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: response, it kicks you out. Basically, to use a well connected irc server, you *must* run an identd that returns a valid username response, and that username is used in your conversations. Some servers will let you on without a fully functional identd, but in my experience they seem to be the most unreliable as they are the most abused. Uh, not always. I've been on/off of IRC for the last, oh, 7 years or so, and _still_ don't bother to run identd. It's a nuisance, and as I'm the admin on my machines, I don't need it. I've always managed to find some well-run servers that don't require identd. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : Good idea. I'll have it check to see that it's a regular file. Make sure that you do this with the stat, open, fstat interlocking so that there isn't a race here. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] John Polstra writes: : Really?? Even though their connect() call failed? Ick! I know : sendmail doesn't behave that way. I'll take your word about the IRC : daemons -- I don't know anything about them. Yes. At least that's what I've observed. However, I believe the culprit was a firewall that just dropped the packets for the connection request, so it had to wait 30 seconds to timeout. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Warner Losh wrote: In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : Good idea. I'll have it check to see that it's a regular file. Make sure that you do this with the stat, open, fstat interlocking so that there isn't a race here. I have this fixed in my latest code (on freefall of course). I did not use an original stat because that's pointless, as it adds another race condition. The only downside to my approach is that if it's a symlink to a dev, the dev can get opened/closed, and d_open/d_close be called. Warner Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : I have this fixed in my latest code (on freefall of course). I did not : use an original stat because that's pointless, as it adds another race : condition. The only downside to my approach is that if it's a symlink : to a dev, the dev can get opened/closed, and d_open/d_close be called. How does the original stat add a race condition. You stat the file, open it, then fstat it. If the two match you know you're good. If they don't, you can detect that something bad has happened Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : Ahh, I misunderstood you. In _this_ case you just proposed, the stat is : really pointless. What good would it do? It would let you know if you should even try to open the file... But that doesn't solve the race. The fstat tells you if what you opened was what you thought you were opening... However, for this, the original stat might not be completely necessary unless you were trying to specifically detect someone trying to race you. You are right that it won't buy you anything. I was confusing this with the tree walking case. The stat + fstat check there was needed... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Kevin Day wrote:
Is it worth it to write an identd for FreeBSD? With one sysctl added, it's
trivial to implement. If an identd would be desired, then should I make a
separate one, or rewrite the current inetd's internal identd shim? I
don't see a reason for pidentd when we could have an identd built in by
me fixing inetd up, and it would all take up less space.
There is the question - what for? identd is of questionable use at best.
The best use of identd I have seen is crypted cookies that would allow
an attackee to identify an attacker in a non-privacy-invasive manner.
In 3 years of running this at an ISP, I have never seen it used in anger.
Under normal circumstances (${BIGNUM} Wintendo boxes running IRC
clients), the info given is completely useless.
Just to add a counter-point here, I run an ISP that offers shell accounts.
We get idiot customers using IRC for all sorts of nasty things at times, and
identd is the only method I have for knowing who did it when I get
complaints.
However, pidentd is rather buggy of late, and tends to freak out a lot. If
we could have an 'official' identd, I'd like it. :)
Go ahead and try out mine then! You'll need the following patches from
http://www.FreeBSD.org/~green/ :
socred.patch (not necessary for 4.0; some parts require manual attention in
3.X, as it won't patch perfectly; this is already applied in 4.0)
getcred.patch
inetd_ident.patch
Patch them in in order, making sure they apply correctly. Then make includes,
rebuild the kernel, rebuild modules, install kernel and modules, rebuild
inetd, edit inetd.conf to enable the built-in auth service, and
reboot. Let me know how it goes. I hope to make this standard as part of 4.0 :)
Kevin
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
The whole point of ident was -- and still is -- to authenticate or verify who created a specific TCP connection. If the machine is untouched (i.e., has not had the root account compromised), then ident responses are usually trustworthy enough. It is generally not applicable to single user operating systems like Windows, Mac OS, or DOS. ...in other words it is not applicable to the vast majority of operating systems where it is used. Where is ident used? Predominantly with IRC, with a minority holding in tcp_wrappers and mail servers. In a hard wrapping environment, by the time you need ident, it is most likely compromised. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
Just because it's useless in some situations doesn't mean it's not useful in others. Yours is an argument against _misusing_ identd, not an argument against _using_ it. No. It is an argument against trusting it. :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 01:49:59 -0400, Brian F. Feldman wrote: inetd already has the built-in equivalent to that. Maybe it's possible to make a REAL ident (*cough* the one I wrote) an option, inetd has that service off by default. That sounds much more like it. I will say that I suspect this is a bad move. The more I think about it, the more I think we don't want the kitchen sink in there. Inetd only offers a limited auth service to prevent delays in the servicing of requests from local users on remote hosts. Anyone who wants to use the auth service for other things should probably use a specialized piece of software to do that. I don't think inetd needs this functionality built in. I think that what you really want is pidentd imported into the base system. And while it's noble to want a GNU-free base system and I applaud efforts in that direction, you should probably slow down and read pidentd's license agreement. :-) Personally, I don't think there's anything wrong with leaving pidentd as a port. Then the user can select one of two lines for a real ident service or a fake one. DES has some interesting ideas in this direction. Take a look at closed PR 11796 if and when you start thinking about how to implement this. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 00:49:59 EST, Kevin Day wrote: However, pidentd is rather buggy of late, and tends to freak out a lot. If we could have an 'official' identd, I'd like it. :) I hope you can back that up with more than a desire to see an official identd, whatever that means. Can you actually give examples of buggy behaviour? If so, I'd suggest sending in a PR, not discussing it here. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
I don't see a point to that. However, I am finished. Please go to
http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch.
Hmm,
+#ifdef FAKEID
+ snprintf(fakeid_path, sizeof(fakeid_path), %s/.fakeid,
pw-pw_dir);
+ fakeid = fopen(fakeid_path, r);
+ if (fakeid) {
$ ln -s /etc/master.passwd ~/.fakeid
Ouch. (One possible saving grace here is that you truncate
after 16 characters).
+ if (!*cp || getpwnam(cp)) {
+ pw = getpwuid(uc.cr_uid);
+ cp = pw-pw_name;
+ goto printit;
+ }
What is this code trying to do? If the ~/.fakeid file is invalid
or the user is attempting to impersonate another then revert? A
comment would be nice. You forget to check for pw == NULL here
(but you don't earlier ;) and I don't think the goto is necessary.
Regards,
Niall
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In article 199907102150.paa33...@harmony.village.org, Warner Losh i...@village.org wrote: Some ftpd and sendmail servers make the queries. When I have my fake identd in place, they go much faster... :-) Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. The only way a long timeout can occur is if you have a filter rule installed that drops the incoming packets without responding to them. You can block the incoming packets but still avoid the timeout with a filter rule that sends back a reset: add reset tcp from any to any auth setup in via etha16 John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 00:49:59 EST, Kevin Day wrote: However, pidentd is rather buggy of late, and tends to freak out a lot. If we could have an 'official' identd, I'd like it. :) I hope you can back that up with more than a desire to see an official identd, whatever that means. Can you actually give examples of buggy behaviour? If so, I'd suggest sending in a PR, not discussing it here. Ciao, Sheldon. Please see: ports/12596 (just added) ports/8042 Thanks, Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 01:49:59 -0400, Brian F. Feldman wrote: inetd already has the built-in equivalent to that. Maybe it's possible to make a REAL ident (*cough* the one I wrote) an option, inetd has that service off by default. That sounds much more like it. I will say that I suspect this is a bad move. The more I think about it, the more I think we don't want the kitchen sink in there. Inetd only offers a limited auth service to prevent delays in the servicing of requests from local users on remote hosts. Anyone who wants to use the auth service for other things should probably use a specialized piece of software to do that. I don't think inetd needs this functionality built in. I think that what you really want is pidentd imported into the base system. And while it's noble to want a GNU-free base system and I applaud efforts in that direction, you should probably slow down and read pidentd's license agreement. :-) Personally, I don't think there's anything wrong with leaving pidentd as a port. I find pidentd gross, to say the least. I don't see why not to kill it... And this service is very small, so it doesn't make inetd huge. It's not feeping creaturism because I replaced the ident service there with a working one. Then the user can select one of two lines for a real ident service or a fake one. DES has some interesting ideas in this direction. Take a look at closed PR 11796 if and when you start thinking about how to implement this. Ciao, Sheldon. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Niall Smart wrote:
I don't see a point to that. However, I am finished. Please go to
http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch.
Hmm,
+#ifdef FAKEID
+ snprintf(fakeid_path, sizeof(fakeid_path), %s/.fakeid,
pw-pw_dir);
+ fakeid = fopen(fakeid_path, r);
+ if (fakeid) {
$ ln -s /etc/master.passwd ~/.fakeid
Ouch. (One possible saving grace here is that you truncate
after 16 characters).
Good idea. I'll have it check to see that it's a regular file.
+ if (!*cp || getpwnam(cp)) {
+ pw = getpwuid(uc.cr_uid);
+ cp = pw-pw_name;
+ goto printit;
+ }
What is this code trying to do? If the ~/.fakeid file is invalid
or the user is attempting to impersonate another then revert? A
comment would be nice. You forget to check for pw == NULL here
(but you don't earlier ;) and I don't think the goto is necessary.
If pw lookup for that uid succeeded before, why won't it succeed now? In
fact, I didn't even need the pw = , but that would be depending on
current static behavior...
Regards,
Niall
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 14:03:29 -0400, Brian F. Feldman wrote: And this service is very small, so it doesn't make inetd huge. It's not feeping creaturism because I replaced the ident service there with a working one. Perhaps this is where we're missing each other. The ident service supplied with inetd isn't broken, it's just designed to do something different from what your replacement was designed to do. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
John Polstra wrote: In article 199907102150.paa33...@harmony.village.org, Warner Losh i...@village.org wrote: Some ftpd and sendmail servers make the queries. When I have my fake identd in place, they go much faster... :-) Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take NO for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Whether this behavior is good or not begs the question, that is how it works. I'd also like to throw in some thoughts on ident in general, since I have several years of experience both in IRC administration and having been through this debate several times. :) 1. ident is useful as far as it goes. It shouldn't be trusted as authentication, but it can give you a good idea of where to start when tracking down problem users. 2. Most shell services do a good job of keeping ident reliable. They need to do that because most IRC networks heavily penalize clients that don't return any ident. 3. Having a built in version of a real ident run out of inetd would be *very* welcome by the people that need it. pidentd is a bloated, buggy pig. 4. I agree with Sheldon that returning real responses by default would be a bad thing. The current ability to send fake responses is a good thing, but having the option to do real ident would also be good. Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. HTH, Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999 12:54:03 EST, Kevin Day wrote: Please see: ports/12596 (just added) ports/8042 Thanks! I've seen 8042 before, but yours looks a lot more useful, as I can't make sense of the older one. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
Doug wrote: John Polstra wrote: Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take NO for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Really?? Even though their connect() call failed? Ick! I know sendmail doesn't behave that way. I'll take your word about the IRC daemons -- I don't know anything about them. Whether this behavior is good or not begs the question, Agreed. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
John Polstra wrote: Doug wrote: John Polstra wrote: Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take NO for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Really?? Even though their connect() call failed? Ick! I know sendmail doesn't behave that way. I'll take your word about the IRC daemons -- I don't know anything about them. No, they connect(). If it times out (eg: packet filter), it kicks you out. If it gets through and the ident server doesn't respond within the 30 second timeout, it drops you again. If it connects and gets a 'Warm-Fuzzy' or an error of some sort, it drops you. If it gets a non-UNIX username response, it kicks you out. Basically, to use a well connected irc server, you *must* run an identd that returns a valid username response, and that username is used in your conversations. Some servers will let you on without a fully functional identd, but in my experience they seem to be the most unreliable as they are the most abused. ISP's run identd on their shell servers. That's so that when their servers get banned from IRC, they can find out which of their shell users from their shell users to have taken out and shot. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
1. ident is useful as far as it goes. It shouldn't be trusted as
authentication, but it can give you a good idea of where to start when
tracking down problem users.
First thing you say to yourself after a compromise is trust nothing.
Things like idents can/will/should/are targets.
2. Most shell services do a good job of keeping ident reliable. They need
to do that because most IRC networks heavily penalize clients that don't
return any ident.
This is changing. In the face of ${BIGNUM} Windoze boxes giving ident
answers like HAX0r, there is little point, except for the administrator
of the box _giving_ the ident. If that was me, it would be _low_ on my
list.
3. Having a built in version of a real ident run out of inetd would be
*very* welcome by the people that need it. pidentd is a bloated, buggy pig.
Small set of people. Much larger set of dupes who would believe/trust
this.
4. I agree with Sheldon that returning real responses by default would be
a bad thing. The current ability to send fake responses is a good thing,
but having the option to do real ident would also be good.
As long as the documentation is _clear_ that this is not a front-line
security tool, but rather a thing to marginally augment logs with
user-supplied info, then I'll buy it.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Doug wrote: 3. Having a built in version of a real ident run out of inetd would be *very* welcome by the people that need it. pidentd is a bloated, buggy pig. Thank you. That's why I wrote it. 4. I agree with Sheldon that returning real responses by default would be a bad thing. The current ability to send fake responses is a good thing, but having the option to do real ident would also be good. Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. How in the world could my inetd ident service be exploited? I just fixed the only problematic feature, fake id, to make it not read anything but a regular file and not let you try to use someone else's name. I can't see any way that any part of it could be exploited... HTH, Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
: 2. Most shell services do a good job of keeping ident reliable. They need
: to do that because most IRC networks heavily penalize clients that don't
: return any ident.
:
:This is changing. In the face of ${BIGNUM} Windoze boxes giving ident
:answers like HAX0r, there is little point, except for the administrator
:of the box _giving_ the ident. If that was me, it would be _low_ on my
:list.
ident is extremely useful when taken in the proper context. It doesn't
really matter what a user-owned box returns. An IRC administrator only
cares about two things:
* If the irc client is connecting from an (ISP's) multi-user shell
machine, that the ident contain sufficient information to identify
the user.
* If the irc client is connecting from a single-user machine, such as
a windoz box, the IRC administrator has the IP address and times
involved, which is again sufficient for the user's ISP to identify
the user.
When a user is abusing an IRC server, the IRC administrator has two
choices:
* If it is coming from an ISP who takes abuse seriously, the IRC
administrator need only identify the user sufficiently (IP and time,
or ident info if coming from a shared shell box) such that the ISP
can kick the user off the service.
* If it is coming from an ISP who does not take abuse seriously, the
IRC administrator locks out the entire ISP.
At BEST ident was turned on on all machines and it returned the user's
real user name. It did that because it made it a whole lot easier for us
to handle abuse issues, it cut abuse significantly, and it cut
abuse-related email from remote IRC admins significantly because they
could lockout specific users based on the ident info without having to
contact us.
I don't work at BEST any more, but I would love to see kernel support
for ident lookups. To make identd work reasonably well, I had to hack
the server to timeout after a few seconds worth of cpu-bound searching
through KVM, because it would sometimes get into scanning loops.
-Matt
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
:How in the world could my inetd ident service be exploited? I just fixed :the only problematic feature, fake id, to make it not read anything but a :regular file and not let you try to use someone else's name. I can't see :any way that any part of it could be exploited... Typically the exploitation of identd is in the form of a denial-of-service attack. What we saw at BEST were denial-of-service attacks against identd to prevent users on a particular shell machine from being able to initiate an IRC client session (because the remote IRC server would not be able to obtain ident info). Early versions of Identd could be used for port scanning purposes, but not any more. Since identd will only resolve connections comming from the client IP making the connection, there aren't very many interesting ways to abuse it. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
Mark Murray wrote:
1. ident is useful as far as it goes. It shouldn't be trusted as
authentication, but it can give you a good idea of where to start when
tracking down problem users.
First thing you say to yourself after a compromise is trust nothing.
Things like idents can/will/should/are targets.
Sure, but I don't think that compromised boxes are the norm, unless I'm
missing something here.
2. Most shell services do a good job of keeping ident reliable. They need
to do that because most IRC networks heavily penalize clients that don't
return any ident.
This is changing. In the face of ${BIGNUM} Windoze boxes giving ident
answers like HAX0r, there is little point, except for the administrator
of the box _giving_ the ident. If that was me, it would be _low_ on my
list.
I'm talking shell services, not ISP's. All of the large IRC networks
have
either implemented a global ban system (like dalnet and undernet) or have a
kline information sharing system (like efnet and ircnet) that allows them
to effectively prevent access from the shell system to IRC. Since most
shells are sold for IRC, the administrators of these systems are doing
everything they can to cooperate with the IRC networks in tracking problem
users, and ident is one of the tools to help do this. I agree that windows
users being able to supply their own ident makes it less valuable in the
general case, but not completely unvaluable.
3. Having a built in version of a real ident run out of inetd would be
*very* welcome by the people that need it. pidentd is a bloated, buggy pig.
Small set of people. Much larger set of dupes who would believe/trust
this.
How much code is in the system now that benefits a small set of
people?
That said, I am definitely an anti-bloatist and would almost prefer that
this identd be a port. But from what Brian is saying it sounds like this
would be a very small addition, and for those few people that need it this
would be a huge benefit. I believe the cost:benefit analysis comes out in
favor of including it, but perhaps my perspective is biased.
4. I agree with Sheldon that returning real responses by default would be
a bad thing. The current ability to send fake responses is a good thing,
but having the option to do real ident would also be good.
As long as the documentation is _clear_ that this is not a front-line
security tool, but rather a thing to marginally augment logs with
user-supplied info, then I'll buy it.
Yes, I agree wholeheartedly with this point.
Doug
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Matthew Dillon wrote:
: 2. Most shell services do a good job of keeping ident reliable. They need
: to do that because most IRC networks heavily penalize clients that don't
: return any ident.
:
:This is changing. In the face of ${BIGNUM} Windoze boxes giving ident
:answers like HAX0r, there is little point, except for the administrator
:of the box _giving_ the ident. If that was me, it would be _low_ on my
:list.
ident is extremely useful when taken in the proper context. It doesn't
really matter what a user-owned box returns. An IRC administrator only
cares about two things:
* If the irc client is connecting from an (ISP's) multi-user shell
machine, that the ident contain sufficient information to identify
the user.
* If the irc client is connecting from a single-user machine, such as
a windoz box, the IRC administrator has the IP address and times
involved, which is again sufficient for the user's ISP to identify
the user.
When a user is abusing an IRC server, the IRC administrator has two
choices:
* If it is coming from an ISP who takes abuse seriously, the IRC
administrator need only identify the user sufficiently (IP and time,
or ident info if coming from a shared shell box) such that the ISP
can kick the user off the service.
* If it is coming from an ISP who does not take abuse seriously, the
IRC administrator locks out the entire ISP.
At BEST ident was turned on on all machines and it returned the user's
real user name. It did that because it made it a whole lot easier for us
to handle abuse issues, it cut abuse significantly, and it cut
abuse-related email from remote IRC admins significantly because they
could lockout specific users based on the ident info without having to
contact us.
I don't work at BEST any more, but I would love to see kernel support
for ident lookups. To make identd work reasonably well, I had to hack
the server to timeout after a few seconds worth of cpu-bound searching
through KVM, because it would sometimes get into scanning loops.
Well, it's here now. I've committed it in 4.0, and would MFC it except it
would require the struct socket changes I made in -CURRENT. See my pidentd
freebsd.c replacement (using this) at http://www.FreeBSD.org/~green/freebsd4.c
-Matt
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In message 199907112034.waa17...@gratis.grondar.za, Mark Murray wrote: } 1. ident is useful as far as it goes. It shouldn't be trusted as } authentication, but it can give you a good idea of where to start when } tracking down problem users. } } First thing you say to yourself after a compromise is trust nothing. } Things like idents can/will/should/are targets. As has been said over and over, identd isn't useful to track a compromise of the machine running it, but can be useful if machine A is running it and hasn't been compromised, and machine A is used to break into machine B. Of course even then you have to be careful about trusting logs, but in a well set up environment it's certainly better than nothing. And it's useful for tracking abuse that's not related to breaking into machines. [ ... ] } 3. Having a built in version of a real ident run out of inetd would be } *very* welcome by the people that need it. pidentd is a bloated, buggy pig. } } Small set of people. Much larger set of dupes who would believe/trust } this. While that's true, I'll say again that it's an argument against _abusing_ identd and not an argument against _using_ it. You may not like/want/need it, but other people do, and not all of them are idiots. Just because someone else's usage model differs from yours doesn't make their experiences or desires invalid. -- Jon Hamilton hamil...@pobox.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In article local.mail.freebsd-hackers/19990711203203.b320...@overcee.netplex.com.au you write: response, it kicks you out. Basically, to use a well connected irc server, you *must* run an identd that returns a valid username response, and that username is used in your conversations. Some servers will let you on without a fully functional identd, but in my experience they seem to be the most unreliable as they are the most abused. Uh, not always. I've been on/off of IRC for the last, oh, 7 years or so, and _still_ don't bother to run identd. It's a nuisance, and as I'm the admin on my machines, I don't need it. I've always managed to find some well-run servers that don't require identd. -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In message pine.bsf.4.10.9907111649160.27818-100...@janus.syracuse.net Brian F. Feldman writes: : How in the world could my inetd ident service be exploited? I just fixed : the only problematic feature, fake id, to make it not read anything but a : regular file and not let you try to use someone else's name. I can't see : any way that any part of it could be exploited... Typically how that was exploited is as a buffer overflow on the remote side (eg there was an exploit in sendmail where the attacker would send a very long string when the ident request came accross. Sendmail would record this in a fixed length buffer on the stack, which overflowed allowing an egg to execute). The text file that you read could be used to make it easier to setup such a hostile host, since if I recall correctly, the entire EGG was printable characters. There are no limits in the size of responses for ident... Thankfully, this exploit is long since dead. However, with irc servers using it as a honest people's lock to keep honest people honest maybe there is something that can be done there. Also, at one time one could open the ident service port up and just sit there, never sending data. After a short period of time, all the ident server slots would be in use, and then the attacker could begin to attack the remote side in earnest (this is a reason that I had forgotten why identd was considered to be a very weak protocol). There was also some trick of using identd to scan ports (eg, connect to identd and ask for each port, in succession, since some early identds weren't selective enough about the data they returned). I also recall seeing on some of the blacker lists that I've bumped into instructions for using TTCP and/or half open connections to confuse identd as well. I can't find the references right now, but these may also have boiled down to the TCP SYN-class of attacks that was so popular a while ago. There is also a danger in accepting source routed packets as well (which I think we turn off at the system level by default). They could be used to figure out who other connections belonged to by disguising the source address to be one other than the originator to gain information about any user connected to your machine. Well, you did ask how it might be abused :-) Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In message pine.bsf.4.10.9907111408060.25135-100...@janus.syracuse.net Brian F. Feldman writes: : Good idea. I'll have it check to see that it's a regular file. Make sure that you do this with the stat, open, fstat interlocking so that there isn't a race here. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In message xfmail.990711131918@polstra.com John Polstra writes: : Really?? Even though their connect() call failed? Ick! I know : sendmail doesn't behave that way. I'll take your word about the IRC : daemons -- I don't know anything about them. Yes. At least that's what I've observed. However, I believe the culprit was a firewall that just dropped the packets for the connection request, so it had to wait 30 seconds to timeout. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In message 37890518.aa3d7...@gorean.org Doug writes: : Sure, but I don't think that compromised boxes are the norm, unless I'm : missing something here. The response doesn't have to come from the box being asked the question in order for it to be accepted. If you can load the box being asked highly enough, you can sniff the packets from another machine and then use that knowledge to win the race to make the connection. If you win the race, and the target machine responds, its answer will silently be tossed away. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Warner Losh wrote: In message pine.bsf.4.10.9907111408060.25135-100...@janus.syracuse.net Brian F. Feldman writes: : Good idea. I'll have it check to see that it's a regular file. Make sure that you do this with the stat, open, fstat interlocking so that there isn't a race here. I have this fixed in my latest code (on freefall of course). I did not use an original stat because that's pointless, as it adds another race condition. The only downside to my approach is that if it's a symlink to a dev, the dev can get opened/closed, and d_open/d_close be called. Warner Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In message pine.bsf.4.10.9907112031200.31726-100...@janus.syracuse.net Brian F. Feldman writes: : I have this fixed in my latest code (on freefall of course). I did not : use an original stat because that's pointless, as it adds another race : condition. The only downside to my approach is that if it's a symlink : to a dev, the dev can get opened/closed, and d_open/d_close be called. How does the original stat add a race condition. You stat the file, open it, then fstat it. If the two match you know you're good. If they don't, you can detect that something bad has happened Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Warner Losh wrote: In message pine.bsf.4.10.9907112031200.31726-100...@janus.syracuse.net Brian F. Feldman writes: : I have this fixed in my latest code (on freefall of course). I did not : use an original stat because that's pointless, as it adds another race : condition. The only downside to my approach is that if it's a symlink : to a dev, the dev can get opened/closed, and d_open/d_close be called. How does the original stat add a race condition. You stat the file, open it, then fstat it. If the two match you know you're good. If they don't, you can detect that something bad has happened Ahh, I misunderstood you. In _this_ case you just proposed, the stat is really pointless. What good would it do? Warner Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
In message pine.bsf.4.10.9907112242280.34006-100...@janus.syracuse.net Brian F. Feldman writes: : Ahh, I misunderstood you. In _this_ case you just proposed, the stat is : really pointless. What good would it do? It would let you know if you should even try to open the file... But that doesn't solve the race. The fstat tells you if what you opened was what you thought you were opening... However, for this, the original stat might not be completely necessary unless you were trying to specifically detect someone trying to race you. You are right that it won't buy you anything. I was confusing this with the tree walking case. The stat + fstat check there was needed... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
a BSD identd
Is it worth it to write an identd for FreeBSD? With one sysctl added, it's trivial to implement. If an identd would be desired, then should I make a separate one, or rewrite the current inetd's internal identd shim? I don't see a reason for pidentd when we could have an identd built in by me fixing inetd up, and it would all take up less space. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sat, 10 Jul 1999, Sheldon Hearn wrote: On Sat, 10 Jul 1999 11:50:01 -0400, "Brian F. Feldman" wrote: I don't see a reason for pidentd when we could have an identd built in by me fixing inetd up, and it would all take up less space. Hi Brian, If you do end up messing with inetd's existing ident service, please make sure that the default behaviour remains the same and that the operator must do something to enable an ident service that reports more than just "UNKNOWN-ERROR". Thanks, Sheldon. I don't see a point to that. However, I am finished. Please go to http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch. =) Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
Is it worth it to write an identd for FreeBSD? With one sysctl added, it's
trivial to implement. If an identd would be desired, then should I make a
separate one, or rewrite the current inetd's internal identd shim? I
don't see a reason for pidentd when we could have an identd built in by
me fixing inetd up, and it would all take up less space.
There is the question - what for? identd is of questionable use at best.
The best use of identd I have seen is crypted cookies that would allow
an attackee to identify an attacker in a non-privacy-invasive manner.
In 3 years of running this at an ISP, I have never seen it used in anger.
Under normal circumstances (${BIGNUM} Wintendo boxes running IRC
clients), the info given is completely useless.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sat, 10 Jul 1999 13:06:33 -0400, "Brian F. Feldman" wrote: I don't see a point to that. I'm not sure whether you don't see the point in the existing behaviour, or whether you don't see the point in doing as I ask and supporting consistent behaviour in FreeBSD. The existing ident implementation is designed to answer queries without answering with any information. This is done so that services MTA's and irc daemons don't end up waiting for ages for the ident request to time out. Why do I want you to work your changes in as an extension that isn't turned on by default? The Principle Of Least Astonishment. If I have a system that hasn't been giving out local usernames in answser to ident queries, I sure as hell don't want it to suddenly start doing so without my telling it to. However, I am finished. Please go to http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch. I'll look at your inetd-related patches on Sunday evening or Monday and get back to you on Monday, but I do hope you see the light in what I've said above. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sat, 10 Jul 1999, Mark Murray wrote: There is the question - what for? identd is of questionable use at best. I used to run a public shell machine, and one of my users cracked someone else's site. Identd made it much easier to figure out who the problem user was. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sat, 10 Jul 1999, Mark Murray wrote: There is the question - what for? identd is of questionable use at best. I used to run a public shell machine, and one of my users cracked someone else's site. Identd made it much easier to figure out who the problem user was. That represents tiny percentage of identd use. The rest is noise. Pidentd+DES _is_ useful in the situation you mention above. It is on average useless to most security folk, as it can also be used to obfuscate the problem. Crack root on the box, and identd is no longer trustworthy. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sat, Jul 10, 1999, Mark Murray wrote: I used to run a public shell machine, and one of my users cracked someone else's site. Identd made it much easier to figure out who the problem user was. That represents tiny percentage of identd use. The rest is noise. Pidentd+DES _is_ useful in the situation you mention above. It is on average useless to most security folk, as it can also be used to obfuscate the problem. Crack root on the box, and identd is no longer trustworthy. You have an interesting point, however, once a user gains root access, nothing on the machine should be considered trustworthy. -- Chris Costello[EMAIL PROTECTED] If a train station is where the train stops, what is a work station? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
Pidentd+DES _is_ useful in the situation you mention above. It is on average useless to most security folk, as it can also be used to obfuscate the problem. Crack root on the box, and identd is no longer trustworthy. You have an interesting point, however, once a user gains root access, nothing on the machine should be considered trustworthy. Right - but ident is an "after the fact" tool; one which at the time you really need results is at its least trustworthy. I need that like an extra hole in the head. :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sat, Jul 10, 1999, Mark Murray wrote: Pidentd+DES _is_ useful in the situation you mention above. It is on average useless to most security folk, as it can also be used to obfuscate the problem. Crack root on the box, and identd is no longer trustworthy. You have an interesting point, however, once a user gains root access, nothing on the machine should be considered trustworthy. Right - but ident is an "after the fact" tool; one which at the time you really need results is at its least trustworthy. I need that like an extra hole in the head. :-) The whole point of ident was -- and still is -- to authenticate or verify who created a specific TCP connection. If the machine is untouched (i.e., has not had the root account compromised), then ident responses are usually trustworthy enough. It is generally not applicable to single user operating systems like Windows, Mac OS, or DOS. -- Chris Costello[EMAIL PROTECTED] Sure it's user-friendly...if you know what you're doing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] Sheldon Hearn writes: : If you do end up messing with inetd's existing ident service, please : make sure that the default behaviour remains the same and that the : operator must do something to enable an ident service that reports more : than just "UNKNOWN-ERROR". Yes. I'd love to replace my perl script: #!/usr/local/bin/perl ($a, $b) = split(/[,\n\r ]+/,); print "$a , $b : USERID : UNIX : Warm-Fuzzy\r\n"; with something a little less heavy-weight. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
: I don't see a point to that. Some ftpd and sendmail servers make the queries. When I have my fake identd in place, they go much faster... :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] Ben Rosengart writes: : I used to run a public shell machine, and one of my users cracked : someone else's site. Identd made it much easier to figure out who the : problem user was. Unfortunately, I've seen the dark side of identd which makes me *HATE* it with a passion. There have been several places that I worked that ran identd, but from which I never sent mail from. The spammers started hitting me there They got the address from the ident replies From this, I'm *NEVER* going to run a identd that gives out real names Hence "Warm-Fuzzy" in my fake script. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
Warner Losh wrote: In message [EMAIL PROTECTED] Sheldon Hearn writes: : If you do end up messing with inetd's existing ident service, please : make sure that the default behaviour remains the same and that the : operator must do something to enable an ident service that reports more : than just "UNKNOWN-ERROR". Yes. I'd love to replace my perl script: #!/usr/local/bin/perl ($a, $b) = split(/[,\n\r ]+/,); print "$a , $b : USERID : UNIX : Warm-Fuzzy\r\n"; with something a little less heavy-weight. Come on guys! identd is one of those topics that also comes under the banner of "religion", and no one solution works for everyone. It is often abused, has too much credibility placed on it at times that it is really meaningless, and it *does* have legitimate uses. It all depends on the circumstances. I just wish that the inetd builtins could take arguments to allow selection of behavior according to what the the person using needs or wants. (ie: real, fake, "unknown error", "piss off", etc results). I also like pidentd's DES encrypted cookie as it is a nice solution to the forgery problem. (I actually had this happen once, a long time ago). Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
In message [EMAIL PROTECTED] Chris Costello writes: :The whole point of ident was -- and still is -- to : authenticate or verify who created a specific TCP connection. NO. The IDENT protocol was never intended to authenticate who was on the other end. *NEVER*. People ABUSED it as such, but its value is only as good as the person providing the information. : If : the machine is untouched (i.e., has not had the root account : compromised), then ident responses are usually trustworthy : enough. It is generally not applicable to single user operating : systems like Windows, Mac OS, or DOS. FALSE. If I can hit the remote side faster than the machine that is untouched with a response (by sniffing the packets on a network and heavily loading the machine that I'm attacking from, but haven't penetrated root), then the information is bogus as well. At best, the information provides who might be on the other end of the end of the link... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
