Services admin channel and associated help for admins/mods

[DanielOaks]

Most services packages have the idea of 'services channels', channels where e.g. vhost requests are dumped into so that vhost helpers can see them and know there's new ones to approve/reject. Or a channel where possible abuse detections are logged, where klines/dlines/etc are logged, etcetc. That might be useful for certain types of mod teams, and it's a concept we may wanna look into at some point depending on the needs of server admins.

Related to the UBAN command, some admins find it useful to monitor for certain kinds of connections after klining a user. RWATCH was brought up in that chat. It might be an interesting idea that after we set a ban on an account, the IPs associated with that account have something akin to an RWATCH placed on them for some length of time (10m? 30? etc), so that if e.g. they hop on another irc client and try to reconnect admins/mods sitting in the services channel will see that suspicious behaviour and know what's going on.

This is something that's a very definite... maybe? IDK. It's something that other services packages have, and I think networks generally may find useful (having a defined channel / or a few, where services automagically dumps certain kinds of notices and information to 'on call' admins), but that sort of thing might not be useful and may only be useful to groups that reach a certain size. I think this sorta thing'll need a few justifications for it before we seriously consider adding it, but hey that's what this issue is for!

[prdes]

So basically I've been having this chap, calls himself: DOOM. And they are severe ban evaders. For about 2-3 months they would actively ban evade and then now they seem to be back. He gets upset because the nick doom got banned as the ban added an SQLINE. And his variations on that nick d00m and duum etc keep getting banned but there are a lot of permutations and combinations. So I have /msg OperServ RWATCH ADD /^d.*m!/iS <reason> added and so basically the S means it will send the notification in the #services channel or as they call it "SNOOP" channel. In the reason I typed 2-3 of us ircops nicks so that it will highlight us if any nick starts with d and ends with m.

I have no idea about how feasible this is but UBANs could maybe add various related parameters such as the ip, hosts and possibly even realname and username (configurable) to RWATCH besides manually being able to add these. Of course the <reason> in RWATCH would have to carry over not only the reason for the ban but the association of this RWATCH to said ban. For example UBAN ADD <account> <reason> will suspend the account indefinitely and then it will add the ip's associated with that account to watch-list and it will need to preserve:

• The association between the account and the ip
• The reason for that ban
• The banner
• Date of Ban
• Something else which may be configurable?

Similarly, if you ban an IP it should add the nick currently associated maybe?

@DanielOaks "the IPs associated with that account have something akin to an RWATCH placed on them for some length of time (10m? 30? etc),"

Why would it need to expire by default?

[slingamn]

Seems like you could do a lot of this with a bot that watches snomasks and parses them?

[prdes]

@slingamn I already do this and am planning to enhance it but for example

1. When a uban is added the responses aren't machine readable as in they aren't standardized which is to be expected since it is unique and also very new which makes it difficult to maintain a bot and also you have to heavily start using labeled-response with batch support which is hard to implement (for me at least).
2. You are already taking the effort of informing the user about the collateral and various other information about the clients killed. It is probably better to have it be more useful because:
   a. People forget
   b. The operator who added the ban may be offline and the ones who come online will not have any context or warnings.
3. It's just a superb monitoring tool in my opinion you can just add the regex and the reason; and walk away with the confidence that those nicks realnames hosts/ips will raise alarms and with context so that abuse can be prevented rather than reacted to (often late).

I can see why this would not be something to add immediately as it probably requires a considerable amount of work but relying on a bot for this is hard due to there not being a proper existing implementation especially with all the new uban and ever-changing landscape of oragono is probably not ideal.

[slingamn]

I don't recommend trying to automate UBAN itself with a bot, but the RWATCH and "services channel" functionality seems like it can be automated by parsing snomasks.