View Issue Details

IDProjectCategoryView StatusLast Update
0002201unrealircdpublic2004-12-11 21:14
ReporterStealth Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status closedResolutionopen 
Summary0002201: Command "blocking"
DescriptionCoders probably won't like this... but please hear me out!

I am now seeing more and more people wanting to block commands from users, and a lot of them actually have a good reason. I have asked in the forums for someone to make a module that does this, but no one has yet. The closest any module has come to blocking commands is AngryWolf's CommandShun. This, however was designed to temporarily block commands by addresses, and was not intended to block commands from users.

What I am suggesting is a conf block that will "block" the specified commands from being used by non-opers. Of course such a feature should not be able to block vital commands such as: NICK, USER, PASS, VERSION, MODULE, OPER, INFO, CREDITS, LICENSE etc. Or be limited to certain commands, such as: MAP, LINKS, LIST, WHO, LUSERS, AWAY, HELPOP, TIME, DNS, SETNAME, etc.

The format of the block should be like deny channel, or ban nick:

deny command {
  command list;
  reason "Don't look at my channels!";
  warn on;
};

When a user attempts to use a command, it should send a message to the user saying they cannot use the command. If warn is set, it should warn opers with snomask e.
TagsNo tags attached.
3rd party modules

Activities

codemastr

2004-11-29 13:36

reporter   ~0008430

[quote]and a lot of them actually have a good reason[/quote]
Yet, just like everytime this has been suggested, you don't tell us what these "good reasons" are! I see no good reason, I just see problems:

MAP - It's useful to be able to find another server on the network
LINKS - It's useful to be able to find another server on the network
LIST - How do you know what channels to join?
WHO - *MANY* clients use this for their IAL features, which would now be broken
LUSERS - Auto sent on connect, some clients expect this and require it to complete a connection
AWAY
HELPOP - How is preventing users from receiving help a good thing?
TIME - What about when I need to know what timezone the server is in, say for a /whowas reply?
DNS - Users can't do anything with it anyway, so what's the big deal
SETNAME - /quit | /realname MyNewName | /reconnect same effect, so what's the problem?

This will *definately not* be added unless someone can give me a very good reason why it is needed. Since this was first suggested over a year ago, I still have received no such reason but I am always informed that "good reasons" do exist.

Stealth

2004-11-29 19:10

reporter   ~0008440

Last edited: 2004-11-29 19:12

Paranoid admins who dont want anyone but opers to know the full list of servers on a network, can use it to disable MAP and LINKS... even though they dont understand a list can be made from WHO and WHOIS.

Private networks who have channels that are there for groups, and they dont want people to find channels and cause disruptions, can disable LIST. Also, list can be disabled on networks with a high user rate, but low bandwidth to save bandwidth. This will probably be used by lazy admins that don't want to edit the conf to lock +s.

Some would like to disable who, I do not know why, but it was an example.

Some feel that disabling LUSERS can save bandwidth, speed up connections, or they just feel it would make their network more secure (more paranoia).

Away can be disabled if admins don't want their users to set away, away does take unnessasary bandwidth and is more of a luxury IRC feature to begin with. Also away can be disabled if they have a major spam problem that would be difficult to block with spamfilter.

HELPOP can easily be used for flooding opers with +h, and you yourself say it is useless and want to remove the whole system anyway, so I do not know why you wish to dispute it so much.

TIME is another luxury IRC feature, and I don't know of any "normal" users that use it "know what timezone the server is in, say for a /whowas reply".

DNS is a paranoia thing.

Disabling SETNAME will make it more work for users to change their real name to evade channels that actually have realname bans. Having this feature available to normal users makes the real name ban worthless.


Of course I would like to point out the commands listed are examples, and this feature can be limited to commands that the coders feel someone might actually have a good reason to disable.


EDIT: Forgot to mention, that this will make paraniod admins happy, and having a block in the core is much more efficient than making a module to do it. Perhaps instead of adding this to Unreal, you can make a module that is actually designed for it.

codemastr

2004-11-29 22:45

reporter   ~0008442

Last edited: 2004-11-29 22:47

[quote]Paranoid admins who dont want anyone but opers to know the full list of servers on a network, can use it to disable MAP and LINKS... even though they dont understand a list can be made from WHO and WHOIS.[/quote]
Exactly why this should NOT be added. It gives a false sense of security, not real security. Why not just add set::make-ircd-secure on;, and have it do nothing? It would serve the same purpose.

[quote]This will probably be used by lazy admins that don't want to edit the conf to lock +s.[/quote]
Let me see if I understand, they don't want to type set { modes-on-join "+s"; restrict-channelmodes "s"; }; however, they will type deny command { command list; reason "No listing"; warn on; };? My guess is, if they are too lazy to lock +s, then they are certainly too lazy to disable the command.

[quote]Some feel that disabling LUSERS can save bandwidth, speed up connections, or they just feel it would make their network more secure (more paranoia).[/quote]
Again though, it's a false sense of security. Why do we want to make admins *think* their server is secure when we know very well it is not? Again, I could just add set::make-ircd-secure and accomplish the same goal.

[quote]Away can be disabled if admins don't want their users to set away, away does take unnessasary bandwidth and is more of a luxury IRC feature to begin with. Also away can be disabled if they have a major spam problem that would be difficult to block with spamfilter.[/quote]
You could already do this anyway, setup an away spamfilter with a regex of ".*"

[quote]HELPOP can easily be used for flooding opers with +h, and you yourself say it is useless and want to remove the whole system anyway, so I do not know why you wish to dispute it so much.[/quote] First, I never said I'd remove helpop, I said I'd remove the +h component of it. Secondly, it was already pointed out that helpop has an ignore list which can already be used to stop flooding, or if you want, you can use it to ignore everyone and effectively disable this command. But if someone is flooding, that is what /kill is for. But, in my experience as an oper, I've never seen a helpops flood.

[quote]TIME is another luxury IRC feature, and I don't know of any "normal" users that use it "know what timezone the server is in, say for a /whowas reply".[/quote]
"Luxury" RFC1459 required, same difference? I know of many users who do this, I do it! When I do a /whowas, and it says "last seen mon nov 15 2:00, how do I know when 2:00 was? Now if it's in my timezone, I was probably asleep. However, if that was GMT-12, then I wasn't.

[quote]DNS is a paranoia thing.[/quote]
Once again, false sense of security. If you are so paranoid, why run an IRCd to begin with? The first rule of security is never let anyone in. Once you open the door, you ask for trouble. So therefore, if you're paranoid, don't run servers.

[quote]Disabling SETNAME will make it more work for users to change their real name to evade channels that actually have realname bans. Having this feature available to normal users makes the real name ban worthless.[/quote]
No it doesn't. You see, you assume what you think realname bans are, though you are incorrect. It's not to keep users out. Banning users based on realname is utterly stupid! It's to keep *drones* out. For example, say XDCC bots all use a realname of "I'm an XDCC bot" and you don't want XDCC bots, so you ban that. It's not meant to keep people out, it's meant to keep drones out. It's also meant as a "filter." I don't want anyone with swearing in their realname to join, so I ban the curse words. However, they are more than welcome to join if they change their realname. In the same regard, you could argue ~c is useless because once they part the +b ~c'ed channel, they can join. But in reality, that is the goal!

[quote]Of course I would like to point out the commands listed are examples, and this feature can be limited to commands that the coders feel someone might actually have a good reason to disable.[/quote]
I can't come up with a good reason to disable any commands!

[quote]Forgot to mention, that this will make paraniod admins happy, and having a block in the core is much more efficient than making a module to do it. Perhaps instead of adding this to Unreal, you can make a module that is actually designed for it.[/quote]
Again, false sense of security. Second, it wouldn't be "much more" efficient, it would be almost exactly the same efficiency. The code would be 99.9% the same. There would be 1 less function call, so one less "call" operation, which in the grand scheme of things, is really a minor operation. It would be slightly more efficient, but not "much more."

aquanight

2004-11-30 01:02

reporter   ~0008443

Last edited: 2004-11-30 01:03

[quote]Let me see if I understand, they don't want to type set { modes-on-join "+s"; restrict-channelmodes "s"; }; however, they will type deny command { command list; reason "No listing"; warn on; };? My guess is, if they are too lazy to lock +s, then they are certainly too lazy to disable the command.[/quote]

Actually in this case there's a bit of difference here. It's a question of what the users see. If a user types /list and sees an empty list of channels, what do you think he or she is going to do? If it were me, I'd probably just /quit. But if I typed /list and saw "*** Notice -- Use of LIST command is disabled on this server." I might think, "maybe the server had a recent botnet attack and just disabled /list to thwart them from finding channels" or "maybe the server has a bot with improved channel listing capabilities and the server is telling me to use that instead *reads MOTD*". Then I /whois some people I know to find the channels I'm looking for. This gives admins a chance to explain why they disabled LIST, instead of putting the reason in the MOTD, and how many users do you know read the MOTD? :P

@Links/map: the idea is probably to hide your dedicated hubs (especially services hub(s)). While there's the DNS trick to prevent the Bad Guys from getting the IP, it may be better to simply not allow them to know these servers exist at all. Although /who and /whois can help them find the client servers (since they connect to those anyway :/ ), they won't be able to find dedicated hubs (which usually have bigger targets on their heads than client servers, especially if one or more of them are unfortunate enough to host the nameserver(s)) if there are no clients on them :) . And what if I really don't care for users to know the layout of my network? :-)

[quote]When I do a /whowas, and it says "last seen mon nov 15 2:00, how do I know when 2:00 was? Now if it's in my timezone, I was probably asleep. However, if that was GMT-12, then I wasn't.[/quote]

If I recall, isn't the time in whowas sent as a TS (and translated by the client)?

syzop

2004-11-30 18:57

administrator   ~0008444

[quote]@Links/map: the idea is probably to hide your dedicated hubs (especially services hub(s)). While there's the DNS trick to prevent the Bad Guys from getting the IP, it may be better to simply not allow them to know these servers exist at all.[/quote]

I fail to see this logic. Again, false sense of security == worse than no security, people might (read: 'will') even not use the DNS-trick if such a thing existed.

[quote]Although /who and /whois can help them find the client servers (since they connect to those anyway :/ ), they won't be able to find dedicated hubs[/quote]

.. which hardly matters anything since their hostname doesn't resolve..

[quote]And what if I really don't care for users to know the layout of my network? :-)[/quote]
Then you use set::options::flat-map. Which btw still doesn't protect 100% since you can still build a map based on splits and stuff, but it does help quite a bit.

[quote]If I recall, isn't the time in whowas sent as a TS (and translated by the client)?[/quote]
No, /whowas is a nice exception.

Issue History

Date Modified Username Field Change
2004-11-29 00:09 Stealth New Issue
2004-11-29 13:36 codemastr Note Added: 0008430
2004-11-29 19:10 Stealth Note Added: 0008440
2004-11-29 19:12 Stealth Note Edited: 0008440
2004-11-29 22:45 codemastr Note Added: 0008442
2004-11-29 22:47 codemastr Note Edited: 0008442
2004-11-30 01:02 aquanight Note Added: 0008443
2004-11-30 01:03 aquanight Note Edited: 0008443
2004-11-30 18:57 syzop Note Added: 0008444
2004-12-11 21:14 syzop Status new => closed