identd

[kaydiddy]

For a linux environment, identd is required to sustain somewhat of an elongated access period, to allow different users to be differentiated from their peers. However, this also proposes several information disclosure threats with the most popular identd servers, and there is no way to limit connections to identd based on source ports, since Hybrid and ratbox seem NOT to send identd requests from port 6667, and thus I am unable to firewall these queries off properly without disallowing fully functional ident service. Why is it implemented this way?

[corrupt]

I have no idea what exactly you are trying to say, so perhaps you could rephrase it. No, EFNet servers do not send ident requests from port 6667, they send requests from port 113 which follows the RFC1413 guidelines. For more information about RFC1413 visit http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1413.html.

If you want to give your users access to use identd to connect to EFNet servers, simply place a rule in your firewall that allows all TCP traffic to and from port 113.

[kaydiddy]

If you don't mind, I wasn't exactly requesting a reply from a newbie, but ah, I suppose I shouldn't expect anything less. No, EFNet servers (what exactly are 'EFNet servers'?) do not send ident requests from port 113, they send ident requests destined for port 113. What exactly does this have to do with my post? Thanks.

[Hwy]

All IRC servers use a standard TCP connect() to send the identd request. There is no logical reason in the code to set the source port, and unlike in UDP, I don't think it would work.

I believe you'll always have to deal with a source port for identd checks as ephemeral.

If you want to firewall things, why not just choose 1 or 2 stable servers and allow them by IP; or use stateful filtering?

[munky]

nowhere in rfc does it state what port an ident request should come from. it only states that a query should include the port the client is connecting to.
ie:
client.23523 -> server.6667
initiates an ident requesty
server.[random] -> client.113
query = "23523,6667"

afaik, not many, if any, services have a set port that connections come from. it's pretty standard that the client port be a random port > 1024. i believe that with standard bsd sockets, where you create a socket(AF_INET, SOCK_STREAM, 0) (nope, no source port specified here), and connect to a sockaddr, which specifies a sin_port, sin_addr, and sin_family of the server (no source port there, either).

so, my guess is, no, you're not going to be seeing ratbox or hybrid or any other portable ircd having all ident requests come from 6667.

[corrupt]

If you don't mind, I wasn't exactly requesting a reply from a newbie, but ah, I suppose I shouldn't expect anything less. No, EFNet servers (what exactly are 'EFNet servers'?) do not send ident requests from port 113, they send ident requests destined for port 113. What exactly does this have to do with my post? Thanks.

Not exactly a newbie. If you learned to speak proper English instead of trying to make your post sound over complex and full of misused technical terms -- someone might fully understand it. If you do not know what an EFNet server is, you should not even be posting on this forum. Goodbye.

[kaydiddy]

Hwy: Why? Because it's a bit of a useless clutter. Why do you see no logical reason and what does this have to do with UDP?

munky: No, the RFC says nothing about a source port. I'm not quite sure if this is better served as a response to me or as a response to corrupt.
P.S. You're not clever by telling me how a connect() scan works. I couldn't care less what you know or how long you've been around, and I'm not going to sit here and tell you what I know either. I was merely asking a question. It DOES seem logical to me to utilize a standard source port for such connections, whether or not you have to use raw sockets. Identd in a Linux environment is required to be running for varied elongated periods of time in order to function in all its glory, and as a result of most common ident server implementations providing user information for all sockets, information disclosure is thus a possible threat. I personally do not care, I was merely inquiring why the behavior of these IRC daemons is so infantile. As I said, however, I probably shouldn't expect any less, granted that the most popular IRC servers are created by freelance hackers in a patchwork environment.

corrupt: I said I didn't want replies from newbies. Your post was dismissed.

edit: I actually took the time to review your post briefly in hopes that you may turn out to be a brighter apple than I had originally presumed, and now I concur with my inklings. It is quite amusing that you find my grammatical syntax threatening, as this is how I have always presented myself. I'm not going to flame, but I assume you're reflecting your insecurities onto me as a result of you being intimidated. I have no idea why, but I do get this alot. However, I find my vocabulary quite limited, as do I find my grammatical efficacy quite inadequate. Your sarcasm is much appreciated.

[corrupt]

Munky was not trying to be clever, he was simply trying to give an adequate answer to your question, which you seem to have no clue about. We don't really care what you think our IRCDs should and should not do -- you are nothing to EFNet. If you don't like the way that our ircds send ident requests, develop your own IRCD (since you seem to be such a genius) and run your own network.

An identd in any enviroment is required to be ran for elongated periods of time to continously answer queries that it might recieve just as any other normal TCP daemon.

Do something useful with your time instead of acting like a know-it-all little tool. Take your kiddie like attitude and go write a shell script.

This thread is locked.