Hello all. I am PapaSmurf on DALnet. This post has nothing to do with hostmasking for the general public. I have been assisting users, in DALnet help channels, since August/September 1998. Non-oper helpers, ever since I have been on IRC, have been subjected to packeting, DDoS, and computer invasions from annoying individuals. I believe the IRCd terminology for oper hostmasks (e.g. *@staff.dalnet or *@dalnet) is staff_token_address. Would it be possible for official-help-channel AOps, and above, to receive a token address (to help protect them, for their service in helping the network)? Possible restrictions to consider: 1. Helpers must be an AOp (or above) in official help channels. >> This will get non-AOp helpers more dedicated to helping, but this can lead to help abuse (e.g. use of scripts to provide fastest help to users, or AOps becoming lazy if wannabe helpers race to answer everything). 2. Token address possibilities: *@helper; *@nonstaff.helper >> I do not know IRCd, and I do not know if multiple token addresses can be assigned. 3. If this option can be made available, can said users have special permissions added (beyond the standard user)? >> Examples: more access to Q/q-lined nicknames and other, selected /stats commands, or expanded access to StatServ commands. As helpers, this would offer great flexibility when trying to explain certain matters to users, such as why certain nicknames cannot be used. 4. Conflict of policies. >> Some help channels may not remove AOps in official help channels for certain disciplinary actions, but DALnet decision makers may have different policies. DALnet policies would have to allow for removal of the token address (regardless of helpers remaining as channel staff or not). If this option is not feasible for DALnet, no worries. I thought I would bring it up to, at the very least, get some discussion going on this mailing list. PapaSmurf
On Tue, Jan 20, 2015 at 11:48 AM, PapaSmurf <freedried@yahoo.com> wrote: > Hello all. Hi, I believe the matter of choosing to apply masks to the people who are help channel operators or not is purely a policy matter, as the technical means already exists within Ircd to implement that; it is just services that needs to take actions to set hostmasks as desired. There might be some minor changes required to services code; however, we cannot very well submit patches or specific suggested changes on sources we cannot see. I would say the situation is unfortunate, but the _real_ problem is that Ircd is revealing user IP addresses by default, in the first place. This is historical, and reflects the fact that in the 1980 / 1990s internet, it was perfectly acceptable to reveal the IP address of end users of a service, but these days that results in breach of privacy and indeed facilitates abuse such as DoS or directed hacking attacks against IRC users. And hostmasking for the general public would address at least a major aspect of the problem, which affects or can affect many users beyond the help channel AOPs. Basically, the argument is cherrypicking helpers or opers for hostmasking functionality is not a good approach to begin with --- the protection could be extended to more users.
I am PapaSmurf on DALnet. This post has nothing to do with hostmasking for the general public. I have been assisting users, in DALnet help channels, since August/September 1998. Non-oper helpers, ever since I have been on IRC, have been subjected to packeting, DDoS, and computer invasions from annoying individuals.
-- -JH
Yes and no. If I remember correctly, bahamut contains an SVScommand to change a users hostname as it appears in a whois. So to get something like this would mean adding into services a flag for say, helpers, into nickserv for a registered nickname. The only problem here is that until the user has identified to nickserv, or is using the applicable nickname when connecting and matching a user@host mask in that nicknames access list; the period between successful connection and services telling the ircd to change the visible hostname, their real hostname is exposed. All I need to do is to put them on notify and have my irc client Whois them. The only way around that would be to have them connect using a different/random nickname, identifying first, then change/join channels. - Holbrook On Sunday, January 25, 2015, Jimmy Hess <mysidia@gmail.com> wrote:
On Tue, Jan 20, 2015 at 11:48 AM, PapaSmurf <freedried@yahoo.com <javascript:;>> wrote: > Hello all. Hi, I believe the matter of choosing to apply masks to the people who are help channel operators or not is purely a policy matter, as the technical means already exists within Ircd to implement that; it is just services that needs to take actions to set hostmasks as desired.
There might be some minor changes required to services code; however, we cannot very well submit patches or specific suggested changes on sources we cannot see.
I would say the situation is unfortunate, but the _real_ problem is that Ircd is revealing user IP addresses by default, in the first place. This is historical, and reflects the fact that in the 1980 / 1990s internet, it was perfectly acceptable to reveal the IP address of end users of a service, but these days that results in breach of privacy and indeed facilitates abuse such as DoS or directed hacking attacks against IRC users.
And hostmasking for the general public would address at least a major aspect of the problem, which affects or can affect many users beyond the help channel AOPs.
Basically, the argument is cherrypicking helpers or opers for hostmasking functionality is not a good approach to begin with --- the protection could be extended to more users.
I am PapaSmurf on DALnet. This post has nothing to do with hostmasking for the general public. I have been assisting users, in DALnet help channels, since August/September 1998. Non-oper helpers, ever since I have been on IRC, have been subjected to packeting, DDoS, and computer invasions from annoying individuals.
-- -JH _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net <javascript:;> https://lists.dal.net/mailman/listinfo/dalnet-src
-- holbrook / zort / srd SA: The halcyon team
I know Quension was against hostmasking, in general. There have been many threads about general hostmasking; all were shot down or left to die without change.If it could be done, to help those nonopers who help the network, it would be very much appreciated by those of us who help in official help channels. @Holbrook Wouldn't there be a way to ID to nickserv before using the nick (to bypass your point); i.e. /nickserv identify nickname nickpass? The user should be able to connect with one nickname, ID to nickserv with the aforementioned command, then change to the nickname (whereby the IRCd would auto-change the hostmask)? Perhaps I am mistaken. Thanks for the replies. PapaSmurf On Monday, January 26, 2015 1:31 AM, Holbrook Bunting <holbrook@dal.net> wrote: Yes and no. If I remember correctly, bahamut contains an SVScommand to change a users hostname as it appears in a whois. So to get something like this would mean adding into services a flag for say, helpers, into nickserv for a registered nickname. The only problem here is that until the user has identified to nickserv, or is using the applicable nickname when connecting and matching a user@host mask in that nicknames access list; the period between successful connection and services telling the ircd to change the visible hostname, their real hostname is exposed. All I need to do is to put them on notify and have my irc client Whois them. The only way around that would be to have them connect using a different/random nickname, identifying first, then change/join channels. - Holbrook On Sunday, January 25, 2015, Jimmy Hess <mysidia@gmail.com> wrote: On Tue, Jan 20, 2015 at 11:48 AM, PapaSmurf <freedried@yahoo.com> wrote: > Hello all. Hi, I believe the matter of choosing to apply masks to the people who are help channel operators or not is purely a policy matter, as the technical means already exists within Ircd to implement that; it is just services that needs to take actions to set hostmasks as desired. There might be some minor changes required to services code; however, we cannot very well submit patches or specific suggested changes on sources we cannot see. I would say the situation is unfortunate, but the _real_ problem is that Ircd is revealing user IP addresses by default, in the first place. This is historical, and reflects the fact that in the 1980 / 1990s internet, it was perfectly acceptable to reveal the IP address of end users of a service, but these days that results in breach of privacy and indeed facilitates abuse such as DoS or directed hacking attacks against IRC users. And hostmasking for the general public would address at least a major aspect of the problem, which affects or can affect many users beyond the help channel AOPs. Basically, the argument is cherrypicking helpers or opers for hostmasking functionality is not a good approach to begin with --- the protection could be extended to more users.
I am PapaSmurf on DALnet. This post has nothing to do with hostmasking for the general public. I have been assisting users, in DALnet help channels, since August/September 1998. Non-oper helpers, ever since I have been on IRC, have been subjected to packeting, DDoS, and computer invasions from annoying individuals.
-- -JH _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src -- holbrook / zort / srd SA: The halcyon team
On Mon, Jan 26, 2015 at 2:31 AM, Holbrook Bunting <holbrook@dal.net> wrote: [snip]
So to get something like this would mean adding into services a flag for say, helpers, into nickserv for a registered nickname.
Yes... Essentially services would need to trigger it immediately after completing any desired authentication procedure, and a NickServ per-nickname boolean flag would seem like the most likely candidate for such a function. Of course an alternative would be to not re-use NickServ-based authentication at all, and just have a single shared password, Or a separate database with usernames and passwords for the 'Helper mask' function, Or simply have a database of registered Google Authenticator TOTP tokens for qualified helpers. These may be more flexible, since it could actually be implemented independent of other services and not require NickServ identification, so the helper could login with a randomized nickname.
The only problem here is that until the user has identified to nickserv, or is using the applicable nickname when connecting and matching a user@host [snip]
Correct. The helper might be subject to the possibility of a premeditated attack from a persistent stalker. I would note, however... that there is a mechanism in bahamut where the user can configure a password in their IRC client, and if they connected to the server using a non-passworded I:Line, the IDENTIFY command is sent upon login, so they might often be identified before /NOTIFY triggers. There is the trouble that, the hostname is exposed if: (1) Services is down, And (2) There is a race condition, between the time the user logs in and the time services However, I think most such abuses are acts of opportunism, a requirement to perform reconnaissance first is increasing time and effort -- even if the shield provided is not perfect, it is setting a higher bar, so it is still an improvement. The above trouble situations or limitations show imperfections that could be improved upon, they don't really negate the benefit, and they should not deter or obstruct implementation. -- -Jimmy
I'm sending this from my phone so please excuse the top posting. Having given this some further thought, another way around the limitations from my previous email: Another possible workaround would be to implement a system similar to sqlines. Either: A) use nickserv nickname/password B) a nick setting for a separate password (think chanserv webpasswd) C) Separate list within services or stats This could allow immediate hostmask having the user sign on the same way opers do with oper hostmasking. This would allow it to be affective on all servers without requiring any extra work from the server admins. Or we could do user@host matching instead having either a network wide or server by server system similar to the system used on efnet (making it not exclusive to a specific group of people, but that would be an entirely different debate). On Monday, January 26, 2015, Jimmy Hess <mysidia@gmail.com> wrote:
On Mon, Jan 26, 2015 at 2:31 AM, Holbrook Bunting <holbrook@dal.net <javascript:;>> wrote: [snip]
So to get something like this would mean adding into services a flag for say, helpers, into nickserv for a registered nickname.
Yes... Essentially services would need to trigger it immediately after completing any desired authentication procedure, and a NickServ per-nickname boolean flag would seem like the most likely candidate for such a function.
Of course an alternative would be to not re-use NickServ-based authentication at all, and just have a single shared password, Or a separate database with usernames and passwords for the 'Helper mask' function, Or simply have a database of registered Google Authenticator TOTP tokens for qualified helpers.
These may be more flexible, since it could actually be implemented independent of other services and not require NickServ identification, so the helper could login with a randomized nickname.
The only problem here is that until the user has identified to nickserv, or is using the applicable nickname when connecting and matching a user@host [snip]
Correct. The helper might be subject to the possibility of a premeditated attack from a persistent stalker.
I would note, however... that there is a mechanism in bahamut where the user can configure a password in their IRC client, and if they connected to the server using a non-passworded I:Line, the IDENTIFY command is sent upon login, so they might often be identified before /NOTIFY triggers.
There is the trouble that, the hostname is exposed if: (1) Services is down, And (2) There is a race condition, between the time the user logs in and the time services
However, I think most such abuses are acts of opportunism, a requirement to perform reconnaissance first is increasing time and effort -- even if the shield provided is not perfect, it is setting a higher bar, so it is still an improvement.
The above trouble situations or limitations show imperfections that could be improved upon, they don't really negate the benefit, and they should not deter or obstruct implementation.
-- -Jimmy
-- holbrook / zort / srd SA: The halcyon team
I've read, thought and understood.. However, its not a one man voice anywhere in this world.. and DALnet is not one of those things. However, a hostmasking thing for ALL users would not be a bad thing. One for "helpers" of #official channnels would be... Holbrook Bunting skrev den 2015-01-27 03:33:
I'm sending this from my phone so please excuse the top posting. Having given this some further thought, another way around the limitations from my previous email: Another possible workaround would be to implement a system similar to sqlines. Either:A) use nickserv nickname/passwordB) a nick setting for a separate password (think chanserv webpasswd)C) Separate list within services or stats This could allow immediate hostmask having the user sign on the same way opers do with oper hostmasking. This would allow it to be affective on all servers without requiring any extra work from the server admins. Or we could do user@host matching instead having either a network wide or server by server system similar to the system used on efnet (making it not exclusive to a specific group of people, but that would be an entirely different debate).
On Monday, January 26, 2015, Jimmy Hess <mysidia@gmail.com <mailto:mysidia@gmail.com>> wrote:
On Mon, Jan 26, 2015 at 2:31 AM, Holbrook Bunting <holbrook@dal.net> wrote: [snip] > So to get something like this would mean adding into services a flag for > say, helpers, into nickserv for a registered nickname.
Yes... Essentially services would need to trigger it immediately after completing any desired authentication procedure, and a NickServ per-nickname boolean flag would seem like the most likely candidate for such a function.
Of course an alternative would be to not re-use NickServ-based authentication at all, and just have a single shared password, Or a separate database with usernames and passwords for the 'Helper mask' function, Or simply have a database of registered Google Authenticator TOTP tokens for qualified helpers.
These may be more flexible, since it could actually be implemented independent of other services and not require NickServ identification, so the helper could login with a randomized nickname.
> The only problem here is that until the user has identified to nickserv, or > is using the applicable nickname when connecting and matching a user@host [snip]
Correct. The helper might be subject to the possibility of a premeditated attack from a persistent stalker.
I would note, however... that there is a mechanism in bahamut where the user can configure a password in their IRC client, and if they connected to the server using a non-passworded I:Line, the IDENTIFY command is sent upon login, so they might often be identified before /NOTIFY triggers.
There is the trouble that, the hostname is exposed if: (1) Services is down, And (2) There is a race condition, between the time the user logs in and the time services
However, I think most such abuses are acts of opportunism, a requirement to perform reconnaissance first is increasing time and effort -- even if the shield provided is not perfect, it is setting a higher bar, so it is still an improvement.
The above trouble situations or limitations show imperfections that could be improved upon, they don't really negate the benefit, and they should not deter or obstruct implementation.
-- -Jimmy
-- holbrook / zort / srd SA: The halcyon team
_______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src
-- SaD @ Mozilla.DAL.Net Member of: Main Kline / OperTraining and Exploits Prevention team
participants (4)
-
Holbrook Bunting -
Jimmy Hess -
PapaSmurf -
SaD