(If any of you got this twice, apologies, sent it from the wrong address the first go)
So, the idea of user hostmasking was brought up on the dalnet-src@ mailing list a few weeks ago and since we already have the ability in bahamut (via SVSHOST) to have services change a users hostname at anytime, I am thinking why not do this on a global scale?
efnet (and others using the same ircd) have the ability to give specific users their own custom host, on a server level, like handing out I:lines. We already have infrastructure setup for management of things in different areas via services (nickname/channel ownership, akill, etc).
On a small network I had running, I built into my services a way to allow users to set a "custom" hostname into NickServ done on the nick level, which worked a little like the /ns set url - command.
To create a new host for nick xyz (whilst using that nick), I would use; /ns set host some.random.hostname.
To turn off that option: /ns set host -
To minimise potential abuse, a list of hostmasks would say no you can't set your hostname to have the word "dalnet" or "staff" or "*.dal.net" in it. If the user tried to set their host to be the same as another users host or ip, it would deny the request. Finally, once a hostname was set, services would not allow them to change the hostname for that nick again for 1 week (unless it was to turn it off).
For any other potential abuse problems that someone might cause, there was a kill switch which a CSOp could use to disallow the user from setting a custom host (kinda like freeze), remove any existing host already set.
This automated system looked beneficial in that any user could create their own unique hostname without having a bureaucratic system of having a specific team of opers having to grant or deny any request on a one-by-one basis.
So, with my system, when does services issue the SVSHOST command (aside from when using /ns set host)? The answer is it would happen when they /identify to their nickname (or another nickname that they aren't currently using) with a separate NOHOST option at the end for if they don't want the host applied at that time.
Does a system like this sound of interest to anyone? Does anyone think something like that would be too open for potential abuse? Does anyone have any differing views on how to best setup a user hostmasking system for the network?
Thanks, Holbrook aka zort aka srd
Hi ,
I was reading this on a site about host masking just thought to share if that helps out? Reference site is mention at the end. What is Hostmask?
A hostmask is how scripts, bans, ignores, and some bots, determine someone's identity on IRC. Everyone who logs onto IRC has a nickname, a UserID (or `ident'), and a host. If you are on a Unix system, your UserID is likely your login name. On a Windows machine, you likely are able to set your UserID yourself.
Components
Your nickname is the main identifier used on IRC, but you can change nicks easily during your session, thus, it is a poor identifier. Likewise, because Windows users often set their own UserID, it is only a semi-reliable identifier. Your host is the Internet IP address or hostname you are connecting from. Most people can only change it by logging in with a different ISP. It is a strong identifier, although parts of it may change every time you log in, and a group of people share the same domain name.
The nickname, UserID, and host are often represented as:
nickname!UserID@Host You are probably familiar with the format `userid@host' for e-mail addresses. Although usually a host on IRC is not exactly the same as a person's e-mail address, the concept is similar. To get a mask, simply take thenickname!UserID@Host string, and replace the parts which you expect may change with wild cards. Two wild cards, “*” (asterisk) and ”?” (question mark) are understood. The “*” means “match any number of characters”, and the ”?” means “match exactly one character.”
Masks in practice
For example, my user@host string is Krobar!krobar@kro.bar, but if I added myself to the userlist that way and I didn't use the nickname Krobar one day, I wouldn't be recognized. On the flip side, if I added myself as *!*@*, then everyone would match. A typical mask is *!*UserID@*.Host This way any nickname used, from any machine in the domain is matched. The * in front of a UserID is usually a good idea, because some servers will add a ~ in front if identd (a nameserver of sorts) isn't working or is too slow. I typically add myself as *!*krobar@kro.bar
IP Addresses
Sometimes when DNS is slow or broken, someone might show up with only their IP address as a host. In this case, it's the end that changes, so a mask like this might be what you want: *!*UserID@Host.* My mask, in this case would be: *!*krobar@128.193.14?.* Note the use of ”?” in the IP portion. Sometimes my IPis 128.193.141.* and sometimes its 128.193.142.*. Adding a ? ensures I will be recognized, but without too much chance of accidentally recognizing someone else. EXAMPLES: To match everyone with a .br country ending:
*!*@*.br To match everyone with nick “warez”:
warez!*@* To match your friend John (John!jdoe@d-32.alaska.dialamerica.com):
*!*jdoe@*.alaska.dialamerica.com When John complains that he's not recognized when he dials in from Florida:
*!*jdoe@*.dialamerica.com To match John when his IP shows up instead:
*!*jdoe@132.31.206.* To match people with the tell-tale “typehere” userid:
*!*typehere@*
PFB , Reference site http://www.afternet.org/help/irc/hostmasks Regards Jazzzzz
On 19-Jul-2013, at 1:00 PM, "Holbrook Bunting" holbrook@DAL.NET wrote:
(If any of you got this twice, apologies, sent it from the wrong address the first go) So, the idea of user hostmasking was brought up on the dalnet-src@ mailing list a few weeks ago and since we already have the ability in bahamut (via SVSHOST) to have services change a usershostname at anytime, I am thinking why not do this on a global scale? efnet (and others using the same ircd) have the ability to give specific users their own custom host,on a server level, like handing out I:lines. We already have infrastructure setup for management of things in different areas via services (nickname/channel ownership, akill, etc). On a small network I had running, I built into my services a way to allow users to set a "custom" hostname into NickServ done on the nick level, which worked a little like the /ns set url - command. To create a new host for nick xyz (whilst using that nick), I would use; /ns set host some.random.hostname. To turn off that option: /ns set host - To minimise potential abuse, a list of hostmasks would say no you can't set your hostname to havethe word "dalnet" or "staff" or "*.dal.net" in it. If the user tried to set their host to be the same as another users host or ip, it would deny the request. Finally, once a hostname was set, services would not allow them to change the hostname for that nick again for 1 week (unless it was to turn it off). For any other potential abuse problems that someone might cause, there was a kill switch which a CSOp could use to disallow the user from setting a custom host (kinda like freeze), remove any existing host already set. This automated system looked beneficial in that any user could create their own unique hostname without having a bureaucratic system of having a specific team of opers having to grant or deny any request on a one-by-one basis. So, with my system, when does services issue the SVSHOST command (aside from when using /ns set host)? The answer is it would happen when they /identify to their nickname (or another nickname that they aren't currently using) with a separate NOHOST option at the end for if they don't want the host applied at that time. Does a system like this sound of interest to anyone? Does anyone think something like that would be too open for potential abuse? Does anyone have any differing views on how to best setup a user hostmasking system for the network? Thanks,Holbrook aka zort aka srd _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
_______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
On 7/19/13, Asif Ali Baig dreamhealer@hotmail.co.uk wrote:
Hi , I was reading this on a site about host masking just thought to share if that helps out? Reference site is mention at the end. What is Hostmask?
[snip]
The traditional definition of hostmask is used in the context of a ban or ignore entry, and refers to the parts of a host address that must be present, such as "*.aol.com" is a hostmask that applies to any user host pattern, as long as it ends in .aol.com; on the other hand nick!user@ipt1234.aol.com.example is in IRC protocol what is referred to as a sender prefix, and *!*@*.aol.com is an example of a prefix mask; that is a wildcard pattern based on an entire sender prefix.
Just to be clear... when reference is made to "host masking"; we are generally not talking about this at all.... but in fact about /hiding/ the true hostname, by changing IRC users' hostnames to a "substitute hostname".
Such as changing Nickname!username/Realname@ipt1-2-3-4.aol.com.example
To Nickname!username/Realname@Nickname.users.dal.net.example
That is 'host masking' doesn't have anything directly to do with a 'mask' or 'pattern';
Although the manner in which masking possibly affects features such as Banlists, Ignore lists, and Silence lists are very important.
For example: If you change the user prefix, this affects IRC clients' /IGNORE functionality.
When the IRC server is testing if an entry in a banlist applies to a user trying to join a channel ---- Do you test their Masked hostname against the ban, their original unmasked hostname against the ban, or Both?
If there's a channel ban like *!*@1.2.3.4/24 or *!*@[fe60::]/64
Do you check the IP address of the client joining --- when their hostname doesn't reverse resolve and they're not masked?
When their host doesn't reverse resolve and they ARE masked?
When their host does reverse resolve and they ARE masked?
When their host does reverse resolve and they are not masked?
If they are not masked, because they turned it off.... does the server attempt to figure out what their masked hostname might be, and apply the channel ban or AKICK to them?
E.g. do you expand matching in the opposite direction?
Or perhaps you attempt to interpolate the non-masked version and add it as an 'invisible' banlist entry, at the time that a channel operator adds a masked hostname to the banlist.
-- -JH
On 19 July 2013 04:35, Jimmy Hess mysidia@gmail.com wrote:
On 7/19/13, Asif Ali Baig dreamhealer@hotmail.co.uk wrote: If they are not masked, because they turned it off.... does the server attempt to figure out what their masked hostname might be, and apply the channel ban or AKICK to them?
E.g. do you expand matching in the opposite direction?
Or perhaps you attempt to interpolate the non-masked version and add it as an 'invisible' banlist entry, at the time that a channel operator adds a masked hostname to the banlist.
I like your idea of an invisible banlist entry. Perhaps some sort of linked ban which the hidden +b only gets sent from server<->server and not server<->client(s). May put unnecessary burden on server, but worth looking into.
-- -JH
On 7/19/13, Holbrook Bunting holbrook@dal.net wrote:
On 19 July 2013 04:35, Jimmy Hess mysidia@gmail.com wrote:
I like your idea of an invisible banlist entry. Perhaps some sort of linked ban which the hidden +b only gets sent from server<->server and not server<->client(s). May put unnecessary burden on server, but worth looking into.
What an implementation of an implied ban could look like is a canary, e.g. suppose you have userchosen.HASHCODE.masked.dal.net
when you do a channel ban add, you could have
- When a user comes online, and bcomes masked, they get somechosentext.HEXCODE.masked.dal.net
- The Hex CODE is a key into a database or cache.
- The cache should contain two things: the current real hostname. And "variability history" for that users' logins via that second level domain
For example: if one day they logged in with port42.city.state.example.com
And on the next day they logged in with port43.city.state.example.com
Then the variable portion is the first dot, based on the user's login history. *.city.state.example.com
would be the login history-adjusted version of the banmask.
If that user later logged into services with port16.city.otherstate.example.com
Then the variability-adjusted mask is now *.example.com
The expectation is services would "Announce" the HEX KEY data and the "variability history" data, at the time that the user logs in.
When a ban is set: it might look like *!*@someuserchosentext.HEXCODE.masked.dal.net
[ 1] Add a 32-bit field to the banlist structure to denote a 'tag'
[1] Test if the ban entry being added ends with ".masked.dal.net"
[2] If it does, look for a dot followed by some text.
[3] If HEXCODE has a valid hexcode, then, populate banlistentry->tag with that code.
[4] When a ban is checked; for the host portion, also check the "Variability adjusted" Host database entry, that corresponds to the Banlist Entry's "TAG" field
-- -JH
On 19 July 2013 05:11, Jimmy Hess mysidia@gmail.com wrote:
On 7/19/13, Holbrook Bunting holbrook@dal.net wrote:
On 19 July 2013 04:35, Jimmy Hess mysidia@gmail.com wrote:
What an implementation of an implied ban could look like is a canary, e.g. suppose you have userchosen.HASHCODE.masked.dal.net
What I'm proposing isn't incorporating dal.net in it. User picks a hostname they want.
To keep from them changing their host like you suggest would be to place a limit on how often they can change their hostname for said nickname. Once a week? Once a month?
On 7/19/13, Holbrook Bunting holbrook@dal.net wrote:
To keep from them changing their host like you suggest would be to place a limit on how often they can change their hostname for said nickname. Once a week? Once a month?
[snip] I would say it's important that the Mask displayed not be false. The hostname should be an agreeable hostname according to internet standards; and it should not be possible to display a "fraudulent" mask such as OTHERISP.COM or DomainNotRegisteredToTheIRCUser.com.
The hostname should end with "masked.dal.net" or something else, that clearly demonstrates its a masked name, that could never be registered by anyone else; even under the new ICANN Generic TLDs program.
Mandatory inclusion of a HEXCODE as I suggested above, also has great benefits, and I would strongly suggest that.
If host masking is implemented; users should not be allowed to create "confusion"; by pretending "this is my real hostname", convincingly, when in fact, it is some kind of fiction.
If custom domains are allowed, then the user should be required to demonstrate they can receive mail sent to postmaster@domain.example, or Administrative contact of the domain listed in WHOIS
OR that there is a forward A record for that domain to an IP address that user has exclusive control over.
I think simple hostmangling would do the trick. For example, a user with h-123-123-123-123.telia.com would mask to Dalnet-<checksum>.telia.com, where the checksum part would consist of a salt value set in ircd.conf. The real IP can still be shown to IRC Operators.
On another note, +b/+E/+I etc should still work on both the mangled host and the real IP, so users don't ban evade with host mangling.
We implemented this in fqircd (based on Bahamut 1.8 iirc, development has been stalled for a good number of years) and it has been working great. Should be quite an easy implementation to do with Bahamut, the main issue here seems to be whether to allow some kind of host mangling on DALnet.
Regards, Andreas aka ph0x (Sorry for top posting!)
-----Original Message----- From: dalnet-services-bounces@lists.dal.net [mailto:dalnet-services-bounces@lists.dal.net] On Behalf Of Jimmy Hess Sent: Saturday, July 20, 2013 12:32 AM To: Holbrook Bunting Cc: dalnet-src@dal.net; dalnet-services@dal.net Subject: [DALnet-services] Re: [DALnet-src] User hostmasking
On 7/19/13, Holbrook Bunting holbrook@dal.net wrote:
To keep from them changing their host like you suggest would be to place a limit on how often they can change their hostname for said nickname. Once a week? Once a month?
[snip] I would say it's important that the Mask displayed not be false. The hostname should be an agreeable hostname according to internet standards; and it should not be possible to display a "fraudulent" mask such as OTHERISP.COM or DomainNotRegisteredToTheIRCUser.com.
The hostname should end with "masked.dal.net" or something else, that clearly demonstrates its a masked name, that could never be registered by anyone else; even under the new ICANN Generic TLDs program.
Mandatory inclusion of a HEXCODE as I suggested above, also has great benefits, and I would strongly suggest that.
If host masking is implemented; users should not be allowed to create "confusion"; by pretending "this is my real hostname", convincingly, when in fact, it is some kind of fiction.
If custom domains are allowed, then the user should be required to demonstrate they can receive mail sent to postmaster@domain.example, or Administrative contact of the domain listed in WHOIS
OR that there is a forward A record for that domain to an IP address that user has exclusive control over.
-- -JH _______________________________________________ DALnet-services mailing list DALnet-services@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-services
On 7/19/13, Holbrook Bunting holbrook@dal.net wrote:
hostname at anytime, I am thinking why not do this on a global scale?
The idea that a CSop can take action doesn't do much to address the possibility of abuse. Basically, there are a limited number of CSops, whom additional work should not be created for on a daily basis ---- that is, the use of CSops to correct problems should be considered a contingency or an emergency response in case of extreme unexpected circumstances, not an appropriate system for deterring or preventing abuse on a daily basis.
IRC operations staff involvement, should always be kept an available option to deal with emergencies, but it should not be an excuse for failing to insist that possible intrinsic avenues for abuse be appropriately controlled and minimized ----- automated systems should resist abuse, and this makes them more scale able, and capable of servicing larger number of users more reliably.
-- The most likely kind of abuse I see with masking is -- ban evasion, or suppression of the user's real host, so they could rejoin channels later using a different identity.
To allow users to have custom hosts on any global scale; I do believe this calls for having some form of "IRC User" reputation system; to restrict the capability to "trusted users", such as nicknames with a known history: nicknames registered for a significant length of time, that are able to get other IRC users to vouch for/endorse them.
Then I would recommend that there be an automated system IRC users could use to report suspected abuses of masking and other service features.
And an automated mechanism for channel operators to make an "Official inquiry" through services, about the real hostname behind a masked user visiting their channel
-- -JH
On 19 July 2013 04:18, Jimmy Hess mysidia@gmail.com wrote:
On 7/19/13, Holbrook Bunting holbrook@dal.net wrote:
hostname at anytime, I am thinking why not do this on a global scale?
The idea that a CSop can take action doesn't do much to address the possibility of abuse. Basically, there are a limited number of CSops, whom additional work should not be created for on a daily basis ---- that is, the use of CSops to correct problems should be considered a contingency or an emergency response in case of extreme unexpected circumstances, not an appropriate system for deterring or preventing abuse on a daily basis.
CSOp was a suggested level, this could of course be any global operator, SA, CSOp, sabuse or SRA. That would be an entirely different discussion though and would ultimately be the decision of the highers.
IRC operations staff involvement, should always be kept an available option to deal with emergencies, but it should not be an excuse for failing to insist that possible intrinsic avenues for abuse be appropriately controlled and minimized ----- automated systems should resist abuse, and this makes them more scale able, and capable of servicing larger number of users more reliably.
-- The most likely kind of abuse I see with masking is -- ban evasion, or suppression of the user's real host, so they could rejoin channels later using a different identity.
The server that a user is on also keeps the users ip and hostname (as with oper hostmasking). The ircd still checks against that as well when comparing with a channels ban/exempt/invite list.
To allow users to have custom hosts on any global scale; I do believe this calls for having some form of "IRC User" reputation system; to restrict the capability to "trusted users", such as nicknames with a known history: nicknames registered for a significant length of time, that are able to get other IRC users to vouch for/endorse them.
Could limit the use of the system to nicknames registered for say 30 days or more.
Then I would recommend that there be an automated system IRC users
could use to report suspected abuses of masking and other service features.
And an automated mechanism for channel operators to make an "Official inquiry" through services, about the real hostname behind a masked user visiting their channel
This would have to be something looked further into. Who's to say that such an automated system there would in turn not be open for abuse as well? #operhelp would be a good place to start for reporting.
-- -JH
-
Andreas -
Asif Ali Baig -
Holbrook Bunting -
Jimmy Hess