View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005276 | unreal | ircd | public | 2019-05-15 17:43 | 2020-01-10 08:37 |
| Reporter | westor | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.2.3 | ||||
| Fixed in Version | 5.0.2 | ||||
| Summary | 0005276: UnrealIRCD blacklist + antirandom modules doesn't let the user connect in if ban-action is warn,shun,tempshun,kill | ||||
| Description | Hello, 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! | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
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 |
|
|
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. |
|
|
*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) |
|
|
https://gitgud.malvager.net/Wazakindjes/unrealircd_mods/issues/18 |
|
|
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. |
| 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 |
