Earlier quoted context omitted.
"Darknet collection during final /8 run-down captured audio in UDP." Mind elaborating on this? SIP traffic from which year?
2010/2011 time frame. Google and others helped sink the traffic, all written up at apnic labs. It's how 1.1.1.0/24 got held back from general release.
When internal hostnames are leaked to the clown
201–210 of 265 posts
Re: When internal hostnames are leaked to the clown
#202This is exactly why I have a number of "appliances" which never get clown updates: have addresses in a subnet I block at the segment edge, have DNS which never answers, and there are a few entries in the "DNS firewall" [0] (RPZ) which mostly serve as canaries.
This is the problem with the notion that "in the name of securitah IoT devices should phone home for updates": nobody said "...and map my network in the name of security"
[0] Don't confuse this with Rachel's honeypot wildcarding *.nothing-special.whatever.example.com for external use.
Re: When internal hostnames are leaked to the clown
#203Earlier quoted context omitted.
You can run a container on Synology and install your custom services, tools there. At least that is what I do. For custom kernel modules you still need a Synology package for something like Wireguard. If you have OPNSense, it has an ACME plugin with Synology action. I use that to automatically renew and push a cert to the NAS. That said, since I like to tinker, Synology feels a bit restricted, indeed. Although there…
The extremely old kernel on Synology makes it hard or impossible to run some containers.
I have a fairly recent DS920+ and never had issues with containers - I have probably 10+ containers on it - grafana, victoriametrics/logs, jellyfin, immich with ML, my custom ubuntu toolboxes for net, media, ffmpeg builds, gluetun for vpn, homeassistant, wallabag,...
Edit: I just checked Grafana and cadvisor reports 23 containers.
Edit2: 4.4.302+ (2022) is my kernel version, there might be specific tools that require more recent kernels, of course, but I was so far lucky enough to not run into those.
Re: When internal hostnames are leaked to the clown
#204Earlier quoted context omitted.
The (somewhat affordable) productized NASes all suffer from big tech diseases. I think a lot of people underestimate how easy a "NAS" can be made if you take a standard PC, install some form of desktop Linux, and hit "share" on a folder. Something like TrueNAS or one of its forks may also be an option if you're into that kind of stuff. If you want the fancy docker management web UI stuff with as little maintenance as…
The real trick, and the reason I don't build my own NAS, is standby power usage. How much wattage will a self built Linux box draw when it's not being used? It's not easy to figure out, and it's not easy to build a NAS optimized for this. Whereas Synology or other NAS manufacturers can tell me these numbers exactly and people have reviewed the hardware and tested it.
There are power meters like KWS-303L that will tell you how much manufacturers lie with their numbers.
For example my ancient tplink TL-WR842N router eats 15W standby or no, while my main box, fans, backlight, gpu, hdds and stuff -- about 80W idle.
Looking at Synology site the only power I see there is the psu rating, which is 90W for DS425. So you can expect real power consumption of about 30-40W. Which is typical for just about any NUC or a budget ATX motherboard with a low-tier AMD-something + a bunch of HDDs.
Re: When internal hostnames are leaked to the clown
#205Earlier quoted context omitted.
Marginally better for sure but in this case the path would also have been "leaked" to the sentry instance owned by developers of the the NAS device phoning home. This can happen in zillions of ways and is a good reason to use relatively opaque urls in generally and not "friendly ids" and generally being careful abou putting secrets in URLs.
Just try it. The first example gets attacked by bots nearly immediately after issuing a TLS cert. The second one usually doesn't get detected at all.
What if you have a wildcard cert for *.example.com?
Re: When internal hostnames are leaked to the clown
#206Earlier quoted context omitted.
Just try it. The first example gets attacked by bots nearly immediately after issuing a TLS cert. The second one usually doesn't get detected at all.
What if you have a wildcard cert for *.example.com?
Much better. But you still leave traces from dns queries.
Subfinder has a lot of sources to find subdomains, not only certs: https://github.com/projectdiscovery/subfinder
Re: When internal hostnames are leaked to the clown
#207Is "clown GCP Host" a technical term I am unaware of, or is the author just voicing their discontent? Seems to me that the problem is the NAS's web interface using sentry for logging/monitoring, and part of what was logged were internal hostnames (which might be named in a way that has sensitive info, e.g, the corp-and-other-corp-merger example they gave. So it wouldn't matter that it's inaccessible in a private netw…
with clown=cloud, GCP must mean google clown platform
Re: When internal hostnames are leaked to the clown
#208I have investigated similar situation on Heroku. Heroku assigns a random subdomain suffix for each new app, so URLs of apps are hard to guess and look like this: test-app-28a8490db018.herokuapp.com. I have noticed that as soon as a new Heroku app is created, without making any requests to the app that could leak the URL via a DNS lookup, the app is hit by requests from automatic vulnerability scanning tools. Heroku c…
Really? Is that new? My apps use wildcard domains: https://i.postimg.cc/SQ82S0Dp/image.png
Re: When internal hostnames are leaked to the clown
#209Re: When internal hostnames are leaked to the clown
#210I personally have been blocking sentry and all relevant domains on my machines.
I understand this is not a generally applicable advice. For me that’s the right choice