- Helpers - nomad.dal.net

User hostmasking is around the corner!
by Ryan Smith 09 Aug '22

09 Aug '22

Hello, helpers community! Over the past couple years, the ircd and SRA coding teams have been working on adding support for user hostmasking. It's a big change for DALnet, affecting many different pieces of code (bahamut, services, stats), how we handle bans, how we handle logging, etc. It's at the point now where we feel our systems are ready for a production deployment. We're going to do this as a staged roll out, meaning only a couple small servers will have user hostmasking enabled to start. All users on all servers will be able to see the hostmasks that are in use, but only users on the enabled servers will be able to set/remove hostmasking to start. If all goes well, we'll continue enabling hostmasking on more and more servers until all servers are enabled. We expect the full roll out to take about 2 weeks, give or take. We've done an extensive amount of testing on the test net, but there is still a possibility that a bug may crop up somewhere. Please email coders(a)dal.net for any ircd/bahamut bugs you encounter and sra(a)dal.net for any services/stats bugs you encounter. == How does it work? == When a user connects to a hostmask enabled server, they will automatically be set usermode +H, which shows their masked hostname. For example, a user that connects with host 10-23-23-116.server.myisp.net would be visible to other users as bdc7-7c7a-9179-7486-6846.server.myisp.net. A user who connects with IP address 10.20.17.4 would be visible to other users as f0c6-d3de-b094-6eeb-5c7.20.10.ip. We are using a hashing algorithm, so the same host or IP will always be masked to the same result even if the user reconnects. The masked hostname is not changeable by users and users cannot request a specific hostmask. When +H is on, the masked hostname will show in /whois, in channel joins/parts, and any other place a hostname is shown in ircd or services. /who will show whichever host is currently in use; if the user is +H, it'll show the masked host, otherwise it'll show the real host. The user has the option to set usermode -H to show their real hostname or IP. In order to set or remove the H usermode, the user must not be in any channels. This is keep client-side channel lists in sync. There is a limit of 2 usermode H changes in 5 minutes as a flood mitigation measure. == What about ban evasion? == Any ircd or services feature that supports an address mask (access lists, bans, exempt lists, invite lists, HOP/VOP/AOP/SOP masks, AKILLs, etc.) will accept either the real hostname, the masked hostname, or the real IP and will apply no matter if the user is +H or -H. For example, I could ban the above user with *!*(a)10*.server.myisp.net or *!*(a)10.23.* and the ban would still be effective even if the user is masked. Our systems will check the address mask against the real hostname, the masked hostname, and the real IP. We've included the above information in a FAQ that is available to all users at: https://www.dal.net/kb/view.php?kb=450 If users have any questions that aren't answered in the FAQ, please refer them to #operhelp. Happy testing and masking! -- Ryan Smith <xpsycho(a)dal.net> Server Administrator (foxtrot/sakura) and SRA Lead The DALnet IRC Network PGP Fingerprint: 8A27 3349 2B43 D378 6349 8674 F13A D7BA C90E D44E

1 0

Small change to AUTH link work flow
by Ryan Smith 20 Jun '20

20 Jun '20

We just pushed out a small change to the AUTH link work flow. In the past, a user would click the users.dal.net AUTH link and the AUTH request would immediately be processed. There's a fatal flaw in this logic though. Some email providers and antispam/antivirus packages scrape or preview all email links to see if the links are "safe". If an automated process like this previews the AUTH link URL, it'll be as if the user clicked the link and authorized the change. Sometimes the user doesn't want this to happen, like during the email address change process where clicking the first email link will abort the email change. Effective immediately, we now require all user.dal,net AUTH links to be confirmed in the browser by the user. When they first click the AUTH link, they'll see a message, "Click below to confirm you would like to process an AUTH request for the nick BLAHBLAH." The AUTH request will not be processed until the "Confirm" button is clicked, something that an automated crawler will not do. Thanks to sps for bringing this to our attention. -- Ryan Smith <xpsycho(a)dal.net> Server Administrator (foxtrot.dal.net) and SRA The DALnet IRC Network PGP Fingerprint: 8A27 3349 2B43 D378 6349 8674 F13A D7BA C90E D44E

1 0

Re-enabling the expiration system
by Kobi Shmueli 26 Mar '19

26 Mar '19

Hi all, We have re-enabled the expiration system. Starting today, inactive nicks will expire after 3650 days (10 years) from the last time they were used. Nicks will continue to be marked as "inactive" after 30 days, however, if they will remain inactive for years, they will expire (purged from our database) after 3650 days (10 years). Also, in order to fight services abuse, frozen nicks will *not* be able to be requested for at least one year after being frozen. Link to the news article we just published: https://www.dal.net/news/shownews.php?id=165 For the SRAs, -Kobi.

1 0

Services update (2019-02-04) - NickServ AUTH
by Kobi Shmueli 04 Feb '19

04 Feb '19

FYI - We have disabled the NickServ AUTH command for authorizing newly registered nicks. New nicks must be AUTH'ed with the users.dal.net website. If someone is having problems to authorize their nick due to being detected as an open proxy/public VPN, please refer them to #OperHelp who can look into it further and help or deny them. For the SRAs, -Kobi.

1 0

Services update (2019-01-04)
by Kobi Shmueli 03 Jan '19

03 Jan '19

Hi all, Due to abuse, DALnet has decided to restrict access for users on public VPN services. By default, these users will be squelched until they identify to NickServ. They'll see something like this upon connect: -monitor.dal.net- Due to abuse, DALnet has decided to restrict access for users on public VPN services. -monitor.dal.net- You must identify to a registered nick to continue to use the network. See https://www.dal.net/kb/view.php?kb=436 for more information. Also, we recently added two new xflags to ChanServ: NO_VPNS - no connections from public VPN services will be allowed (on/off) NO_SHELLS - no connections from shell providers will be allowed (on/off) These xflags honor EXEMPT_REGISTERED and EXEMPT_IDENTD (but do not honor EXEMPT_INVITES at this time). TitanUS, our pseudo bot will enforce these xflags (i.e. kickban vpn users who join NO_VPNS:ON channels). For the SRAs, -Kobi.

1 0

Services upgrade (2018-11-26)
by Kobi Shmueli 25 Nov '18

25 Nov '18

Hi all, We just did a major upgrade to services (v2.8.0), it has 60+ changes... here are some of the visible changes: 1. ChanServ VOP command (Auto Voice list). 2. ChanServ VOICE command. 3. ChanServ DEVOICE command. 4. ChanServ SET VOICEGUARD command. 5. Extended information about AKICK/VOP/AOP/SOP/MANAGER lists (like who added the entry, when it was added, when it was last used, etc). 6. AKick reasons. 7. nick!user@host masks can't be added VOP/AOP/SOP/MANAGER lists when IDENT is enabled on the channel. Also, the services help session on #ServHelp will start in ~90 minutes. Visit https://www.dal.net/news/shownews.php?id=157 for more information. For the SRAs, -Kobi.

1 0

Services upgrade (2018-11-10)
by Kobi Shmueli 10 Nov '18

10 Nov '18

Hi all, We just upgraded services.* and added two new xflags to the ChanServ XFLAG command: NO_NICK_CHANGE - no nick changes allowed on the channel (on/off) NO_UTF8 - messages with strange characters (Hebrew/Arabic/UTF8) will be blocked (on/off) Both of these xflags require bahamut 2.1.2+ so not all servers support them yet but we plan to upgrade all servers soon. Also, another "new" feature Bahamut 2.1.2+ brings is a change to cmode +p: from now on, +p channels will be hidden from /list but not from /whois (unless they're also +s, +s will continue work the same and will hide channels from both /list and /whois). For the SRAs, -Kobi.

1 0

Services update
by Kobi Shmueli 19 Oct '18

19 Oct '18

Hi all, We just upgraded services.* with a few changes: *** New xflags have been added to ChanServ XFLAG *** 1. USER_VERBOSE - send failed command messages to #channel-relay (on/off). 2. HIDE_MODE_LISTS - hide /mode #channel +b/+I/+e lists from non-ops (on/off). 3. AUTOMSG - tell everyone who joins that the channel is protected (on/off). This was previously a part of the recommended command and we got many requests from users to let them use it without using the recommended settings so here it is. Note: USER_VERBOSE and HIDE_MODE_LISTS are new bahamut 2.1.1 features so they will only work on upgraded servers (only nonstop.* for now). *** Relay channels (#channel-relay) *** 1. Relay channels are used by both cmode +A (auditorium) and the USER_VERBOSE xflag. 2. They can only be registered by the real channel's founder. When registered, it will function just like a normal channel. 3. When un-registered, only AOPs+ of the real channel as well as IRC Operators will be able to join. Others will be kickbanned by ChanServ just like restricted access channels. 4. ChanServ INVITE will work for relay channels even if they're not registered. For the SRAs, -Kobi.

1 0

Services update
by Kobi Shmueli 07 Oct '18

07 Oct '18

Hl all, Here are some highlights about the latest services update: - ChanServ XFLAG command has been added to let managers/founders control extended channel flags. - ChanServ SET #channel MLOCK now supports +P & -P. - New command: /motd teams.* - /motd services.* will now show on-line CSops in bold. - /whois of opers now includes information about their services access and team membership. (We will send an official announcement about this later today) For the SRAs, -Kobi.

1 0

New DALnet feature: SpamFilter
by Kobi Shmueli 03 Oct '18

03 Oct '18

Hi all, We just announced spamfilter on the website: https://www.dal.net/news/shownews.php?id=153 We're happy to announce that DALnet is adding a new feature called "spamfilter" that will help us in the fight against spam. SpamFilter is a new addition to DALnet's IRCd (Bahamut), it is very flexible, and spam can be identified in private messages, notices, kick messages, quit messages, channel topics, away messages, channel messages, and channel part messages. Basically, if a particular piece of spam message is in our database, it can be recognized and dealt with. Please note that no human will see your messages or be able to read them (unless they were triggered as spam). This is a purely automated system, and experienced IRC Operators (mostly CSops) will be the only people who can add spam to the database. SpamFilter will be DEFAULT ON for everyone (all users and all channels). While we believe most of you will like this feature, some of you may not want to use it (for one reason or another) so we have added an option to opt-out: If you do not want SpamFilter protection on your nick, just type /mode yournick +P If you do not want SpamFilter protection on your channel, type /mode #channel +P This will mean that any messages going to you or your channel will not be screened by the database. A Q&A knowledge base article will be published soon at: http://www.dal.net/kb/view.php?kb=411 For the SRAs, -Kobi.

1 0