Anope Bug Tracker - Anope Stable (2.0.x series)
View Issue Details
0001358Anope Stable (2.0.x series)[All Projects] Generalpublic2011-11-03 20:092019-01-08 05:42
Robby 
 
normalfeatureN/A
newopen 
0001358: A notify/flag system that notifies opers that a client matching a pattern has connected to the network
This is maybe a rather big and complex feature request, but since 1.9 is in dev and new features are being added I can only try.

So, it's for notifying IRCops when a client matching a pattern in the form of nick!ident@address (where address is a hostname or IP/CIDR, even if their IP resolves to a hostname), perhaps even match against the gecos field of the connecting client.

Currently I have an opered bot running that provides this functionality and outputs to a specific IRCop-only channel (and thus not the log channel as else it would be easily missed as things scroll by). We currently use this to find abusive and malicious clients more easily. Of course there's always some false positives depending on the pattern used but that's not something services should care about. The bot does the following:
- pattern matching against connecting clients and say if a matching connecting client was found and add it to memory/list in case they change nicks
  it outputs like this: NOTIFY: Connected: nick (~ident@address) (gecos)
- take into account nickchanges (explained further below)
  outputs like this: NOTIFY: Nickchange: oldnick -> newnick
- say when they quit (including quit message) and remove user from memory/list
  outputs like this: NOTIFY: Quit: nick (~ident@address) [quitreason]

It would be nice if Anope had something like this aswell.

This system should however also keep track of nickchanges that the client could possibly do and output those to the notifychannel aswell, especially when using patterns in the form of *abuser*!*@* because if the user changes his nick from Abuser44 to EvilUser for example, the pattern wouldn't match anymore. Also, link the pattern matched to the user, for example for use in /OS NOTIFY CLIENTS (explained below).

If this were to get approved, I'm thinking a command syntax like AKILL should be used:
NOTIFY ADD [+expiry] mask reason
^- maybe add a switch for when mask should match against the gecos and not a hostmask
NOTIFY DEL {mask | entry-num | list | id}
^- also this command should remove/cleanup any clients in CLIENTS when the pattern they were matched by gets removed unless they still match another pattern, in which case the entry in CLIENTS should be updated
NOTIFY LIST [mask | list | id]
NOTIFY VIEW [mask | list | id]
NOTIFY CLEAR
And the addition of a CLIENTS subcommand:
NOTIFY CLIENTS -> This one lists clients online found after a match, with their current nickname including their ident@address, and the pattern against which they matched, like this:
-OperServ- Current notify-matched clients online:
-OperServ- 1 nick (~ident@address) - realname
-OperServ- Matched against: pattern
-OperServ- Reason: reason
For example:
<Robby> NOTIFY CLIENTS
-OperServ- Current notify-matched clients online:
-OperServ- 1 Abuser44 (~abuser@blah-874864.isp.com) - Bleh Blah
-OperServ- Matched against: *abuser*!*@*
-OperServ- Reason: Abusive user
-OperServ- 2 EvilUser (~abuser@blah-874864.isp.com) - All Your Base
-OperServ- Matched against: *abuser*!*@*
-OperServ- Reason: Abusive user
Maybe also have CLIENTS take a pattern as parameter, like LIST and VIEW already do.

And a configurable notifychannel (an IRCop-only channel for example) in the OperServ configuration file.

Output to the notifychannel should ideally be similar to my current bot but with some slight changes:
Connecting (if matching against hostmask):
<OperServ> NOTIFY: Connected: nick (~ident@address) [Matched against <pattern>]
Connecting (if matching against gecos):
<OperServ> NOTIFY: Connected: nick (~ident@address) (gecos) [Matched against <pattern>]
Changing nick:
<OperServ> NOTIFY: Nickchange: oldnick -> newnick
Quit:
<OperServ> NOTIFY: Quit: nick (~ident@address) [quitreason]


Maybe also add a switch to the ADD command to flag the matched client for extra "surveillance", so that it also shows what the client does on the network. For example: the channels it joins, parts, gets kicked from, or what modes or topics it sets on those channels (can help in finding a botnet(-master)), or if it kicks someone from a channel or when it changes it's own umodes (in short: everything :P). Output to the notifychannel something like this:
<OperServ> FLAGGED: nick joined #channel
<OperServ> FLAGGED: nick left #channel
<OperServ> FLAGGED: nick was kicked from #channel
<OperServ> FLAGGED: nick has kicked othernick from #channel --> should be disableable
<OperServ> FLAGGED: nick sets mode on #channel: <mode> --> should be disableable
<OperServ> FLAGGED: nick sets topic on #channel: <topic> --> should be disableable
<OperServ> FLAGGED: nick sets umode: <umode> --> should be disableable
Note that I left out part and kick messages, as this is not really needed here, it's just to get an idea of what the client does on the network.



I'll leave it at this for now as this is getting fairly long.
No tags attached.
Issue History
2011-11-03 20:09RobbyNew Issue
2012-03-29 16:19MathK1LLNote Added: 0006128
2012-03-29 22:30cronusNote Added: 0006129
2013-12-19 06:35YoergerNote Added: 0006556
2016-07-02 16:03RobbyProjectAnope Development (1.9.x series) => Anope Stable (2.0.x series)
2016-07-02 16:03RobbyCategoryOperserv => General
2019-01-08 05:42genius3000Note Added: 0006854

Notes
(0006854)
genius3000   
2019-01-08 05:42   
Would love to see this implemented in 2.1/3.0 yet. For 2.0, I've wrote a 3rd party module: https://modules.anope.org/index.php?page=view&id=283 [^]
(0006556)
Yoerger   
2013-12-19 06:35   
I like this idea.
(0006129)
cronus   
2012-03-29 22:30   
I'm all for it, Possibly even expand it further somehow.
(0006128)
MathK1LL   
2012-03-29 16:19   
I love this idea.