View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002301 | unreal | ircd | public | 2005-01-25 06:02 | 2013-05-06 06:06 |
| Reporter | vonitsanet | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.2.3 | ||||
| Target Version | 3.3-alpha0 | Fixed in Version | 3.4-alpha1 | ||
| Summary | 0002301: "NickName is an IRC Operator" field on whois | ||||
| Description | Can be added On the whois information (for ircops only of course) something like this: Normal Users Can See On Whois: NickName is an IRC Operator IrcOps will see: NickName is an IRC Operator [Oper-Username] Something like when an ircop Oper Up. The server notice shows the oper username. This is useful for all opers because they can who is the ircop even if he has changed his nick to something else. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| 3rd party modules | |||||
|
|
Good Morning:-PP Any reply?:-))) |
|
|
um why? are ur ircops not all in the same channel? |
|
|
Actually I can see one use for this - if an oline got hacked and you the server admin are trying to figure out which one it is so as to delete it... and didn't catch the operup notice :) . |
|
|
aquanight log files? |
|
|
When someone is an ircop with a different nick and i can't think who is he and i haven't see the operup notice.. It's not so easy to /stats o and search the hostnames and check the olines or to login to my account to see the ircd logfile.. I ask for this feature so every ircop can check more easy who is who when he can't remember a nickname... |
|
|
in order tostop this person using this "hacked" opers line, you need to access ur shell and change the password for that oper, since ur already IN the shell why not check the log file? what if a oper pastes another opers whois by accident into a userwhisper or user channel, youve given away that nicknames oper up name , thats why i dont see this as such a good idea. |
|
|
If you're smart, you shouldn't be able to hack an oline to begin with. It should require almost an exact host, and a decently strong password which is stored encrypted, or even better, an SSL key. In any case, Unreal does not store the oper username with the user. Once the user is opered up, Unreal no longer keeps track of which oline they used. Therefore, adding this feature would increase memory usage since we'd now need to store this information. For something with limited utility (seeing as how the log already has this information) I'm not sure I'm willing to waste this memory usage. Also, I don't quite agree with any of the reasons provided. As I said, oline hacking should be rare or impossible. I've never seen it occur and I've been an oper on about 10 different networks over a 6 year period. Second, when it does occur, you're going to need to go into the shell anyway. Then for the, finding out who an oper really is, well ever heard of /msg? "/msg SomeOperIDontKnow Hey, who are you?" Additionally, each server should not have more than 3-4 opers. So is doing a /stats o and comparing 3 hostmasks really that difficult? Seems like it would take half a second to me. So I don't see that as being useful either. |
|
|
[quote]In any case, Unreal does not store the oper username with the user. Once the user is opered up, Unreal no longer keeps track of which oline they used. Therefore, adding this feature would increase memory usage since we'd now need to store this information. For something with limited utility (seeing as how the log already has this information) I'm not sure I'm willing to waste this memory usage.[/quote] Yet, AngryWolf's m_getinfo module is somehow able to retrieve information that you say is not stored? |
|
|
Also, if oper-up info is not stored, how does oper::maxlogins work? |
|
|
The two aren't related at all. Having int login_attempts; is different than having char *login_id; |
|
|
I found this in AngryWolf's getinfo module... if (acptr->user->operlogin) sendto_one(sptr, ":%s 339 %s :Last used oper login: %s", me.name, sptr->name, acptr->user->operlogin); I somehow doubt that 'operlogin' field was something he made up :P . Also, about the whole hostmask thing, well typically one relies more heavily on password security, and also, when dynamic IPs are involved, it's difficult to have an exact IP and username... Me for example, even though my IP has only changed about 3 times in the past year or so, the fact that it can change proves that I'm technically on a dynamic IP even if it pretty much only changes once in a blue moon... Anyway, I suppose it's correct that this really isn't that useful. One can always check logs (unless they don't keep logs for some reason (shell limits?)) and the hostmask thing codemastr mentioned (even though that doesn't 100% work when an oper could match up with more than one hostmask... like when you have two opers from the same ISP and said ISP is super-dynamic (like, dialup dynamic :p))... *shrug* *edit* Oh, a couple of other problems: - This pretty much breaks when an oper gets oper privileges from services (SVS2MODE +o \ SVSO +O+etc). - Looking at AngryWolf's use of it tells me that field is still valid when the oper deopers. And if said oper gets oper privileges from services, now you're displaying incorrect information... |
|
|
Hmm, yeah, I forgot, that was implemented by storing the login name. In any case though, I'm still not sure this is really worth adding. If people want it, I suppose it can be done, but it just seems like something no one will ever use and that will confuse most people. |
|
|
I've asking for this as a way to check more easy who is using an oline. Yes there are many others way i agree and i'm sure it's useless for anything else. Also this may be added with a snomask. So opers will have a choice if the want to see this info or not. Cya |
|
|
I would vote for putting the time it will take to do on something else, or bugs. |
|
|
Snomas...k?! ANOTHER one?! Aaargh. Please god, no. |
|
|
Any final answer for this (little:P) feature? It will be added sometime or not at all? :)) |
|
|
wots wrong with adding this to a pre existsing snomask? |
|
|
You all seem to have forgotten the purposes of SNomasks. So I'll refresh you a little. SNoMasks, standing for Server Notice masks, is a feature added to unreal to replace the generic +s usermode that was defined in the RFC (ie: what users got sent server notices, such as users connecting.) Now, this was really necessary since the number of server notices got BIGGER. And big networks got a LOT of snotices. Now, you'll see here, that server notices are NOT pieces of information that a user can see. As you'll recall with the usermode conversation, there is a finite limit on the number of snomasks that can be used (32 again, I believe). Now, can you imagine, if I added a snomask for each and every piece of optional information, how many there would be? A bloody lot. [admittedly, some things like eyes snomask kind of go against this but.. oh well, another day, another feature request.] |
|
|
We can just not use any snomask/usermode. This can be added to the /whois to all opers. And if you want to disable it do it from config? |
|
|
ok heres an addition that accord in the #unreal-support room 08:15 <+Dj-Neo> Your maximum number of concurrent oper logins has been reached (2) 08:16 <+Dj-Neo> I can't ! 08:16 <+Dj-Neo> I can't oper me Now say he is competant and has a fellow staff memeber around, they can do a who +m o and see who is opered then do a simple whois on each to see who is using this guys oline |
|
|
Anyway can we do something about this thing?:P |
|
|
i have seen this somewhere (modulized). bt i dont remember the ircnetwork:( |
|
|
This looks like a good feature to me. I'll add it if no one else wants to take a swing at it. |
|
|
Potential patch uploaded. m_whois.correct.patch. (Ignore the other =P) |
|
|
Fixed in .2371 |
|
|
needs re-porting, or did we already add this? |
|
|
I say no thanks. There isnt a practical reason the expose an opers login to other opers. Admins just need to secure their oper's olines, simple as that. Yes, it is a pain in the butt to add 50 hostmasks but no one says being an admin is fun 24/7. At best i can see an admin using this info for their locally connected opers, but not global as they likely have no shell access to fix any problems anyway. |
|
|
You have serious issues with your opers don't you? Do you also suspect any of your opers for DoS attacks by explosing your hub's IP perhaps? ---"Admins just need to secure their oper's olines, simple as that." You said it, not me. ---"Yes, it is a pain in the butt to add 50 hostmasks" There is no reason to add anything than *@* for a single oper: http://forums.unrealircd.com/viewtopic.php?t=4181 ---"but not global as they likely have no shell access to fix any problems anyway." Says who? For your setup maybe. For other's maybe not. |
|
|
1> Not all clients support SSL certs so the point of *not* using *@* is still highly relevant. 2> Securing oper blocks as strictly as possible has been standard practice by experienced admins that have eye witnessed rogue opers for nearly 20 years now, it's not my invention. There is a reason we check a hostmask to start with. 3> Please allow me to quote RFC1459, dated May 1993. Section 8.12.2: "The granting of operator privileges to a disruptive person can have dire consequences for the well-being of the IRC net in general due to the powers given to them. Thus, the acquisition of such powers should not be very easy." SSL Certs aside, using strict hostmasks, max logins, requiring certain usermodes like +z is how UnrealIRCd helps admins secure oper blocks. So I say again, Admins need to secure their oper blocks .. it's as simple as that. Anyway, back on topic. To help keep the network secure, I don't advise broadcasting any portion of an opers login information, even to opers. |
|
|
All major clients support SSL and as we are talking about opers, you may want to advice (or force) them to use such a client (or their own client through ssl tunnel). Also, back in 1993 we had not such features like SSL authentication. https://tools.ietf.org/html/rfc2813#section-7.2 Besides that, as '/stats o server' returns the operblock list, I can't see any difference in terms of security. |
|
|
There is a difference between using ssl to connect to irc and using ssl certs as a password, the latter is what you referred in defense of using *@*. My underlying point is that if you secure your oper blocks properly like any good admin will, then you won't have a need to see whom is using what login in the first place, you will already know. Lets not forget about our logfiles. Granted, no everyone has log file access. That only reinforces my point about broadcasting oper login info to those that don't need it because they can't do anything about it anyway. It also reinforces my previous statement that at best, only the local admin would have any use for it. As far as whom has shell access or may need this on your individual network, there is a patch attached to assist you. |
|
|
To use SSL as a password you need to connect through SSL and use your own certificate. |
|
|
"To use SSL as a password you need to connect through SSL and use your own certificate." Obviously, but still not all clients support the SSL Cert as a password portion of your statement and stunnel will not fix that. Lets stay on topic now please. |
|
|
Inside stunnel configuration i can see the following section: # Certificate Authority file CAfile = ca-chain.pem # Your client certificate in PEM format. cert = mycert.pem # Where the private key is kept. key = mycert.pem So I can't see why stunnel will not fix that. Did I miss something here? |
|
|
Even if you are correct, it's still off topic. Not to mention that as an IRCd we can't expect every admin in the world to force SSL on their opers. We have to focus on security for anyone that uses Unreal, not just a few networks that so choose to force ssl. This feature is about broadcasting oper login information to other opers. Something that I see as pointless and as a security risk because it's easier to accidentally paste the /whois output than the /stats o output to the public. JoeOper from RandomServ1 doesn't need access to JonnyAdmin's oper login from RandomServ2. I say again, there is a patch attached that should help your individual network. Good Day. |
|
|
After thinking about what I truly object here, it's more of how easy it would be to accidentally paste /whois than opers knowing others logins, while I still disagree that opers need to know, i'm more troubled about this being in the /whois. I'm always paranoid when there is oper only information available in regular user commands. Silly? Perhaps, but not unwarranted. Obviously, if this goes in, please make it optional. vonitsanet, in addition to the attached patch, you may want to consider the GETINFO module. It's like a /whois on steroids and will tell you what oper login was used. Personally, I'd like to see the GETINFO module part of Unreal's core. |
|
|
Please keep this on topic. I am tired of seeing you two bicker in my inbox with this issue. If you would like to discuss the relationships of SSL connections and SSL authentication and how it applies to opers, PLEASE DO SO SOMEWHERE ELSE. Any further off-topic notes will be deleted. Syzop has already marked this for re-porting, there is no need to continue to discuss this issue. If it is added to 3.3 and you want it, great; if not, don't use it. |
|
|
Now, back on topic: The requested feature simplifies the ability to identify an oper if the oper has changed his/her nick. > There isnt a practical reason the expose an opers login to other opers. Oper logins can be viewed by other opers in the oper-up notice announcing a login. The oper login can also be seen with /stats o, then matched to the oper matching the userhost. An oper can also find track nickchanges from that original oper notice using snomasks nN. |
|
|
Uhm, no Stealth. 1> The patch attached is *not* optional so I can't simply "not use it". 2> All of the instances where the oper login is already seen is true enough but none of them are executed using a user command, like /whois. /stats o - oper only by default. oper up notice - oper only. snomask nN - oper only. /whois - a very basic *USER* command. Utter chaos has been wrought from users gaining access to oper information by 1 form or another. Granted, it's also been coupled with the network security level set on stupid, but still. UnderNet was nearly brought to it's knees because a user social engineered oper information. We as opers are more likely to expose sensitive information to users from the output of user commands than we are from oper only commands. It's a mental thing, but still happens. We have the option for opers to invite themselves into +ps channels .. why? that is to prevent an oper from accidentally joining such channels be way of a normal user command, which is done out of habit and by placing the oper login into the /whois output we are creating the exact same possibility of accidentally exposing otherwise sensitive data to users. Am I the only one that sees that?! If you want a /whois style way of showing sensitive info to opers, then adopt GETINFO into Unreal's core or ship it with Unreal as a module exactly like cloak.so already is. It takes 5 minutes .. hell, I'll even do the patch for it! |
|
|
39 comments.. woah. As Stealth noted (and myself), the idea is accepted and needs to be re-ported. I also disagree that exposing oper login information to other IRCOps is a problem. In fact, I don't see a reason to make this configurable... I find this rather ridiculous.. but if the person who writes the patch has too much time on his/her hands then sure.. why not.. I'm not going to block it either. |
|
|
In reply to katsklaw about including the info in a basic user command, please read the patch before you make even more of a fool of yourself: + if (IsOper(sptr) && MyClient(acptr)) + sendto_one(sptr, + ":%s 313 %s %s :is %s (%s)", + me.name, parv[0], + name, buf, + acptr->user->operlogin); The oper login is only displayed if the user requesting the whois is an oper, so therefore it is not and will not be provided to users. |
|
|
http://hg.unrealircd.org/hg/unreal/rev/cb370040ab01 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-01-25 06:02 | vonitsanet | New Issue | |
| 2005-01-27 07:27 | vonitsanet | Note Added: 0008932 | |
| 2005-01-27 22:10 | White_Magic | Note Added: 0008933 | |
| 2005-01-28 19:33 | aquanight | Note Added: 0008934 | |
| 2005-01-29 00:06 | White_Magic | Note Added: 0008935 | |
| 2005-01-29 06:46 | vonitsanet | Note Added: 0008936 | |
| 2005-01-29 11:18 | White_Magic | Note Added: 0008937 | |
| 2005-01-29 12:57 |
|
Note Added: 0008940 | |
| 2005-01-29 18:39 | aquanight | Note Added: 0008955 | |
| 2005-01-29 19:35 | Stealth | Note Added: 0008956 | |
| 2005-01-29 19:50 |
|
Note Added: 0008957 | |
| 2005-01-30 12:08 | aquanight | Note Added: 0008961 | |
| 2005-01-30 12:11 | aquanight | Note Edited: 0008961 | |
| 2005-01-30 14:16 |
|
Note Added: 0008962 | |
| 2005-01-31 12:28 | vonitsanet | Note Added: 0008965 | |
| 2005-02-23 12:02 | devil | Note Added: 0009265 | |
| 2005-02-24 23:32 | w00t | Note Added: 0009290 | |
| 2005-03-08 06:32 | vonitsanet | Note Added: 0009507 | |
| 2005-03-08 09:18 | White_Magic | Note Added: 0009513 | |
| 2005-03-08 09:38 | w00t | Note Added: 0009516 | |
| 2005-03-10 08:39 | vonitsanet | Note Added: 0009555 | |
| 2005-03-21 08:36 | RandomNumber | Note Added: 0009640 | |
| 2005-03-21 10:29 | vonitsanet | Note Added: 0009641 | |
| 2005-11-12 10:47 | vonitsanet | Note Added: 0010724 | |
| 2007-04-18 19:02 | WolfSage | Note Added: 0013551 | |
| 2007-04-19 02:27 |
|
Status | new => acknowledged |
| 2007-04-19 22:49 | WolfSage | File Added: m_whois.patch | |
| 2007-04-19 22:50 | WolfSage | Note Added: 0013614 | |
| 2007-04-19 22:54 | WolfSage | Note Edited: 0013614 | |
| 2007-04-19 22:59 | WolfSage | File Added: m_whois.correct.patch | |
| 2007-04-19 23:00 | WolfSage | Note Edited: 0013614 | |
| 2007-04-20 03:21 |
|
Status | acknowledged => confirmed |
| 2007-04-24 05:31 |
|
Status | confirmed => resolved |
| 2007-04-24 05:31 |
|
Fixed in Version | => 3.3-alpha0 |
| 2007-04-24 05:31 |
|
Resolution | open => fixed |
| 2007-04-24 05:31 |
|
Assigned To | => stskeeps |
| 2007-04-24 05:31 |
|
Note Added: 0013654 | |
| 2011-07-19 14:18 | syzop | Note Added: 0016706 | |
| 2011-07-19 14:18 | syzop | Assigned To | stskeeps => |
| 2011-07-19 14:18 | syzop | Status | resolved => needs re porting |
| 2011-07-19 17:11 | syzop | Target Version | => 3.3-alpha0 |
| 2013-02-12 06:56 | dummy | Status | needs re porting => has patch |
| 2013-02-19 22:54 | syzop | Status | has patch => needs re porting |
| 2013-02-26 06:54 | katsklaw | Note Added: 0017442 | |
| 2013-02-27 14:14 | vonitsanet | Note Added: 0017443 | |
| 2013-02-27 14:18 | vonitsanet | Note Edited: 0017443 | |
| 2013-02-27 14:20 | vonitsanet | Note Edited: 0017443 | |
| 2013-02-27 14:20 | vonitsanet | Note Edited: 0017443 | |
| 2013-02-27 14:22 | vonitsanet | Note Edited: 0017443 | |
| 2013-02-27 14:27 | vonitsanet | Note Edited: 0017443 | |
| 2013-02-27 14:28 | vonitsanet | Note Edited: 0017443 | |
| 2013-02-27 14:28 | vonitsanet | Note Edited: 0017443 | |
| 2013-02-27 14:29 | vonitsanet | Note Edited: 0017443 | |
| 2013-02-27 23:30 | katsklaw | Note Added: 0017444 | |
| 2013-02-28 00:50 | vonitsanet | Note Added: 0017445 | |
| 2013-02-28 00:51 | vonitsanet | Note Edited: 0017445 | |
| 2013-02-28 01:01 | vonitsanet | Note Edited: 0017445 | |
| 2013-02-28 01:04 | katsklaw | Note Added: 0017446 | |
| 2013-02-28 01:07 | vonitsanet | Note Added: 0017447 | |
| 2013-02-28 01:09 | katsklaw | Note Added: 0017448 | |
| 2013-02-28 01:19 | vonitsanet | Note Added: 0017449 | |
| 2013-02-28 01:29 | katsklaw | Note Added: 0017450 | |
| 2013-02-28 01:33 | katsklaw | Note Edited: 0017450 | |
| 2013-02-28 02:09 | katsklaw | Note Added: 0017451 | |
| 2013-02-28 04:19 | Stealth | Note Added: 0017452 | |
| 2013-02-28 04:37 | Stealth | Note Added: 0017453 | |
| 2013-03-02 00:24 | katsklaw | Note Added: 0017454 | |
| 2013-03-02 18:47 | syzop | Note Added: 0017455 | |
| 2013-03-03 01:40 | Stealth | Note Added: 0017460 | |
| 2013-05-06 06:05 |
|
Note Added: 0017486 | |
| 2013-05-06 06:05 |
|
Status | needs re porting => resolved |
| 2013-05-06 06:05 |
|
Fixed in Version | 3.3-alpha0 => 3.4-alpha1 |
| 2013-05-06 06:05 |
|
Assigned To | => nenolod |
