Page 1 of 1

Scenario: Denying Operator Access To An Operator

Posted: Mon Feb 28, 2011 6:08 pm
by MiRe
Hello and good day to all. I've been working on creating my own private network for my friends, family etc. to connect to. As I am tackling this project seriously (and somewhat professionally) I'm trying to plan out various scenarios, and document what needs to be done. I've done some online searches via Google and on the forums but I haven't quite found what I am looking for. I'm not new to iRC but I am new to the whole administrative side of it (it's one of the reasons I started this project).
So here goes:

Here is an example of one of my operator definitions:

Code: Select all

oper networkoperator {
	from {
		userhost *@*;
	};
	password networkoper;
	class clients;
	flags {
		helpop;
		can_rehash;
		can_wallops;
		can_globops;
		can_localroute;
		can_globalroute;
		can_localkill;
		can_globalkill;
		can_kline;
		can_unkline;
		can_localnotice;
		can_globalnotice;
		can_gkline;
	};
};
I have similar blocks set up for the network admin, services admin, server admin and server co-admin. My simple idea is to grant multiple iRC Operators access to a particular block. For example I may have 10 operators oper up using "/oper networkoperator networkoper". I have read many times on these forums:
aquanight wrote:If you don't trust your opers, don't make them opers.
Well here's my scenario: I get my network all set up, and I've given the O:Line described above to someone I trust, let's call her Melissa. Now some years pass, me and Melissa have a serious falling out, say, she doesn't like how the network is being administered, and she ends up being disruptive to the network. Let's also say that some other operators support her cause, and notify her of: when I change the password; or when I change the host in the from section.

Questions:
1. Is there a recommended method of defining operators in the oper block? What I mean is that, should there be a different oper block for every single operator on the network? Is there a standard way of defining iRC Operators?
2. Based on my oper block (all other opers, services admin, network admin etc. are defined as above) how would I go about removing her O:Line or disallow her from gaining access to this O:Line?
3. Short of actually adding an AKill or a GLine for her, what else can be done?
4. It has been said many times that you should just remove the O:Line for that user, but in the above example, doing so (removing the O:Line) would actually stop legitimate Operators. Is there something else that can be done?

Thanks in advance for any assistance or help with regards to this matter. I was going to put this in the Unreal Support forum, but on retrospect it didn't quite warrant "unreal support". So I placed it here.


MiRe

Re: Scenario: Denying Operator Access To An Operator

Posted: Mon Feb 28, 2011 8:20 pm
by seraphim
First you should use a single OLine for each opers, secondly you can narrow down the allowed hostnames for using that OLine with the oper::from::userhost directive.

If you define a OLine for each oper you can set different permission, eg for can_override, depending on the experience and rationality the oper shows.

Also make sure that not anyone has direct access to the config files to prevent the use of other OLines by knowing the passwords (cloaking them helps a bit).

Re: Scenario: Denying Operator Access To An Operator

Posted: Mon Feb 28, 2011 8:29 pm
by katsklaw
#1 is the standard, 1 oper block per oper, you may have several userhost masks in the oper block, but generally 1 block per oper.
#2 With the method used in #1, if/when you remove her O:Line you simply comment or delete her oper block then /rehash the ircd. There is no need to change passwords, let anyone else know etc. This also makes it so even if she has friends, they can't just give her the new passwd.
#3 the userhost field is menat to have a restrictive host and not *@*. More like *user@*.some-isp.net. the more restrictive the better.

This will work to your advantage 2 fold.
1> Melisa's friends can't share their O:Line with her.
2> in the even an opers password is leaked, the /oper attempt will still fail because any user that tries to use the leaked password will fail due to a host mismatch.

Re: Scenario: Denying Operator Access To An Operator

Posted: Tue Mar 01, 2011 4:56 am
by Stealth
Proper O:Line removal usually goes like this:
1) Remove the oper block (comment it or delete it from the conf)
2) Rehash the configuration
3) KILL the oper (most effective forced-logout)

As katsklaw pointed out: This is why there is a need to have multiple oper blocks. You never want sharing, and you want each block as restrictive as possible.

Re: Scenario: Denying Operator Access To An Operator

Posted: Tue Mar 01, 2011 10:10 am
by Jobe1986
Stealth wrote:and you want each block as restrictive as possible.
Included in that is not only the host mask restrictions but also do not give an oper more access then he/she really needs.

For example I would for a BOPM only use the can_gzline flag (Unreal gives it the global flag automatically for flags that require global, but because you don't explcitly give the oper block the global flag, the flags the global flag normally gives are not given)

Re: Scenario: Denying Operator Access To An Operator

Posted: Tue Mar 01, 2011 1:24 pm
by MiRe
Firstly, I want to say thank you for all the help and information you all have given, it isn't said enough, but it should be. So thank you, seraphim, katsklaw, Stealth and Jobe1986; you're help and information has been greatly appreciated by this novice.

Secondly after having some time to think through this new information, I see where I was going wrong, and how difficult it would have been to control abusive operators should things ever come to that. I have a new understanding of how the oper block should be defined. My only difficulty is, being an innately lazy person, is the struggle it would be to ensure that each individual server on the network contains the correct oper block. My research indicates that I can put the oper block in a file called "oper.conf" and include it in the "include" section of Unreal's configuration file. Am I correct in assuming this?

Thirdly, I have a few more questions (well sort of questions), that if possible, I would kindly like some clarification on.
Jobe1986 wrote:Included in that is not only the host mask restrictions but also do not give an oper more access then he/she really needs.
1. This I understand, and during my planning I was very aware of not giving operator more access than what is really needed. But with regards to the hostmask restrictions I have some trouble with it. Our ISP is, let's just say is less than you're worst, and as such iRCDs tend to mask all of the hostmask, for example

Code: Select all

[Tue 08:17:31 am] <Global> LOGUSERS: MiRe[Bot]|Work (~MiReBot@99.99.999.999 => 27BC2FEA.524F2544.6766754.IP) (MiRe[Bot]|Work) [99.99.999.999] connected to the network (irc.network.net).
How would you apply a hostmask restriction for the above, keeping in mind that the IPs are dynamic?
My thoughts tend towards these:

Code: Select all

userhost MiReBot@*.IP; *@*.*.*.IP; MiReBot@*.*.*.IP;
2. I believe the answer to this next question is "no". During my tests it would appear that each oper block definition must be statically defined on each server on the network, and that this must be the same for eery server on the network. Simply, for Network1, Server A must have the same oper block as Server B, Server C and so on. The question is, is it possible for one hub server to have an oper block defined, that is then filtered throughout the network? I don't think it is, but if it is, how is that done? (My limited tests revealed that it isn't. It indicates that if there is an oper block defined on Server A, but isn't defined on Server B, that operator must connect to Server A in order to oper up. Otherwise that operator would get no O:Lines found for your host.)

3. After having read this http://forums.unrealircd.com/viewtopic.php?t=4181 with regards to using SSL Certs for passwords. I'm leaning towards a "no" to this question: Would I have to run "makeNewCert.bat" for each operator to be defined? Or do I simply run it once and rename the "cert.pem" to "opernick.pem"?

Again thanks for any assistance that can be given, and thanks for all that have been given.


MiRe

Re: Scenario: Denying Operator Access To An Operator

Posted: Tue Mar 01, 2011 4:13 pm
by Stealth
1) The oper block goes off the real host of the user, so if your user cannot be resolved you want to find a common section of their IP address to go by. Usually the first segment of their IP will always be the same. Using your example, you'd want

Code: Select all

userhost MiReBot@99.*;
2) The best way to get the opers on all your servers consistently would be to use remote includes. Load the opers.conf file in a password protected web server directory, and use this in your conf:

Code: Select all

include https://user:password@www.example.com/secret/opers.conf;
Note: You will have to compile Unreal with remote include support to use this method. If you cannot compile with remote include support, there are ways around this limitation by using scripts to automatically download updates and rehash Unreal. The Win32 build of Unreal is precompiled with this feature.

3) Each oper would need their own cert, and they should generate these certs themselves. Once they have their key and cert installed in their client, the would give you the cert part and keep their key a secret. If someone else gets their key, that person could also use it to oper with that opers credentials. If they are lazy and don't want to download or read stuff, they can use my online cert generation tool at https://unreal.x-tab.org/cert.php

Re: Scenario: Denying Operator Access To An Operator

Posted: Tue Mar 01, 2011 4:45 pm
by katsklaw
IRC administration isn't for the lazy. Even lazy admins find that they have much work to do.

Another secure option to restricting userhosts is using sslclientcerts. It requires the oper to connect via ssl and to create and configure both their client and the ircd to use the key. However, in some most cases I've found that while it's the most upfront configuration, it's the least configuration to maintain as you can still use a hostmask of *@* and still be rather secure as it uses a ssl generated key file as the password instead of a text string so there is no password to guess and there is no need to maintain a restrictive list of userhosts to manage for all your opers.

Instructions on how to use ssl client certs is found: http://forums.unrealircd.com/viewtopic. ... 81&p=21634

SSL Certs can't be used on all client software but the most popular does support it.

Re: Scenario: Denying Operator Access To An Operator

Posted: Tue Mar 01, 2011 6:29 pm
by MiRe
Once again thanks to Stealth, and katsklaw for your responses and help.
Stealth wrote:1) The oper block goes off the real host of the user, so if your user cannot be resolved you want to find a common section of their IP address to go by. Usually the first segment of their IP will always be the same. Using your example, you'd want

Code: Select all

userhost MiReBot@99.*;
This is exactly the issue I'm having with my ISP (our only ISP mind you). Our IP ranges are a tad too random to draw a consistent value from. We may have an IP that starts with a 70 value, a 60 value, even a 200 value. So unless the person (the operator) is on a more stable IP range I don't foresee me being able to utilize the hostmask in this regard.
What I would have to do is utilize what katsklaw suggested and use the SSL Cert method using a hostmask of *@*, and force a prospective oper to do the procedure him/herself and send me the cert to add in their O:Line. No cert, no O:Line.
katsklaw wrote:IRC administration isn't for the lazy. Even lazy admins find that they have much work to do.
LOL! Isn't that the truth, I'm finding that out now. Although I kind of misspoke when I said I was innately lazy. What I meant is that I like to have clear cut procedures for doing things, that get to the heart of the solution efficiently and eloquently. But I'm working my butt off to ensure I know as much as I can, so I can teach those operators on my network when the time comes.
Stealth wrote:2) The best way to get the opers on all your servers consistently would be to use remote includes. Load the opers.conf file in a password protected web server directory, and use this in your conf:

Code: Select all

include https://user:password@www.example.com/secret/opers.conf;
Note: You will have to compile Unreal with remote include support to use this method. If you cannot compile with remote include support, there are ways around this limitation by using scripts to automatically download updates and rehash Unreal. The Win32 build of Unreal is precompiled with this feature.
I was wondering about this and asking myself "How on earth do IRC Admins keep track of all this stuff?" now I know. I don't have my own domain name yet, but I'll find a way to test this remote include, and since I'm using the Win32 build of Unreal I should have no problems with remote includes.

There's one very last thing that has been puzzling me, and I'm wondering if it is because of how my network is currently set up, or if it is something inherent to Unreal. I used to use Rizon which I know is a different iRCD (hybrid-plexus), oftentimes I would see their Services go down and if I had a bot from BotServ I would see it has left due to a netsplit (where NetSplit is said as the quit message). I have two linked servers and Services (Anope) connected to one them, let's call that Server B. Now if I restart services and the BotServ bot leaves I see:

Code: Select all

[Tue 02:12:22 pm] * &Opers (Opers@Supreme.IRC.Operator) Quit (irc.networkb.net irc.services.net)
Let me be absolutely clear: I have no issue with what it displays for the net split, I'm just curious as to if it is something that it always displayed (i.e. displaying which servers have split) regardless of the size of my network, or does it only display that because of the size of my network?

MiRe

Re: Scenario: Denying Operator Access To An Operator

Posted: Tue Mar 01, 2011 6:52 pm
by Stealth
This is exactly the issue I'm having with my ISP (our only ISP mind you). Our IP ranges are a tad too random to draw a consistent value from. We may have an IP that starts with a 70 value, a 60 value, even a 200 value. So unless the person (the operator) is on a more stable IP range I don't foresee me being able to utilize the hostmask in this regard.
If you wanted to use password authentication you could still use it. Just specify multiple userhost lines:

Code: Select all

oper MrSmith {
  from {
    userhost MiReBot@99.*;
    userhost MiReBot@70.*;
    userhost MiReBot@200.*
    userhost MiReBot@60.*;
  };
  ...
};
This would still narrow down the people who can use your O:Line. If you google around a bit you can find out what public subnets your ISP owns and make proper oper blocks for those subnets.
There's one very last thing that has been puzzling me, and I'm wondering if it is because of how my network is currently set up, or if it is something inherent to Unreal. I used to use Rizon which I know is a different iRCD (hybrid-plexus), oftentimes I would see their Services go down and if I had a bot from BotServ I would see it has left due to a netsplit (where NetSplit is said as the quit message). I have two linked servers and Services (Anope) connected to one them, let's call that Server B. Now if I restart services and the BotServ bot leaves I see:
This is somewhat a standard between servers to let users know there was a netsplit. Some servers mask it, and you might see "*.net *.split" or "*.example.com *'example.com".

Re: Scenario: Denying Operator Access To An Operator

Posted: Tue Mar 01, 2011 7:55 pm
by MiRe
After reading what you said I did some digging, and I found some information about an option to hide net splits here: http://dev.unrealircd.com/documentation ... s_optional. Unfortunately I did some more digging and found that this version of Unreal is no longer in development. Which then led me back to this page: http://www.unrealircd.com/devel.php.
So I'll be correct in assuming that the option option:hidesplits is not implemented in the latest stable version?

And with that I would like to say thanks again to all those that helped. Keep up the good work Unreal, and I'm really looking forward to the new release!

MiRe

Re: Scenario: Denying Operator Access To An Operator

Posted: Wed Mar 02, 2011 2:46 am
by katsklaw
The features and options available for your version of Unreal are located in the docs/unreal32docs.html file. The docs for the latest cvs version, which is 3.2.9-rc1 are located at: http://www.unrealircd.com/files/docs/unreal32docs.html This same url can be accessed by clicking the "configuration" link in my signature.