Dear genius3000,

It would be beneficial if the os_notify also would allow tracking invite's by "marked" clients to track possible mass invite spam, as this is also often an issue that occurs via botnets. Perhaps the flag i could be used as it is unoccupied as of now and it would also be intuitive.

Regards,

Koragg

Hello. I would like to thank you for the excellent module.
The join flood module helps a lot in channel and network protection, especially botnet attacks.

But I'd like to know if you could integrate the join flood with the anope EXCEPTION.

Often we run eggdrops, zncs, based on an ip. Putting the protection when you put it in crontab will automatically catch a join flood.

Would you like to integrate with EXCEPTION? So the listed ips would not join join flood protection.

Another solution would be to create a list player in the module set with ips that will not reach protection.

What do you think of that idea? If it were implemented the module would look perfect ...

Thanks again for making ....

Originally posted by @ssh5000 in 839a4fa#commitcomment-30479052

It would be useful if os_notify could have certain exceptions, at least for localhost (also the 127.0.0.1 and 0::1 IP addresses) and also services operators (perhaps it can fetch the hsst info from /ns info or even read out the host = "" part of services.conf?) to avoid services operators using this against each other or even against the network itself.

Regards,

Koragg

I've recently installed this module in my network.
It works kinda well, the problem is that you need to re-set the topic in order for it to be saved (or maybe I've done something wrong).
I think that would be a nice addition to add the ability to auto add the current topic to the topichistory as soon as we enable it on a channel.
Best regards

Dear genius3000,

Thank You very much for creating and updating this functionality to prevent abuse with people tossing cycle spammers into anyone's channels (and for preventing Anope from dying if wrong syntax is used :P)

It appears that with keepmodes if allowredirect is yes, that when one does e.g. /mode #A +x 5:300:1800:#B
that it will NOT be restored yet the form without a rediect channel, e.g. /mode #A +x 5:300:1800 does get restored.
As one cannot uxe ChanServ to set the mode and thus bypass (half)op access checking, it would be safe to allow keepmodes to restore this mode I would say. It can be useful if one has a special "dumping channel" for spammers, especially a dedicated network channel (or an own channel for such "bad eggs").

If I am not overlooking any crucial securty aspects could the module allow keepmodes to restore +x even if it has a channel parameter, so long it is a valid parameter (meaning allowredirect is set to yes)?

Regards,

Koragg

Currently ChanServ ackick doesn't trigger when a user change its nickname.
Sometimes we add "bad nicks" to the akick list to have a "clean" channel.
Unfortunately that can be bypassed by joining the channel with an ordinary nickname and changing it to a "bad nick".
I'd like to know if it's possible and feasible to create a module that would make the akick to trigger on nick change.
Thanks in advance

There's one thing that I like in Freenode:
When someone connect, identifying to some nickname via SASL you receive a notification about successful/unsuccessful login attempt.

Would it be possible to enhance Anope NickServ features to have something like that?

How it would work:

1. If account has already one or more nicknames logged in, send a notification to each user logged in about the successful/unsuccessful login attempt along with the nickname that tried to login and possibly the IP address (privacy concerns here, see note below).
2. If account has no users logged in, store the attempts and send them via memo with the details of 1.

Currently anyone can hack our account and we are not aware of anything, which is also a lack of security.
This could be possibly extended to trigger on /ns id nick password, to prevent abuses and help the end user to keep his account/nicknames protected

Thoughts on this?

NOTE

While there can be some NO's about sending the IP information to the end user, this could help that same user when reporting the situation to an IRCop providing the many details as possible, and therefore, IRCops could take measures (akill, gline, etc) against the offending user/IP

Dear genius3000,

Thank You for creating this module, it can be used well to keep unwanted channels (e.g. used by botnets) unusable. There are some things that do not appear to be as described though.

1. in the code it says it does NOT use BotServ bots yet it appears do this: a) it assigns OperServ b) it will then assign more BotServ bots in alphabetical order until the botcount is reached

2. Despite setting different kill and akill reasons in the config and reloading once again with those set to be certain, the default examples that it came with are always used as reason

3. It appears that a chantrap channel can be registered AFTER it was made a chantrap channel.

I hope that this feedback is of use to You and that if I am misunderstanding some functionality that
after some explanations I will be able to utilize it better.

Regards,

Koragg

Dear genius3000,

It appears after setting a channel trap KILL channel and applying bans to it via /SAMODE and then restarting services resulted in a services crash that could only be circumvented via unloading os_chantrap.
I will paste the most promenent errors I had received in here:
*** Error in `./services': double free or corruption (fasttop): 0x000055df3cc9b5 70 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7f39c822abfb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76fc6)[0x7f39c8230fc6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7780e)[0x7f39c823180e]
./services(ZNSt8_Rb_treeIN5Anope6stringESt4pairIKS1_S1_ESt10_Select1stIS4_ESt4l essIS1_ESaIS4_EE5eraseERS3+0x222)[0x55df3a8e3432]
./services(_ZN7Channel18RemoveModeInternalER13MessageSourceP11ChannelModeRKN5Ano pe6stringEb+0x8a)[0x55df3a8dccaa]
./services(_ZN7Channel10RemoveModeEP7BotInfoP11ChannelModeRKN5Anope6stringEb+0xe 0)[0x55df3a8ddae0]
lib/modules/os_chantrap.so(_Z10CreateChanPK12ChanTrapInfob+0x201)[0x7f39b8a798c1 ]
lib/modules/os_chantrap.so(_ZN10OSChanTrap4InitEv+0x17f)[0x7f39b8a84ecf]
./services(_ZN6Server4SyncEb+0x21f)[0x55df3a989b0f]
lib/modules/inspircd12.so(_ZN19IRCDMessageEndburst3RunER13MessageSourceRKSt6vect orIN5Anope6stringESaIS4_EE+0xdf)[0x7f39c7d5bb2f]
./services(_ZN5Anope7ProcessERKNS_6stringE+0x1976)[0x55df3a968d06]
./services(_ZN12UplinkSocket11ProcessReadEv+0x50)[0x55df3a9951c0]
./services(_ZN12SocketEngine7ProcessEv+0x18a)[0x55df3a98f61a]
./services(main+0x803)[0x55df3a8ba723]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f39c81da2e1]
./services(_start+0x2a)[0x55df3a8bc91a]
======= Memory map: ========
55df3a880000-55df3a9e0000 r-xp 00000000 08:01 537977 /home/d ebian/services/bin/services
55df3abdf000-55df3abe5000 r--p 0015f000 08:01 537977 /home/d ebian/services/bin/services

I hope this can help as such a crash is truly concerning and I will test to see if it was done by setting modes "from the outside".

Regards,

Koragg

Dear genius3000,

Thank You very much for providing this module, as it can help keeping unwanted nick!user@host masks out even if e.g. the person joins with a "clean" one and only after joining switches to a "bad" one.
There appears to be an issue though with cs_akick_check NOT checking on ident changes.

This can occur e.g. via an oper doing /CHGIDENT (as I had done to test it) or via vidents (vhosts in the user@host format vs the "standard" host alone). This could allow users to let "bad" akicked idents in (e.g. if a webirc connection with a fixed ident is meant to be kept out and the user has a vident and identifies after joining.)
As at least InspIRCd 2.0.27 (where this feature was tested upon) also sends a Changing ident pseudo quit upon host changes, this module could perhaps use that as an indicator to check?

Tested Anope version is Anope 2.0.6

I hope this feedback can help you further improve this module as it is a great implementation and should be integrated directly into ChanServ AKICK!

Regards,

Koragg

Dear genius3000,

The os_notify module does not have all flags spaced out correctly in /os help notify add, as seen in the lines https://github.com/genius3000/anope-modules/blob/master/os_notify.cpp#L842-L849

On IRC it looks like this: [01:47] -OperServ- The available flags are:
[01:47] -OperServ- c - User Connections d - User Disconnections
[01:47] -OperServ- j - Channel Joins k - Channel Kicks
[01:47] -OperServ- m - Channel Modes n - User Nick changes
[01:47] -OperServ- p - Channel Parts s - Most Services commands
[01:47] -OperServ- t - Channel Topics u - User Modes
[01:47] -OperServ- S - More Services commands
[01:47] -OperServ- expiry is specified as an integer followed by one of d (days),

Thank You for all Your time and effort in developing these modules.

Regards,

Koragg

Hello,

I wanna ask if is it possible for a module that will allow to change the registered value of any nickname|#channel, i will provide some examples.

The goal is to update the database time_registered value immediately (probably by forcing an /os update after each modification) without a services restart.

Errors checks:

1. If the given nickname or channel is not registered then error.
2. If given unixtime is the same as set or larger than CURRENT_UNIX_TIME then error.
3. If given unixtime is lower than Thu Jan 01 02:00:00 1970 then error.
4. If READ_ONLY then error.

Config:

module { name = "os_regset" }
command { service = "OperServ"; name = "REGSET"; command = "operserv/regset"; permission = "operserv/regset"; }

Usage:

/os regset nickname|#channel unixtime
/os help regset

Example:

/os regset westor 958564800
-OperServ- westor registration unix value has been changed.
/ns info westor
Registered: May 17 15:00:00 2000 CEST (20 years, 25 days, 12 hours, 48 minutes ago)

/os regset #channel 958564800
-OperServ- #channel registration unix value has been changed.
/cs info #channel
Registered: May 17 15:00:00 2000 CEST (20 years, 25 days, 12 hours, 48 minutes ago)

• Thanks!

Some modules have a hard dependency on using inspircd20, although the features may even work in inspircd12 or inspircd3.

I saw this in one of Sadie's modules, this seems like a good approach for checking in general if InspIRCd is being used, where the specific protocol version is not important:

if (IRCD->GetProtocolName().find("InspIRCd") == std::string::npos)
    // not inspircd, ...