Login or Registration does not work.

[stokito]

I can't sign up into the site. How long the registration will be closed?

[ThomasWaldmann]

I won't reopen it (== self service account creation) in the near future.
Also, all external authentication methods (twitter, github, google, ...) are disabled.

There is just too much abuse by criminals and I neither want to support their actions nor deal with deleting their stuff all the time.

Account owners who can't login any more (because they used some external authentication and did not set a local password or forgot the local password) can write me an email to info @ nsupdate.info:

• email from: should be the address used in the account
• alternatively, give your user name
• state some of your hosts (makes it easier for me to find your account)

I will then set a new temporary password for you, so you can log in again.

[stokito]

Interesting how other DDNS providers working with abuses. In the DuckDNS FAQ said

Q: Do you have an Abuse policy?

A: yes, we will block, as much as we can anyone who is abusing our service, see our Terms of Use and Privacy Policy. If you have any issues please use the Google Group to contact us

https://www.duckdns.org/faqs.jsp

Maybe this is solvable somehow.

The bigger problem is for tunnels providers.
I remember this article https://pagekite.net/2018-07-18/Phishing_and_spam
The Ngrok also spent a lot efforts to stop spam
https://ngrok.com/abuse
here is some examples
https://medium.com/@g33xter/phishing-with-ngrok-252309890b87

Maybe their experience may be useful

[sporkman]

Interesting how other DDNS providers working with abuses. In the DuckDNS FAQ said

Q: Do you have an Abuse policy?
A: yes, we will block, as much as we can anyone who is abusing our service, see our Terms of Use and Privacy Policy. If you have any issues please use the Google Group to contact us

https://www.duckdns.org/faqs.jsp

Maybe this is solvable somehow.

The bigger problem is for tunnels providers. I remember this article https://pagekite.net/2018-07-18/Phishing_and_spam The Ngrok also spent a lot efforts to stop spam https://ngrok.com/abuse here is some examples https://medium.com/@g33xter/phishing-with-ngrok-252309890b87

Maybe their experience may be useful

Running a free service like this AND keeping it clear of people trying to use for C&C servers and other nefarious purposes, and then also fighting DDoS attacks from both good guys and bad guys is a full-time job. In theory, sure, any of us could set this up on a bunch of VPSs out there and advertise it as "free dynamic dns service", but without a small team of people constantly babysitting it, it's just not practical.

Just glad the software exists so I can self-host (and I'm looking at this because DuckDNS is again intermittent all weekend long).

[luckman212]

@sporkman Is there a fairly simple guide or any steps on setting up a selfhosted instance from scratch on a VPS (DigitalOcean etc)?

[stokito]

@ThomasWaldmann could you please explain how criminals are using the service?
As far I understood they are making a phishing like bank.nsupdate.info or they just need for any domain for their website?
In first case we may make a filter by registred trademarks and banned words. And we may require for domain to start from bad so that users will see badbank.nsupdate.info and this should make them more cautios.

But if criminals just need for any domain and they don't want to register because it needs for a credit card then this makes it more dificult. The only solution would be to require a payment of 1$ and then rollback.
Maybe you can create a group of moderators voulontiers who can review emails about abuses. How many of abuses letters do you receive?

I'm asking because I made my own ddns server and I need to know how to protect.

I decided to use a different approach. I want to make my users to be automatically registered. So they'll just generate a long random domain (uuid or ed25519 pub key) and token and configure a ddns client. The new domain with the token are registred and any next updates will require of the same password.
Since the domains are not human readable then nobody interested for a sqoting. Not used domains will be removed after a period.

P.S. my ddns server poc https://github.com/yurt-page/go-ddnsd

[ThomasWaldmann]

Well, as far as i could see / got notified of:

• they register an arbitrary dyndns hostname to point to a distribution host of illegal material (e.g. CSAM), malware (computer virus/trojan infected stuff) or copyright violations (ebooks, movies, ...)
• they register specific dyndns hostnames to point to fishing sites, like somebank.nsupdate.info, somepostalservice.nsupdate.info - they are rather creative with these so it is hard to blacklist them, even when using regexes.
• they register specific dyndns hostnames to sell fake / questionable products
• they register less specific dyndns hostnames for other sites with services for their criminal operations.

I think a simple list of trademarks / registered names would be huge and won't solve the problem. E.g. if you had wellsfargo (a bank) on your list, the abuser would just use wells-fargo or we11sfargo or wellsfarg0 or ... - some are even hard to match with regexes.

I thought about obligatory payments. That might deter some of the criminals, because that would harm their anonymity and some kind of information about them might be in reach for criminal investigators then. But I guess even that could be worked around, just by abusing the credit card of someone else. Also, I don't like that, because it would basically turn the free service into a commercial one, cause more work for me and would be either for nothing or would be more expensive...

There is no "moderation admin interface" (yet?) for the nsupdate.info software (I currently do that via the django admin). In any case, I would only give access to very trusted persons I personally know.

Using random (like uuid) hostnames and not allowing the user to choose the hostname removes some of the criminal use cases, but not all. Of course, it also removes some of the reasons why legitimate users want to have a dyndns name in the first place (== because they can remember it easily). It also removes some pattern matching options for the admin to fight criminal abusers.

About removing inactive hostnames after some time: we also do that (after a rather long time), but it first notifies the users multiple times via email about that this is going to happen if there is no activity. This is not completely unproblematic, because sometimes users give fake email addresses or just don't get or read our emails. Hostnames that are not updated for longer times usually happen for cable internet providers (IP does not change).

It is a good practice to not update the dyndns host if the IP did not change, BUT still send 1 monthly unconditional update just to signal "hey, I am still alive and using this dyndns host".

About self-registration, oauth (external accounts):

• when only using local accounts on nsupdate.info and disallowing self-registration, i have some control over who can create dyndns hosts and who not. if some user gets on the radar by creating scam hostnames, i can delete the user account and all their hosts and they won't get in again easily.
• when allowing self-registration, a user who was removed can easily just create a new account (using a new name / email address) and can continue abusing the service until they get noticed again. this is an endless whack-a-mole game...
• when allowing external accounts (oauth, twitter, github, ... logins) it even gets more comfortable for the abusers, because they can maintain e.g. a twitter account (which i have no control over) and the nsupdate.info service then would just auto-create a profile for them based on that twitter account. even if i removed their hosts and their profile, they could immediate get in again and just recreate their hosts.

Since I have removed self-registration and external accounts, the amount of abuse has significantly decreased (also the amount of abuse notifications I get via email).

But I usually can't keep up with new user registration request emails (also hard to know how they will use the service), so in the past months I focussed on helping existing users to get into their accounts again (e.g. if they only had used the external auth [disabled now], but did not set a local password).