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.
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
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.
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
>
