[DONE] Anti mass highlight module.

Need a module converted from 3.2.x to UnrealIRCd 4? Or looking for a certain module? Ask here.

Moderators: Gottem, Supporters

Post Reply
The_Myth
Posts: 12
Joined: Tue Jun 27, 2017 4:42 pm

[DONE] Anti mass highlight module.

Post by The_Myth » Sun Aug 13, 2017 9:05 am

Okay, I've found this while surfing on the internet. Seems that InspIRCd have developed an anti mass highlight module. It can be found here:
https://github.com/inspircd/inspircd-ex ... hlight.cpp
Indeed I think that should be ported to UnrealIRCd since it's a great idea.
Maybe adding a block into unrealircd.conf like:
blockhighlights {
maxnicks 5;
/* Maximum number of nicknames to be highlighted in one line */
action gline; /* What to do in case of mass highlight */
duration 7d; /* Duration of the ban */
reason "Mass highlight isn't appreciated on this network"; /* Ban reason */
};
This would be good also, because spammers constantly changed their "publicity" lines, so spamfilter becomes ineffective quickly. But they usually use the max number possible of highlighted nicks in one line.
What do you think?
PeGaSuS

Gottem
Posts: 133
Joined: Fri Aug 19, 2016 5:26 pm
Location: NL

Re: [REQUEST] Anti mass highlight module.

Post by Gottem » Sun Aug 13, 2017 1:13 pm

I've thought about this before, but I held off on writing it because I personally didn't have any use for it and I didn't see anyone else requesting this either. :>

It's not too hard to write, but we should also take into account when they do break it up over multiple lines:

Code: Select all

<somebot> nick1 nick2
<somebot> nick3 nick4
<somebot> nick5 nick6
......
So I'm thinking, what if we keep counting the amount of highlights until they have a line without one at all? So above example would result in nicks = 6 so the block/ban would set in anyways. As always, opers and U:Lines will be exempted from this. ;]

Also, should we count per user per channel, or simply per user? The first one would mean they can highlight up to "maxnicks" people in every channel. The latter would also ban them if they said one nick across 6 channels. InspIRCd seems to be doing the per channel thing, which is the most efficient.

As for actions, how about: block (drop silently), notice (drop, but send the "reason" to the user), gline and gzline (some people prefer IP-based bans so makes sense to me to have both those options)? =] For block and drop, I would prevent them from highlighting people again for the "duration" specified.
If you like my modules, pls consider donating (through PayPal) or becoming a monthly Patron ;];]

The_Myth
Posts: 12
Joined: Tue Jun 27, 2017 4:42 pm

Re: [REQUEST] Anti mass highlight module.

Post by The_Myth » Sun Aug 13, 2017 2:17 pm

So I'm thinking, what if we keep counting the amount of highlights until they have a line without one at all?
even better
Also, should we count per user per channel, or simply per user?
per channel seems more effective.
As for actions, how about: block (drop silently), notice (drop, but send the "reason" to the user), gline and gzline (some people prefer IP-based bans so makes sense to me to have both those options)?
that's perfect
PeGaSuS

Gottem
Posts: 133
Joined: Fri Aug 19, 2016 5:26 pm
Location: NL

Re: [REQUEST] Anti mass highlight module.

Post by Gottem » Wed Aug 16, 2017 12:41 am

Module's well on the way, I just need to do some deeper testing. ;] Also I ended up making a few changes from above, but I'll explain that in a later post. =]
If you like my modules, pls consider donating (through PayPal) or becoming a monthly Patron ;];]

Gottem
Posts: 133
Joined: Fri Aug 19, 2016 5:26 pm
Location: NL

Re: [DONE] Anti mass highlight module.

Post by Gottem » Wed Aug 16, 2017 6:43 pm

Aye we good fam.

It keeps track of a user's messages on a per-channel basis and checks if they highlight one person too many times or too many different persons at once (as per the alternation thing mentioned earlier). Opers and U:Lines are exempt (as per usual), but also those with list modes +a and +q. When someone hits the threshold, opers with the snomask "EYES" will get a server notice through the module (enable that snomask with /mode <nick> +s +e).

Config block:
The module doesn't necessarily require any configuration, it uses the following block as defaults

Code: Select all

block_masshighlight {
	maxnicks 5;
	delimiters "     ,.-_/\:;";
	action gline;
	duration 7d;
	reason "No mass highlighting allowed";
	snotice 1;
	banident 1;
	multiline 0;
	allow_authed 0;
	//allow_accessmode o; // k4be
	percent 1; // k4be
	show_opers_origmsg 1; // k4be
};
  • maxnicks: Maximum amount of highlights (going over this number results in action setting in) -- works in conjunction with percent
  • delimiters: List of characters to split a sentence by (don't forget the surrounding quotes ;]) -- any char not in the default list may prevent highlights anyways
  • action: Action to take, must be one of: drop (drop silently [for the offender]), notice (drop, but do show notice to them), gline, zline, shun, tempshun, kill, viruschan
  • duration: How long to gline, zline or shun for, is a "timestring" like 7d, 1h5m20s, etc
  • reason: Reason to show to the user, must be at least 4 chars long
  • snotice: Whether to send snomask notices when users cross the highlight threshold, must be 0 or 1
  • banident: When set to 1 it will ban ident@iphost, otherwise *@iphost (useful for shared ZNCs etc)
  • multiline: When set to 1 it will keep counting highlights until it encounters a line without one
  • allow_authed: When set to 1 it will let logged-in users bypass the checks
Features added/proposed by k4be:
  • allow_accessmode: Must be one of vhoaq (or omitted entirely for no exemptions [the default]), exempts everyone with at minimum the specified mode from highlight checks (e.g. a includes people with +q)
  • percent: Threshold for the amount of characters belonging to highlights, not counting delimiters (e.g. "hi nick" would be 67%) -- works in conjunction with maxnicks
  • show_opers_origmsg: Display the message that was dropped to opers with the SNO_EYES snomask set
If you omit a directive which is required for a certain action, you'll get a warning and it will proceed to use the default. It should be pretty clear what directives are required in what cases imo tbh famalam. ;];]

Also added by k4be is a channel mode +H to exempt a channel from all mass highlight checks. This can be useful for quiz channels. He also excluded duplicate nicks on the same line from counting towards the total highlight count.
Last edited by Gottem on Sun Nov 19, 2017 5:53 pm, edited 1 time in total.
Reason: merged changes
If you like my modules, pls consider donating (through PayPal) or becoming a monthly Patron ;];]

The_Myth
Posts: 12
Joined: Tue Jun 27, 2017 4:42 pm

Re: [DONE][TWEAK] Anti mass highlight module.

Post by The_Myth » Tue Sep 05, 2017 9:57 pm

I'd like to know if it's possible to implement a way that we can decide if the module should work just when several users are highlighted in one line or on the current state, and an option on the module config to choose that.
On my network I had a few cases where some users like to always use the addressed user nick on their messages, which will lead to a gline, even thought they're network regular users.
Waiting on replies. :D

EDIT
On my request, the following shouldn't trigger it
<nick>: <nick2> hi
<nick2>: <nick> hello
<nick>: <nick2> wassup?
<nick2>: <nick> nm, you?
...
PeGaSuS

Gottem
Posts: 133
Joined: Fri Aug 19, 2016 5:26 pm
Location: NL

Re: [DONE] Anti mass highlight module.

Post by Gottem » Wed Sep 06, 2017 4:54 pm

Update the module. ;] I added config directive block_masshighlight::multiline, which takes a value of 0 or 1 (and defaults to 0/off).
If you like my modules, pls consider donating (through PayPal) or becoming a monthly Patron ;];]

Gottem
Posts: 133
Joined: Fri Aug 19, 2016 5:26 pm
Location: NL

Re: [DONE] Anti mass highlight module.

Post by Gottem » Thu Sep 07, 2017 2:48 pm

The_Myth also requested 2 additional features, which are now implemented:
  • An action viruschan
  • A config directive to allow logged-in users to highlight anyways (allow_authed)
See also my earlier post for more details. =]
If you like my modules, pls consider donating (through PayPal) or becoming a monthly Patron ;];]

k4be
Posts: 17
Joined: Sun Jan 09, 2005 12:19 pm

Re: [DONE] Anti mass highlight module.

Post by k4be » Sun Nov 19, 2017 2:22 pm

I had some ideas about extending capabilities of this module, and have all of them implemented :) These changes makes the module more resource-intensive, but it should be not a problem.
Changes:
- Add channel mode +H, settable by owner (so won't work without AQ prefixes). When set, this channel is exempted from mass highlight. (Seems to be needed by some IRC quiz chans.)
- If a single nickname is mentioned in a message multiple times, count it as a single highlight. (Method of storing the nicknames is very simple, but should suffice.)
- The minimum channel privilege for a user to be not checked can be now configured.
- The contents of a suspicious message can be sent to IRC Ops (configurable).
- Normal conversation, in which a user repeatedly addresses other users, could be eventually interrupted by this module in multiline mode. To deal with this problem, it can be now configured, how many characters of a message have to actually contain a nickname, for the message to be denied. Configurable as percents (nick-containing chars / message chars). This should fix the problem mentioned by The_Myth.
- The module displayed information about setting default ban time, even if action does not require it. It is now fixed.

New config example:
EDIT by Gottem: merged into this post

Can't attach neither .patch nor .txt extension, so the patch is available here.
Last edited by Gottem on Sun Nov 19, 2017 5:53 pm, edited 1 time in total.
Reason: merged changes

Gottem
Posts: 133
Joined: Fri Aug 19, 2016 5:26 pm
Location: NL

Re: [DONE] Anti mass highlight module.

Post by Gottem » Sun Nov 19, 2017 5:54 pm

Works for me. =] I've merged your changes after reviewing them and adjusting the code style to my personal tastes. I did notice a few mistakes though:

Code: Select all

if(!strcmp(cep->ce_varname, "percent")) {
	muhcfg.got_maxnicks = 1;
Seems to me that should've been muhcfg.got_percent = 1;. So I changed it to that.
--

Also related to percent:

Code: Select all

if(tmp <= 1 || tmp > 100) {
	config_error("%s:%i: %s::%s must be an integer between 1 and 100", {snip}
But the tmp <= 1 actually makes it require an int between 2 and 100 (i.e. can't be 1). Changed it to tmp <= 0 instead.
--

Code: Select all

switch(cep->ce_vardata[0]) {
	case 'v': muhcfg.allow_chmode |= CHFL_VOICE;
	case 'h': muhcfg.allow_chmode |= CHFL_HALFOP;
	case 'o': muhcfg.allow_chmode |= CHFL_CHANOP;
#ifdef PREFIX_AQ
	case 'a': muhcfg.allow_chmode |= CHFL_CHANPROT;
	case 'q': muhcfg.allow_chmode |= CHFL_CHANOWNER;
#endif
}
None of these cases had a break statement, nor was there a default case.
--

This one was a little more problematic:

Code: Select all

if(!strstr(already_detected, werd)) {
	strncat(already_detected, werd, 1023);
First, it's not really good practice to hardcode an array size in such function calls, better use sizeof(already_detected). Also, because of the strstr(), if you had 2 nicks such as "bee" and "b" the shortest would still return a pointer (because it's also in "bee") thereby excluding it from the count (while it shouldn't). I changed this to append the user's UID and separate them all with a comma (using ircsnprintf()), so even a possible overlap of say AAAAABBBB, BBBBBAAAA and BBBBBBBBB won't match.
--

I also changed some of the variable names (and by extension, the ones in unrealircd.conf):

Code: Select all

unsigned int allow_accessmode; // Lowest channel access mode privilege to bypass the limit
unsigned short int percent; // How many characters in a message recognised as a nickname is enough for the message to be rejected
unsigned short int show_opers_origmsg; // Display the suspicious message to operators
I added these and their example/default values to my initial explanation post. I also changed your post to direct readers to mine in regards to the new configurables, so all that info is centralised into one post which helps avoiding confusion. =]

Other than that, I made some minor optimisations (like a continue here and there). View the commit diff right here.
If you like my modules, pls consider donating (through PayPal) or becoming a monthly Patron ;];]

k4be
Posts: 17
Joined: Sun Jan 09, 2005 12:19 pm

Re: [DONE] Anti mass highlight module.

Post by k4be » Sun Nov 19, 2017 6:53 pm

Gottem wrote:
Sun Nov 19, 2017 5:54 pm
Works for me. =] I've merged your changes after reviewing them and adjusting the code style to my personal tastes. I did notice a few mistakes though:

Code: Select all

if(!strcmp(cep->ce_varname, "percent")) {
	muhcfg.got_maxnicks = 1;
Seems to me that should've been muhcfg.got_percent = 1;. So I changed it to that.
--

Also related to percent:

Code: Select all

if(tmp <= 1 || tmp > 100) {
	config_error("%s:%i: %s::%s must be an integer between 1 and 100", {snip}
But the tmp <= 1 actually makes it require an int between 2 and 100 (i.e. can't be 1). Changed it to tmp <= 0 instead.
Right, this is my fault. Not enough testing.
Gottem wrote:
Sun Nov 19, 2017 5:54 pm

Code: Select all

switch(cep->ce_vardata[0]) {
	case 'v': muhcfg.allow_chmode |= CHFL_VOICE;
	case 'h': muhcfg.allow_chmode |= CHFL_HALFOP;
	case 'o': muhcfg.allow_chmode |= CHFL_CHANOP;
#ifdef PREFIX_AQ
	case 'a': muhcfg.allow_chmode |= CHFL_CHANPROT;
	case 'q': muhcfg.allow_chmode |= CHFL_CHANOWNER;
#endif
}
None of these cases had a break statement, nor was there a default case.
There has to be no "break"s. It is supposed to append all the following masks, so adding "break" breaks the concept ;) . Also I think there is no need for "defalut", because we are checking the value in masshighlight_configtest().
Gottem wrote:
Sun Nov 19, 2017 5:54 pm
Also, because of the strstr(), if you had 2 nicks such as "bee" and "b" the shortest would still return a pointer (because it's also in "bee") thereby excluding it from the count (while it shouldn't).
I decided this would be good enough ;)
Gottem wrote:
Sun Nov 19, 2017 5:54 pm
I changed this to append the user's UID and separate them all with a comma (using ircsnprintf()), so even a possible overlap of say AAAAABBBB, BBBBBAAAA and BBBBBBBBB won't match.
Good idea, did not think of using UIDs.
Thanks for your reply :)

Gottem
Posts: 133
Joined: Fri Aug 19, 2016 5:26 pm
Location: NL

Re: [DONE] Anti mass highlight module.

Post by Gottem » Sun Nov 19, 2017 7:04 pm

k4be wrote:
Sun Nov 19, 2017 6:53 pm
There has to be no "break"s. It is supposed to append all the following masks, so adding "break" breaks the concept ;) . Also I think there is no need for "defalut", because we are checking the value in masshighlight_configtest().
My bad, I read that bit too fast and thought breaks were supposed to be in there. :D Changed and committed. =] I've kept the default case though, I just feel it's good practice plus some compilers may even throw warnings/errors about it.
If you like my modules, pls consider donating (through PayPal) or becoming a monthly Patron ;];]

Post Reply