yatralalala

Internet is no longer decenstralised.

Some interesting DNS data https://news.ycombinator.com/item?id=46159249

Given what's happening with Cloudflare downtimes, we looked at internet centralisation.

GoDaddy and Cloudflare alone host ~106 millions of domains – about one-third of all the domains. The top 10 providers sit on over half of all the domains.

I'm all for in for it. Sadly, companies host wild stuff and forget about it.

What we build is primarily focused on companies that have at least hybrid stack - some on prem, some in cloud. If you completely behind load balancer and have strict change management, we can't bring you any value.

In ideal world, we wouldn't have any business. But oh boy... Companies host wild stuff.

Every single conversation I had with clients ended up with us showing some of their infra and the response was "wow, we didn't know this is ours".

I'm building Recon Wave (https://reconwave.com) - we monitor companies online perimeter and let them know when something's wrong.

Recon Wave basically finds and scans all their services - DNS, IPs, Apps, Ports - and notify customers when it breaks some policy (aka. "no ports than 443 should be open") or when some service is straight vulnerable.

I'm former security engineer and I hated all that "critical reports" that reported missing CSP header.

We're now playing with an idea to build LLM pentesting agent that could run agains the whole infra of our customers.

Sorry for a bit of self promo, but just to explain we run https://reconwave.com/, basically EASM product but more focused on network/DNS/setup level.

Finding all things about domains is one of the things that we do. And yes, it's very easy.

There are many services like subdomainfinder - i.e. dnsdumpster and merklemap. We built our own as well on https://search.reconwave.com/. But it's a side project and it does not pay our bills.

See my comment above https://news.ycombinator.com/item?id=43289743 there are many techniques!

Zone transfers are super interesting topic. Thanks for mentioning that.

It's basically the way how to get all DNS records a DNS server has. Interestingly in some countries this is illegal and in some this is considered best practice.

Generally, enabled zone transfers is considered as misconfiguration and should be disabled.

We did research on that few months back and found out that 8% of all global name servers have it enabled.[0]

[0] - https://reconwave.com/blog/post/alarming-prevalence-of-zone-...

If you're using infra in a way [cloudflare -> your VM] I'd recommend setting firewall on the VM in a way that it can be accessed only from Cloudflare.

This way, you will force everyone to go through Cloudflare and utilize all those fancy bot blocking features they have.

Lifehack - it's especially awesome in cases where server operator is using self-signed certs / private cert authorities. Because you will not find these in public cert logs.

As always, depends on your threat model. Generally having private IPs in public DNS is not great, because potential attacker gets "a general idea" how your private net looks like.

But I'd say there's no issue if everything else is secured properly.

I sadly did not see the comment above, but I'd like to just add, that this bruteforce and sniffing methods are target only against our paying customers.

We built global reverse-DNS dataset solely from cert transparency logs. Our active scanning/bruteforcing runs only for assets owned by our customers.

So many thoughts on that, but from my perspective - obscurity is ok, but you can not depend on it at all.

Great example is port knocking - it hides your open port from random nmap, but would you leave it as the only mechanism preventing people getting to your server? No. So does it make sense to have it? Well maybe, it's a layer.

Kerckhoffs' principle comes to my mind as well here.

So while I agree with you on that's obscurity is fine strategy, you can never depend on it ever.

Hi, our company does this basically "as-a-service".

The options how to find it are basically limitless. Best source is probably Certificate Transparency project as others suggested. But it does not end there, some other things that we do are things like internet crawl, domain bruteforcing on wildcard dns, dangling vhosts identification, default certs on servers (connect to IP on 443 and get default cert) and many others.

Security by obscurity does not work. You can not rely on "people won't find it". Once it's online, everyone can find it. No matter how you hide it.

similar thing - https://search.reconwave.com/ - but it's passive and includes reverse dns search (all domains for given IP)

TLDR: they're used as a revocation mechanism for DKIM.

non "paywalled" link: https://threadreaderapp.com/thread/1852021884902138123.html

TIL: there's .su gtld

Very nice, I read one of your blog posts [0] and was pretty surprised, great read! Good luck on your journey.

[0] https://reconwave.com/blog/post/storing-private-keys-in-txt-...

Yup, it kinda makes sense, but I agree with other commenters there that plausible deniability is not as strong here.

Oh wow, just recently started a discussion about this on reddit [0]. Still seems pretty bad idea in all possible scenarios. I don't believe that this "plausible deniability" would be a thing there.

[0] https://www.reddit.com/r/sysadmin/comments/1fn3f25/found_rsa...

Have you heard about Wire? Groups up to 500, when they switch to MLS protocol then thousands, e2e, Swiss based and it has kind of ok UI.

Wire has backups and is e2e even for groups and all.

Allow me to introduce you to Katlib - collection of extension functions I and my colleges wrote for last four years of server side Kotlin development. It contains around 75 extensions or functions that we're missing in the Kotlin standard library.

Fully opensourced, with test coverage between 60-70% and a single dependency for logging.

Collection of Kotlin extension functions gathered through 3 years of server side Kotlin development.