RE: [Coder-Com] RFD: Secondary links
If i may... there is another problem i see coming... What about a network where there is many 1-2 sec lag between servers (an example). If, let say, 3 or 4 servers decide to 'jump' at the same time... I wont list all problem that could occur, but there is a need for a pre-jump (to the network and some sort of aknolegment after that) command telling other servers to wait a little before their jump and maybe reconsider after the fist one (via the secondary link of course, and propaging to all servers and secondary link and coming back the same way to say 'oki', but not being stopped if there is no answer at all... (blah)). There is also the problem that secondary server would be fine for leaf servers, but what about hubs? It's for the hub that it would be the more usefull, but it is also where problems begins: We have to be carefull to avoid some sort of long term netbreak if 1 hub decide to jump to an other hub but creating 2 seperate groups that way... There must be a checking mecanism ;p I don't know it this if this is 'clear' but if you play with a sheet of paper, some dots and line, wou'll see what i mean :o) - Alocin > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de Kev > Envoyé : Le jeudi 11 avril 2002 12:57 > À : [EMAIL PROTECTED] > Objet : [Coder-Com] RFD: Secondary links > > > The idea is to allow servers to establish a secondary network link. No > messages (except PINGs) would go across the secondary link unless the > primary link was broken. This is still a long way from a mesh-linked > network, but might be an interesting enhancement. > > We would introduce a new command for unregistered connections to server > ports--SECONDARY. We would also introduce a new server<->server command > with the token SC. SC would be prefixed by the introducing server and > would contain the same fields as a SERVER command--lag could lead to some > servers receiving the SECONDARY command before the SERVER command. We > need to discuss how to represent destruction of a secondary link--is a > SQUIT command enough, or must we introduce another command? We must also > discuss how the fall-back is to occur--if more than one SECONDARY link > has been established, how do we select which one to fall back to? > > My idea for this is that each link--both the primary and secondaries-- > have an associated timestamp. If the primary is lost, the secondary > with the oldest timestamp is promoted to the primary. > > I can think of three more problems that must be solved. The first is > what to do with en-route messages: messages that cross with the SQUIT. > The parser drops messages that are going the wrong direction. We should > then remove this restriction, but that leads to potentially infinite > message loops under certain types of desynchronization. The second > problem is what to do with messages waiting in the sendq for the primary > link--they should be resent to the secondary, but might that require > re-parsing them? The third problem is what to do about certain global > messages required for maintaining network synchronization--some could get > lost during the transition from the primary to the secondary, but we > can't simply have the server deal with multiple copies of the same change > to the database. > > So. Discuss :) > -- > Kevin L. Mitchell <[EMAIL PROTECTED]> >
RE: [Coder-Com] RFD: Secondary links
(snip) > > There is also the problem that secondary server would be fine for leaf > > servers, but what about hubs? It's for the hub that it would be the more > > usefull, but it is also where problems begins: We have to be carefull to > > avoid some sort of long term netbreak if 1 hub decide to jump > to an other > > hub but creating 2 seperate groups that way... There must be a checking > > mecanism ;p > > > > I don't know it this if this is 'clear' but if you play with a sheet of > > paper, some dots and line, wou'll see what i mean :o) > > My intent is to fail over to the secondaries only if a primary link falls > over, so I'm not sure if this problem is still there... > -- > Kevin L. Mitchell <[EMAIL PROTECTED]> > L L | | L C~E L | / \ | Servers: L-A-B G-H-L | \ / | L D F L | | L L C is connected to E C have F as a secondary F is connected to G F have D as a secondary C-E becomes too slow... C switch from E to F F-G becomes too slow... F switch from G to D L L | | L C E L | / \ \ | Servers: L-A-B | G-H-L | \ | | L D-F L | | L L Well, you could say that F will not be able to link to D because D will reject it as already in the network... but since it will always be the case with the use of secondaries... D would not have the rigth to refuse the connection.. all it could do is send a command to force the break on the other side... somewhere most likely between ... C and F! And this is not all... what if both 'jumps' occur at the same time? It would be even more problematic because no travelling command could be use to avoid the situation... anyway... some puzzle to solve :) - Alocin
RE: [Coder-Com] Ban/Kill with fingerprint
> OK, I see what you're talking about now, but how would you go > about generating a fingerprint? Baring in mind that we have no access to > their local system to use details such as CPU ID...and we likely never > will have either (I'm not sure I'd want that information from the users). > > The only way I can see of doing it would involve a Client <-> > Server protocol change to allow the sending of a FINGERPRINT : hash> during the connection phase...but this would be so easy to fake > (you could just generate a random fingerprint) that it would be > totaly useless. > > > Chojin I'm curious... Theoricaly.. would there be a way to retreive the mac address? Because if it could be done.. -that- would be ideal... to get something like: [EMAIL PROTECTED] where is.com would be the real isp ending... (from ppp123.bla.isp.com, we could keep all except the the first part and replace this one by the 'something') and where 'something' would be the resultant of a simple equation on the mac address to get something like 'n789u6nf'... (this letting possible to ban a simpel person, a whole isp, protecting users against DoS, etc...) ... Is that possible? - Alocin
RE: [Coder-Com] username in /whois?? please remove!
Just a question, not really on X behavior, but on the new way the servers will hide the username... Will there be a way (a command) to choose not to set it? I mean if i log into X but doesn't want my host to look like [EMAIL PROTECTED] ... will there be a '/restoremyhostname' or so? Or better then that, as it will have major consequences on littles bots, scripts, and all those things using the hostname as an authentification for some channel utilities... Maybe X could simply advertize a command to hide your host as soon as you log in... /msg x login myuser mypass -X- Authentification successfull (...) -X- You could now use /hide to hide your hostname Anyway... i don't even know if this is already done... my question is 'how do you intend to make the hiding of the hostname work?' Tanks, - Alocin
RE: [Coder-Com] username in /whois?? please remove!
> Just a question, not really on X behavior, but on the new way the servers > will hide the username... i meant the hostname ;p
RE: [Coder-Com] username in /whois?? please remove!
ah!.. that's the part i didn't know tanks for the info but the idea to advertize it as soon as you login to X remain :o) tanks again, - Alocin > -Message d'origine- > De : nighty [mailto:[EMAIL PROTECTED]] > Envoye : Le vendredi 19 avril 2002 12:03 > A : Alocin; Undernet Coder Comitee > Objet : RE: [Coder-Com] username in /whois?? please remove! > > > At 11:18 19/04/2002 -0400, Alocin wrote: > >Just a question, not really on X behavior, but on the new way the servers > >will hide the username... > > > >Will there be a way (a command) to choose not to set it? > > > >I mean if i log into X but doesn't want my host to look like > >[EMAIL PROTECTED] ... will there be a > >'/restoremyhostname' or so? > > > >Or better then that, as it will have major consequences on littles bots, > >scripts, and all those things using the hostname as an > authentification for > >some channel utilities... Maybe X could simply advertize a > command to hide > >your host as soon as you log in... > > > >/msg x login myuser mypass > >-X- Authentification successfull (...) > >-X- You could now use /hide to hide your hostname > > > >Anyway... i don't even know if this is already done... my > question is 'how > >do you intend to make the hiding of the hostname work?' > > > >Tanks, > > Hi, > > As far as i know when you > /msg [EMAIL PROTECTED] login my_login my_pass > -X- AUTHENTICATION SUCESSFULL AS my_login > > you keep exactly the host you had .. but you need to > > /mode your_nick +x > > to enable the "host faking" (@my_login.users.undernet.org) > Note: to avoid breaking clients, setting (or unsetting afaik) this mode > will make you PART > any channel you joined in the meanwhile. > > regards, > > > > > >- Alocin > > > --nighty / [EMAIL PROTECTED] - Paris.Fr.Eu.Undernet.Org > --web: http://nighty.roots.org/ > > >
RE: [Coder-Com] level 500 command proposal
> >Then of course you can do: > > *!*@*.?? > > *!*@*.com > > *!*@*.net > > *!*@*.org > > *!*@*.info > > I think is enough to add something only for host/IP. > If the banned > host/IP doesn't contain a character a-z, A-Z or a > digit 0-9 then the > banmask to be a wrong one. A ban on *!*@*.c* won't > make X to kick all > users in that channel (only if all of them have a "c" > in their hostname). Well, i'm not sure many persons on a channel would still be there if you ban *!*@*e* from X ;-p To the others... May i suggest that if you intend to continue this discussion, at least specify if you're talking about a ban trough X or as a channel mode, it's very funny to see so many persons arguing but not talking of the same thing at all ;-p - Alocin
[Coder-Com] /msg x help set KEYWORDS
/msg x help set KEYWORDS [00:38] -X- /msg X set <#channel> should be [00:38] -X- /msg X set <#channel> keywords isn't? :o) - Alocin
[Coder-Com] suggestion of a WHOIS modification
About the *.user.undernet.org and the fact that it is nice to protect yourself against attacks, it is also a pain for channel ops to find out who is doing what and to find out to whom they should complain if they want to inform an ISP (...) The fact that a ban is still usefull for banning a person even if they masquerade their host is nice... if you can find that true host! And with the fact that flooders will register 30 false login it is a real pain to live with ... Anyway, my point is: why not put a privilege on the whois request done by a op on a user on his channel? It would reduce the abuse on multiregistering because there would be many less use for it AND it would let users act upon flooders if they join the channel where they are op by maybe contacting the ISP (...) The fact that a person decide to join a channel is still his own choice, so it will not impact on the desire to protect a user privacy or security... If they join a channel they accept to obey by the rules of the channel and to allow acces to their true host to the ops, nothing bad in that. So, to be clear, what i am suggesting is: For everyone, the whois of Someone would still look like SomeUser is [EMAIL PROTECTED] * something SomeUser on #chan1 #chan2 SomeUser using *.undernet.org The Undernet Underworld SomeUser End of /WHOIS list. Except for ops on #chan1 or #chan2 that would see: SomeUser is [EMAIL PROTECTED] * something SomeUser on #chan1 #chan2 SomeUser using *.undernet.org The Undernet Underworld SomeUser End of /WHOIS list. I will also add that this would not compromise CPU usage very much... Or if this is something you absolutly want to avoid, use the same principle that was use for cprivmsg... i dislike the idea of having to use a new command, but even that would at least help me free the channels where i am op of those «kiddies-that-didn't-got-their-x-box-for-christmas-so-the-world-must-suffer» type of users... Tank you for your interest.. reply/suggestions welcome :o) - Alocin p.s.: There is other possibilities, like adding a 'join comment' stating the host to the ops only... (there is already a 'part comment' so the syntax is already in place) and that would eventualy reduce the need for client to use secondary commands to generate an internal user list. Or/and the WHO could be modified in the same way...
Re: [Coder-Com] suggestion of a WHOIS modification
> The hidden +x host was created with a reason: To protect users > and Undernet > > staff. If I run a ddos/botchan, and an oper walks in to gline > them, or a cservice admin join and removes my X bot, I really > think I shouldn't be able > > to see his IP, even if I'm a chanop. > > Spike This is not an issue, if you want to protect an oper going into the channel for this, you just have to pub an additional check for the status of the user joining the channel before giving away his IP... Anyway you put it it wouldn't be hard to code. To the other objections on the privacy basis... I really don't understand your point and clearly you don't understand mine. Everything on this network is based upon the idea of protecting users from attackers and this is nice, but now, the way it is working it also help attackers who want to exploit this. Let be more practicle on an everyday example: #afunchannel, having the habitual limit of 45 bans have to deal with #wewilldestroyyou, a channel from where SomeIdiot is member of a fun team of 'you will not ban me from your chan even if i'm an asshole'. Nom, SomeIdiot have 10 buddies on #wewilldestroyyou that decide that SomeOp had a bad idea when he banned SomeIdiot from #afunchannel. In the past, there was 2 choices: 1- they join #afunchannel with 30 clones, flooding and so, and were banned one by one or by groups and the ops could trace the drones and contact the ISP if they want (or nuke them i admit) but when SomeIdiot did came back to SomeOp and told him 'see what happen', at least SomeOp was able to trace SomeIdiot and contact the ISP (or nuke him i admit). 2- they simply nuke the connexion of SomeOp (or everyone on the channel...) Today, what we have is: 1- they can't flood the connexion of SomeOp, but they will, from time to time, nuke everybody else on the channel who isn't using +x (...) 2- they come with 100 drones to the channel, much of them +x. You can't trace them so their ISP cannot be contacted (or nuked, i know). But it rapidly become impossible to manage the flood with bans so the only choice reside in banning *.users.undernet.org. (and now we go back to the old way, and get the same set of problems!!) And worst of all, when SomeIdiot come to claim 'you should know better than to ban me' there is not a thing you can do about it! If only ops could see real IPs: 1- flood of +x drones would be stoppable with much less bans. ISP could be contacted (or nuked i know). 2- SomeIdiot couln't claim his glory, since he would be tracable (log of a past join prior to the first ban) and so if a flood began 2 minutes after a ban, you would know what ISP to contact (or nuke i know!!) The difference between those cases? On the fisrt one, everybody can and will eventualy be nuked (arg) On the second, attackers are perfectly protected and untracable if they are a bit carefull, but the peoples on a target channel are still vulnerable! Non +x will still get DoS, and eventualy it is easy to force the issue and force ops to use +ban *.users.undernet.org and go back to the even less secure #1 state. The way i propose would simply turn the balance in the favor of ops by letting them act (hopefuly responsably) and be able to resolv a channel attack without having to revert to state #1. To the peoples who are suggesting that this would deprive sormal users of their protection, let remember some things: 1- It will always be a choice to join or not a channel. auto-join on invite are not an issue, this is a client matter. Want to try to solve the old game of #prison on the server side too? (auto-invite on part from this channel was giving a hard time to some mirc users) 2- If you want, you could put supplementary information on the topic... (mode +x or login to x sending a warning telling that their host will NOT be hidden from ops...) 3- you can even imagine (i dont like it) other ways, like putting a channel mode that would void this detection, then a client script could check if the channel have the mode set before joining. Anyway, i hope some lights will go on with this, try to imagine being in the position of the ops of a big channel.. or a support channel for a small isp that is seeing his connexion flooded simply because someone doens't appreciate besoin banned! (or worse doesn't want to give free access!) And to finish with this, choose an everyday example.. you always have the choice to enter in a store that would request that you give you name as a club member before going in. You then decide if this is acceptable for you before going in, even if it is possible that you will receive unwanted publicity afteward. Anyways, a good day (and a good year to come!) to everyone who's taking the time to think about this. Regards, - Alocin.
Re: [Coder-Com] suggestion of a WHOIS modification
> While I am sure there are users that abuse multiregistering to X > from a > single IP, there are also multiple users employing single IP's > in the many > household and small business LAN's utilizing various forms of > shared connections. > > I wonder if the loss of utility for these users might not > outweigh the types of abuse that can perpetrated with X. > > William Van Wyck > pzl If this is what worries you, remember that ops on the channel have the hability to think! They could choose to ban only by the undernet host if they want to! The thing is that they need to have that choice.. this is their channel! And when i talk about multiregistering, what i am talking about is when someone, with a buch of emails that are pointing in fact to the same place is registering 50 usernames and, with them go online with drones coming from compromised connexions (trojan, wingates, etc). And then is using them to flood a channel.. there is no way of tracig them to informe the ISP of the compromised ips... And more important, you cannot pinpoint the source, the person who was abnned or feeled suffisently insulted to attack your channel or your connexion. You cannot informe his ISP to check his activities and eventualy make him stop. You also give the perfect rpotection to pples wanting to do any illegal activities at all... Regards, - Alocin
[Coder-Com] WHOIS ...
sly? I can as well provide a server log showing 100 IPs DDoS-ing ... but the probability of the IP of SomeIdiot being into that log is about 0. So.. is that case, will oper act anyway? What about forged logs? Don't forget that at least ISP can see in their log if the user was contacting the IPs used for the DDoS. Yes there could be some other level proxies, but at least then can give along the informating to the other ISP(?). What can an oper do... will they send the complaint to the ISP automaticaly stating the original complaint without regard to the nature of the proofs? Those questions will maybe seem trivials but i must state that the last times i contacted [EMAIL PROTECTED] i received either no answer or some comment asking for solid proof, such thing aren't possible... about all logs can be forged :-I Well, on this point also i promise i'll try it again before anything else. Don't worry, i'm not making a point to create too long mails :o), i'm just trying to be torough. I try to avoid answering to each mail by sending a complete mail responding to each objections. Regards, - Alocin
RE: [Coder-Com] Spam
Having a closed list accepting automaticaly emails from subscribed users but needing an approval if not subscribed could be done i think... Or, if this needs too much human intervention, an automatic response for pples not subscribed to the list and sending an email, stating 2 choices: 1- subscribe (how-to) and resubmit or 2- use the http://blah webform to submit the question/request/etc. The form would have a signature email accepted by majordomo... and would have also the benefit of making it clear for everybody if the mail need to have a CC to the sender included or not :o) Regards, - Alocin > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de Stacy Brown Thellend > Envoye : 17 fevrier, 2003 16:05 > A : s gibinski > Cc : [EMAIL PROTECTED] > Objet : Re: [Coder-Com] Spam > > > I don't think this can be done with majordomo. > > On Mon, 17 Feb 2003, s gibinski wrote: > > > Would it be possible to have the person making the submission > self-approve > > the posting to the list (rather than the moderator)? > > > > Sorry, I'm not familiar with major domo, but here is what I am thinking: > > 1. Members would post directly to the list. > > 2. In the event that the posting comes from a non-member, the user that > > made the post would be sent an e-mail telling them that their > authorization > > is required to allow the posting to be forwarded to the rest of > the list. > > 3. The user would then provide the actual approval to post. > > > > If possible, the user might also be told that HTML should not > be used in the > > submission, etc. > > > > I am guessing that this type of verification would catch most > of the spam? > > Anyone have any ideas on how difficult this might be to accomplish or > > reasons that this might not work? > > > > -stephen > > > > > > >From: Thomas Helvey <[EMAIL PROTECTED]> > > >Subject: [Coder-Com] Spam > > >Date: Sat, 15 Feb 2003 11:26:03 -0800 > > > > > >The spam to post ratio on this list seems to have gotten a lot worse > > >lately. Perhaps it's time to to consider limiting posters to > subscribers. > > >Discussion? > > > > > >Thanks, > > >--Bleep > > > > > > _ > > Tired of spam? Get advanced junk mail protection with MSN 8. > > http://join.msn.com/?page=features/junkmail > > > > > Stacy Brown Thellend <[EMAIL PROTECTED]> http://pfft.net/stacy > -- > --- > Famous last words: I can get a world record for doing this. >
