0001358: A notify/flag system that notifies opers that a client matching a pattern has connected to the network

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0001358

Anope Stable (2.0.x series)

[All Projects] General

public

2011-11-03 20:09

2019-01-08 05:42

Reporter

Robby

Assigned To

Priority

normal

Severity

feature

Reproducibility

N/A

Status

new

Resolution

open

Platform

OS Version

Summary

0001358: A notify/flag system that notifies opers that a client matching a pattern has connected to the network

Description

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.

Notes
(0006854) genius3000 (reporter) 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 (developer) 2013-12-19 06:35	I like this idea.

(0006129) cronus (developer) 2012-03-29 22:30	I'm all for it, Possibly even expand it further somehow.

(0006128) MathK1LL (reporter) 2012-03-29 16:19	I love this idea.

Issue History
Date Modified	Username	Field	Change
2011-11-03 20:09	Robby	New Issue
2012-03-29 16:19	MathK1LL	Note Added: 0006128
2012-03-29 22:30	cronus	Note Added: 0006129
2013-12-19 06:35	Yoerger	Note Added: 0006556
2016-07-02 16:03	Robby	Project	Anope Development (1.9.x series) => Anope Stable (2.0.x series)
2016-07-02 16:03	Robby	Category	Operserv => General
2019-01-08 05:42	genius3000	Note Added: 0006854

Relationships