DALnet-src October 2009

dalnet-src@lists.dal.net

14 participants
4 discussions

host-masking for users
by Kobi Shmueli 31 Oct '09

31 Oct '09

Hi all, I think it's about time to discuss host-masking for users again. There are (at least) two types of host-masking we could add: 1) hash based masks (statically mask part of the IP/host, i.e. dalnet-19309.example.com) 2) nick based masks (i.e. registered-nick.dalnet.user or whatever) The second method will let users evade bans more easily so I'm going to focus on the first method. My implementation suggestion: Each server will store both the user's real host and a hashed version of it. The hash for each IP/host will always be static and even if a user disconnects and re-connects, they will get the same hashed IP/host. By default, users will get a umode (i.e. +H) that will show the hashed version wherever their real host have been used until now (/whois, /who, joins, parts, etc). At any time, a user will be able to umode -H themselves and use their real host instead of the masked one. Bans will work both against the real host and the hashed host so if a user will get banned by his masked host, they won't be able to join a channel even if they umode -H themsleves. IRC Operators will be able to see any users' real IP/host, ofcourse. IMO, we shouldn't pass the masked host with the NICK command between servers and just let each server hash it on their own. As for the actual encryption, I would let a module do the actual hashing of the masked host (we'll provide a sample module). The module will be able to support (at least) two encryption types so we will be able to be change the type we're using on the fly by services after all servers have upgraded their module (in the case we'll ever want to change it). Let the discussion begin! -Kobi.

12 48

Count.unknown counter problem
by Charalampos Pournaris 19 Oct '09

19 Oct '09

Hello, I noticed a tiny bug in the LUSERS response using the latest bahamut 1.8(06). Specifically I was getting some weired "unknown connection(s)" negative values like: -2 unknown connection(s) thus I added some debug code for every counter increase/decrease statement to figure out what is going wrong. Here are my findings: The counter *only* increases within the function: add_connection() in s_bsd.c. 3 functions decrease the counter: do_server_estab() in m_server.c (When a connection with a remote server is established) register_user() in s_user.c (When a client is registered via NICK/USER) exit_client() in s_misc.c (When the client quits and is marked as unknown) so here are some scenarios that can occur: Suppose, test1.example.net is our local server (unlinked) test2.example.net is a remote server (unlinked) test3.example.net is another remote server (unlinked) client1 is.. a client - Count.unknown = 0; in main() - Client connects to the server and the counter is increased via add_connection(), Count.unknown == 1. The client either registers or quits so the counter gets decreased back to zero via register_user() or exit_client() respectively. Count.unknown == 0. - test2.example.net initiates a connection to "us" (test1.example.net) so the add_connection() is called and the counter is increased to 1. The connection with the remote server is established so do_server_estab() decreases the counter back to 0. Count.unknown == 0. Everything ok so far.. - We initialize a connection to test3.example.net (via CONNECT). The counter is *not* increased since add_connection is never called. The negotiation with the remote server is established and do_server_estab() is called decreasing the counter to -1. Oups!! Count.unknown == -1 I guess a solution could be to increase the counter in connect_server() too but then the counter should be also decreased when the connection to the remote server fails and do_server_estab() is never called. Any ideas/solutions for this? Thanks, Charalampos Pournaris __________ Information from ESET NOD32 Antivirus, version of virus signature database 4523 (20091019) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

1 0

Re: [DALnet-src] host-masking for users
by Kobi Shmueli 15 Oct '09

15 Oct '09

Juan Baez wrote: > From my understanding a host such as "127-0-0-1.state.isp.com" would get > masked something like: "dalnet-19309.state.isp.com" > > What about IPs that don't have hostnames? Do you plan on generating a > hostname for them, and then masking that? (i.e. 127.0.0.1.usr.dal.net to > dalnet-19309.usr.dal.net) I would want users to still be able to ban another user's /16 so either 127.0.0.dalnet-32312 (will break some ban scripts, I guess) or dalnet-32312.0.127.in-addr.arpa will do the trick. -Kobi.

1 0

[RE:] Host-masking for users
by Irvine A. Eatmon - prez 14 Oct '09

14 Oct '09

Well, from my understanding DALnet's Coding Team is already working on, and has implimented, client-side SSL. It is in testing stages. As for hostmasking, I can see this feature being of use for many of our users. People like to feel secure when using IRC, as let's face it, it does have a bit of a bad name compared to other Chat means for having a lot of "kiddies." So adding this will help allow our users (mainly new users,) to feel a little more safe while on DALnet. I agree with "Option 1." This method should work properly, and limit the chance of abuse. We can not have these hashes change, as it would get annoying having to re-ban users from channels a lot. But then again, it's the same when they change ident@vhost. It's bound to happen sometimes, but for the the most part we should be okay in the general abuse area. As for some saying "if it ain't broke, don't fix it." well, this has been a long time coming. Plenty of networks have successfully used host-masking, and will for years to come. DALnet should also, being an top-5 network, offer this to our users as well. It's about them, and if majority want this, we should provide it. I can't see how adding hostmasking would add more channel evading abuse than already exists, especially with the main option mentioned. If they want to get around it, they will with or with-out hostmasking. So my conclusion is, YES to proposition 101! (Host-masking.) done using hashes. (user-2500.dal.exampleISP.com) [ Irvine E. ] [ prez - prez(a)dal.net ] [ rapport.ix.us.dal.net ] [ Global Operator - Services Administrator ] [ Web Team Member ] BEGIN REPLY-TO MESSAGE: - - - - - - - - - - - - > DALnet has successfully done no hostmasking for over a decade, so if it > ain't broke, don't fix it, in my opinion. Client side ssl, though, I feel > is > a reasonable enhancement request. What with more places offering wifi, and > internet options on the go these days, I feel a more secure client to > server > communication is higher priority than hostmask offerings. > > On Tue, Oct 13, 2009 at 8:33 PM, Michael Reynolds < > michael.reynolds(a)gmail.com> wrote: > >> On Tue, Oct 13, 2009 at 7:55 PM, Vin King <vin.king(a)gmail.com> wrote: >> > Personally, I don't think DALnet needs masking. I see plenty of room >> for >> > abuse, and inability to properly ban things, especially if each server >> is >> > independently hashing a hostmask. >> > >> > BUT, if we WERE to mask, I'd go with a static hash of the address >> shared >> > among servers. Connecting server hashes it, passes it as the hostmask >> to >> all >> > other servers. Helps prevent abuse. Nick based masks hold plenty of >> room >> for >> > abuse. >> >> Considering DALnet's rate of growth over the past few years, and the >> fact that there are thousands upon thousands of networks that have >> successfully done hostmasking for close to a decade, I'd have to >> wonder why DALnet would not want to implement this feature. >> >> For that matter, let's throw in client SSL. I don't want to hear the >> excuse that it uses too much load. A Gentoo box powered by a Dell 2950 >> with an Intel PT 1000 can handle over 100 million SSL connection >> setups and takedowns in a day, with a load average of 0, and this is >> without hardware acceleration. >> _______________________________________________ >> DALnet-src mailing list >> DALnet-src(a)lists.dal.net >> https://lists.dal.net/mailman/listinfo/dalnet-src >> > _______________________________________________ > DALnet-src mailing list > DALnet-src(a)lists.dal.net > https://lists.dal.net/mailman/listinfo/dalnet-src >

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

DALnet-src October 2009