mirror of
https://github.com/nsupdate-info/nsupdate.info.git
synced 2026-04-25 08:35:56 +03:00
[GH-ISSUE #332] Major security issue with nerdpol.ovh - Urgent! #261
Labels
No labels
bug
bug
duplicate
easy
easy
enhancement
enhancement
invalid
needs help
pull-request
scalability
security
task
urgent
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/nsupdate.info-nsupdate-info#261
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ghost on GitHub (Mar 26, 2018).
Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/332
if you go to the nerdpol.ovh site itself, your browser gives a "deceptive site" warning and additionally is not allowed to be used with LetsEncrypt certificates.
Any idea whats going on and if the domain site is infected?
Please inform the owner asap.
@elnappo commented on GitHub (Mar 26, 2018):
I'm the owner of nerdpol.ovh. I'm aware of the problem, sadly some people are trying to use subdomains under nerdpol.ovh for distributing malware and spam. As soon as we are aware of any abusive usage of hosts on nsupdate.info we blackhole them and close the issued user account. As for browser warnings, I'm regularly request review of the domain nerdpol.ovh in the Google Search Console to remove the warning.
Sorry for your trouble! I'll try to get the warning removed asap.
Related issues:
@ghost commented on GitHub (Mar 26, 2018):
Appreciate your feedback! please let us know when this is sorted. thanks
@ThomasWaldmann commented on GitHub (Mar 26, 2018):
BTW, this is the wrong place to deal with that.
That malware warning implementation is just wrong, you should complain to google/mozilla about it.
In case it is unclear: there is no malware or spam on nsupdate.info or nerdpol.ovh hosts.
The hosts that carry malware/spam are externally hosted sites that just have registered a hostname on the nsupdate.info or nerdpol.ovh domains.
If malware-idiots.org host has malware, it's also not the fault of the org domain.
@ghost commented on GitHub (Mar 26, 2018):
Well, elnappo stated that there are a lot of abusers and malware distributors that are abusing the domain hence why its been reported on google as a bad site in the first place which in turn causes cert issues.
Im not sure if google reports sites with malware for no reason.
@ThomasWaldmann commented on GitHub (Mar 26, 2018):
@2SI3NX what do you think would the org domain registry do if someone reported that there is malware on malware-idiots.org?
Also, do you think the org domain registry site should be warned about by browsers just because of the existence of sites like malware-idiots.org?
@ghost commented on GitHub (Mar 26, 2018):
@ThomasWaldmann Theres a big difference between a domain and a sub-domain in terms of who is responsible for issues, as there can be eg. 4 malware idiots with sub-domains causing a global problem for everyone else on that main domain.
To add to your example, the .org registry couldnt give 2 shits what people do with a domain(malware-idiots.org). Whereas an owner of a domain allowing other people to piggy-back on it to create sub-domains infested with malware has more a responsibility in finding the specific infection(sub-domain) and killing it entirely (as elnappo said).
Complaining to Google is pointless, they don't care who has malware and they will take their sweet time to de-list it from the blacklist. All they do is use a program to scan sites and auto-blacklist the full domain which can take ages to de-list (hopefully it doesnt)
Evidently, I felt it was my responsibility to report the actual problem on here anyway so that elnappo can take some kind of action against this or so that we can find a way (as you have come up with ideas in #284 & #31) to mitigate these problems.
@ThomasWaldmann commented on GitHub (Mar 26, 2018):
I see it as basically the same problem on another level. And btw, we do not do anything on the base domain, it is all on www. / ipv4. / ipv6. hosts.
There are criminals and idiots on this planet and we can't change that. Even if we kick the criminals and all their hosts, who holds them back from registering new users and the same or other hosts a minute later on either our service or just another dyndns service?
And just because of that, I think the google mechanism of concluding when a.b.c is bad, so b.c and *.b.c must be bad also is fundamentally flawed.
@elnappo commented on GitHub (Mar 27, 2018):
Review was approved yesterday afternoon. Flag is removed.