View Issue Details

IDProjectCategoryView StatusLast Update
0005276unrealircdpublic2020-01-10 08:37
Reporterwestor Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version4.2.3 
Fixed in Version5.0.2 
Summary0005276: UnrealIRCD blacklist + antirandom modules doesn't let the user connect in if ban-action is warn,shun,tempshun,kill
DescriptionHello,

As i can see if i am not wrong the ban-actions warn,shun,tempshun,kill under a blacklist or antirandom set on configuration doesn't working as it should, this causing false-positive users having problems in their client side, i will provide a full report as i test all the actions in both modules.

The following examples counts all soft-* actions too.

Examples:

Blacklist module ::

with ban-action warn; === here should allow the user to connect and only send a warning message on O-Lines in snomask
[Blacklist] IP 104.248.151.248 matches blacklist dronebl (dnsbl.dronebl.org/reply=9)
ERROR :Closing Link: [104.248.151.248] (ban-reason related on blacklist set in configuration)

with ban-action shun; === here should allow the user to connect shunned
[Blacklist] IP 104.248.151.248 matches blacklist dronebl (dnsbl.dronebl.org/reply=9)
*** Shun added for *@104.248.151.248 ..... ......
451 NICK :You have not registered
ERROR :Closing Link: [104.248.151.248] (Registration Timeout)

with ban-action tempshun; === here should allow the user to connect shunned
[Blacklist] IP 104.248.151.248 matches blacklist dronebl (dnsbl.dronebl.org/reply=9)
Temporary shun added at user ([email protected] ) [ban-reason related on blacklist set in configuration]
451 NICK :You have not registered
ERROR :Closing Link: [104.248.151.248] (Registration Timeout)

with ban-action kill; === here should send a Killed reason thought
this seems not kills the user with a proper KIll message, but just block it from connecting, actually this is working as "block" action as it shouldn't.

Antirandom module ::

with ban-action shun; === here should allow the user to connect shunned
*** [antirandom] denied access to user with score 3: [email protected]:dlnic
*** Shun added for *@1.20.99.112 .... ...
ERROR :Closing Link: jofqb[1.20.99.112] (Registration Timeout)

with ban-action tempshun; === here should allow the user to connect shunned
*** [antirandom] denied access to user with score 3: [email protected]:dlnic
Temporary shun added at user jofqb ([email protected]) [ban-reason related on set configuration]
ERROR :Closing Link: jofqb[1.20.99.112] (Registration Timeout)

with ban-action kill; === here should have send a Killed message thought
*** [antirandom] denied access to user with score 3: [email protected]:dlnic
ERROR :Closing Link: jofqb[1.20.99.112] (Registration Timeout)

- Thanks!
TagsNo tags attached.
3rd party modules

Relationships

related to 0005501 resolvedsyzop Blacklist module doesn't allow clients to connect if warn action set 

Activities

Koragg

2019-05-15 18:48

reporter   ~0020670

Dear westor,

It appears there is a severe misunderstanding about how shuns actually work (and/or how clients sign on to a network to connect). I will address each issue in the order they occur.

1) warn disallowing connection: appears to be a bug indeed, we will have to see what syzop has to say to that

2) shun disallowing connection: this is by design. shun disallows all but a select few commands. A client gets a registration timeout for example when it cannot send NICK and USER within a specific time limit (or at all). A shun also blocks these commands and thus any shunned client will gte a registration timeout when disconnecting and attempting to reconnect. (I will assume your network does not require PASS as otherwise this would also be mandatory for signing on, but not sure if that also gives registration timeout, maybe someone else knows precisely).

3) tempshun disallowing connection: see 2) as the only difference between tempshun vs shun is that tempshun auto expires after a certain time period while a shun won't

4) kill causing registration timeout: incase you have not noticed, the user in 4) is using the same IP that is (temp)shunned. Check your (temp)shun list and remove the (temp)shun on the user, then they should be killed again as it should be (see 2) for an elaborate reason on why shun leads to registration timeout).

Hope this clears some or even all things up, if not, please feel free to ask and I'll do my best to make it hopefully more clear.

Regards,

Koragg

westor

2019-05-15 19:53

reporter   ~0020671

My friend Koragg

If shun designed to act like this then ok , so it seems i was wrong, i thought it allowing the clients to connect (handshake) but shunned (same for tempshun).

But in your no. 4 i meant before that i changed in configurations each time i tried it , so in the kill ban-action it doesn't saying that he gets a kill at all.

Each example above i test it was separately by changing the configuration and each time there was no bans/shuns in memory.

Koragg

2019-05-15 20:44

reporter   ~0020672

*Updated notes: tempshun lasts for a session (until the user disconnects) not for a certain time period beyond/beneath that, rest applies as outlined above (just the duration of how long they last is updated now correctly)

westor

2019-05-17 00:10

reporter   ~0020674

https://gitgud.malvager.net/Wazakindjes/unrealircd_mods/issues/18

syzop

2020-01-10 08:37

administrator   ~0021209

Both in blacklist and antirandom the issue with 'warn' was fixed past week.
The 'shun' issue is more of a misunderstanding / awkwardness with how shun works.
So I think this can be marked as resolved? Doing so... if I'm wrong, just let me know.

Issue History

Date Modified Username Field Change
2019-05-15 17:43 westor New Issue
2019-05-15 18:48 Koragg Note Added: 0020670
2019-05-15 19:53 westor Note Added: 0020671
2019-05-15 20:44 Koragg Note Added: 0020672
2019-05-16 08:36 syzop Priority high => normal
2019-05-16 08:36 syzop Severity major => minor
2019-05-17 00:10 westor Note Added: 0020674
2019-12-30 17:45 syzop Relationship added related to 0005501
2020-01-10 08:37 syzop Assigned To => syzop
2020-01-10 08:37 syzop Status new => resolved
2020-01-10 08:37 syzop Resolution open => fixed
2020-01-10 08:37 syzop Fixed in Version => 5.0.2
2020-01-10 08:37 syzop Note Added: 0021209