View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002138 | unreal | ircd | public | 2004-10-27 13:45 | 2004-10-29 09:13 |
| Reporter | brain2 | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Product Version | 3.2.1 | ||||
| Summary | 0002138: Banned clients hostnames or ip addresses exposed to non-opers | ||||
| Description | During a clone flood we have a system which removes the clones by gline. As each client is g-lined the quitmessage exposes its hostname: [18:01] --> Joins: [lsd]|496837 ([email protected]) [18:01] <-- Quits: [lsd]|496837 ([email protected]) (User has been banned from ChatSpike (Your nick is too lame for this network.)) [18:02] --> Joins: [lsd]|561427 ([email protected]) [18:02] <-- Quits: [lsd]|561427 ([email protected]) (User has been banned from ChatSpike (Your nick is too lame for this network.)) [18:02] --> Joins: [lsd]|577459 ([email protected]) [18:02] <-- Quits: [lsd]|577459 ([email protected]) (User has been banned from ChatSpike (Your nick is too lame for this network.)) [18:02] --> Joins: [lsd]|586065 ([email protected]) [18:02] <-- Quits: [lsd]|586065 ([email protected]) (User has been banned from ChatSpike (Your nick is too lame for this network.)) [18:12] --> Joins: [lsd]|627912 ([email protected]) [18:12] <-- Quits: [lsd]|627912 ([email protected]) (User has been banned from ChatSpike (Your nick is too lame for this network.)) | ||||
| Additional Information | Speak to me privately for details of a channel where you can see this happening | ||||
| 3rd party modules | |||||
|
|
seems it doesnt always happen, as you can see from the first in the list of sample glines. seems intermittent, standard glines are being sent from a services server. |
|
|
Could be the clone bots are setting -x? *edit* In other words, put x in your restrict-usermodes and +x in modes-on-connect and see if still happens. */edit* edited on: 2004-10-27 13:50 |
|
|
i dont really want to have to go do that network wide, plus a lot of users will be pissed off. but yes, its possible and probably detectable some other way. |
|
|
i had this problem once, it seems the bots was removing the +x mode, as it wasnt in the restrict usermodes, best way to check is next time u catch them connecting, /whois them as ircop and u`ll get there modes. |
|
|
The QUIT sending function uses sendto_common_channels. This function calls the vsendto_prefix_one function to determine whether to show the real or cloaked host. This is the exact same function used to make this determination for the JOIN message. My point is, if JOIN shows cloaked, and QUIT shows real, something else must be doing it since it is executing the same code to decide which to show. So I am inclined to believe that some of the bots are setting -x. And I'll also make a note that I have seen bots that do this. They are attempting to flood the server since Unreal can be configured to simulate a part/rejoin everytime +/-x is set. Therefore, they are hoping this option is enabled and they are hoping it will allow them to create a join/part flood. |
|
|
this is unlikely but, couldnt a single "mass flood" system be added, for example, if the server sees that X users remove the x umode, it would notify opers? or ban them??? the down sides which i guess will amke u say no is that on large networks this could trip often as users would maybe remove +x (would they?) *if they can remove the x mode, then if u ban the cloaked host, they can ban walk it as they lose the cloaked host when they remove the x rite?* edited on: 2004-10-28 16:16 |
|
|
rofl :PP |
|
|
White_Magic: or the admin just gets sick of it and stuffs x in the restrict-usermodes :P . Seriously, though, the only way you'd get a flood with +x like that is if you have the force-rejoin for userhost changes, and there's a solution: it's called +b. Granted it's a good feature to prevent fun addresslist desynchs in some clients, but those are usually short-lived (iow, until said "desynched" clients receive a message from that user. And no, I don't think setting -x will let you walk cloaked IP bans. And it doesn't let you walk glines either, since those operate on your realhost anyway. |
|
|
aquanight: "i dont really want to have to go do that network wide, plus a lot of users will be pissed off" shame huh, coz always make channel mode x - cant join if ur not umode x and if u remove umode x and ur on channels with mode x ur forced to part? its a lot of work huh, considering a;; they need to do is put it in the restrict user modes then rehash. but that shows just how stubborn people r. (no offense) |
|
|
Well, we have some protection/slowdown: every client gets added 7 seconds of fakelag every time they set/unset 'x' and the force-rejoin stuff is enabled (note: first 9 seconds of fakelag have no impact, so 2 times quickly is allowed, but after that you'll have to wait X seconds). But yeah, they can still try ;). Anyway, I don't find it too odd that bots like this set themselves -x... that way the owner (or other bad ppl) can see the IP, which might allow them (depending on the bot and if the host is firewalled) to somehow connect to the bot(s) on some port or whatever. Hm, I think this can be closed? ;) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-10-27 13:45 | brain2 | New Issue | |
| 2004-10-27 13:46 | brain2 | Note Added: 0008127 | |
| 2004-10-27 13:49 | aquanight | Note Added: 0008128 | |
| 2004-10-27 13:50 | aquanight | Note Edited: 0008128 | |
| 2004-10-27 13:50 | aquanight | Note Edited: 0008128 | |
| 2004-10-27 14:23 | brain2 | Note Added: 0008130 | |
| 2004-10-27 16:28 | White_Magic | Note Added: 0008134 | |
| 2004-10-28 16:04 |
|
Note Added: 0008152 | |
| 2004-10-28 16:14 | White_Magic | Note Added: 0008154 | |
| 2004-10-28 16:16 | White_Magic | Note Edited: 0008154 | |
| 2004-10-28 20:57 | syzop | Note Added: 0008158 | |
| 2004-10-28 22:51 | aquanight | Note Added: 0008160 | |
| 2004-10-29 08:50 | White_Magic | Note Added: 0008165 | |
| 2004-10-29 09:13 | syzop | Status | new => closed |
| 2004-10-29 09:13 | syzop | Note Added: 0008167 |
