I tried using `tailscale funnel` against a dummy server `python -m http.server`, and within 10 seconds the bots started to check for vulnerabilities.
Tailscale warns you about how enabling it will issue an HTTPS certificate which will be in a public ledger. But I wasn't expecting it to be this quick.
I use Headscale, an open source implementation of Tailscale control server. And it doesn't have funnel functionality implemented out of the box, but I use a custom Traefik proxy manager Web UI in which I can expose ports on different Tailnet nodes.
In order to avoid exposing something unnecessarily in the certificate transparency logs, I use a single wildcard certificate, so all the subdomains are not listed anywhere automatically.
I use the same approach for services hosted in the internal subdomain, because I don't want everyone to know what exactly I'm running in my homelab.
Another approach I’ve seen is to route public access from Traefik/nginx through a single Cloudflare tunnel instead, and Tailscale/Headscale can be left for private network and server access.
The traefik box can have the single Cloudflare tunnel , and tailscsle can hang out behind the scenes.
This way tailscale funnel doesn’t need to be public.
There is the self hosted Cloudflare alternative that’s escaping my mind right now too.
Cloudflare also issues certs and logs them in transparency logs. If you do not create a wildcard cert in Cloudflare, your subdomains will leak. And Cloudflare offers free wildcard certs only on the domain root.
You don't have to serve any certificates on the default website. Web server would just fail TLS connection, since it doesn't have a certificate for it.
Not sure if this applies to all web servers, but at least Caddy and a few others support this.
A DoS that will disappear once you close the funnel. Tailscale are proxying the traffic so your public IP isn’t exposed. Your choice of port makes no difference.
This may discover services, but not hostnames. If the server does not disclose them (e.g. in the certificate used on the IP host), an attacker doesn't have much further to go on.
All the dev servers I've used over the past 10 years come with warnings that they're not security hardened, so I'd be wary of using `tailscale funnel` even though it is awesome to share like that so easily.
I wish this trend of “security through obscurity” should mean that all info should just be exposed would die, its silly and lacks basis in reality.
Even within infosec, certain types of information disclosure are considered security problems. Leaking signed up user information or even inodes on the drives can lead to PCI-DSS failures.
Why is broadcasting your records treated differently? Because people would find the information eventually if they scanned the whole internet? Even then they might not due to SNI; so this is actually giving critical information necessary for an attack to attackers.
The issue is not that obscurity per se is bad, but relying _only_ on obscurity is absolute the same as not having any security measures at all.
With the public ledger or not, you will still need to implement proper security measures. So it shouldn't matter if your address is public or not, in fact making it public raises the awareness for the problem. That's the argument.
Until it gets obscure enough that we start calling it “public-key cryptography”. Guess the prime number I'm thinking of between 0 and 2↑4096 and win a fabulous prize!
If you replace "security by obscurity" with "Kerckhoffs's principle", yes, absolutely!
The problem with using regular everyday obscurity is that it usually has a small state space and makes for terrible security, but people will treat it like it is cleverly hidden and safe from attackers
If I guess the IPv4 you're thinking of between 0 and 2↑32, ready or not, you win a free port scan
> So it shouldn't matter if your address is public or not, in fact making it public raises the awareness for the problem. That's the argument.
Forget about the internet, we've had almost 100 years to prove we can secure identity theft. And the best thing we can do is to keep our SSN's secret -- security through obscurity. Keeping your SSN private reduces your personal attack surface.
We've had 50 years to secure the internet, and yet, we still have zero day attacks. Nuclear submarines try their best to keep their locations a secret? Why? You cannot attack something you cannot see or hear.
Battleship sounds like a good analogy, but is very different because you don't have other options to "secure your ship" besides obscurity. If you had other options, let's say a sonar or moving your ship, they would definitely be used along with obscurity.
Besides, the time to scan the whole board is too time consuming in a battleship game, but scanning the whole internet on the other hand only take a few minutes[1]
You're talking IPv4 here, not IPv6. A 24 bit network has 254 addresses in IPv4. A 64bit subnet in IPv6 has 2^64.
If you can scan 1M ipv6's in a second, you can maybe scan 1 subnet in 584,942 years.
So if you're a firewall, and you notice scanning from a particular ip or network, it's easy enough to block them.
Also if you are scanning IPv4, you're not scanning addresses behind the NAT'd routers -- which is also effectively a form of obfuscation. So I would argue it's not the entire internet.
Okay, but we're not talking about that here. This is very much the case of a service being exposed that shouldn't be and relying on obscurity to try and avoid actually getting compromised
If something was temporary then it’s likely that it wouldn’t have been found in a meaningful amount of time to be exploited.
As an only line of defence it’s not good, but its also not good to hand-deliver your entire personal information to fraudsters and then claim that the systems should be more robust.
If you have a target on your own back thanks to cert transparency logs, it's a bit like closing the barn door late for you to find fault in your own being in Texas when sharpshooters are about. If your only defense was obscurity, your ass is hanging out, and it's no one's fault but your own when you find fault with others for simply saying so.
IME, moving ssh off the standard port reduces bot scanning traffic by >99%. Not only it means less noise in the logs (and thus higher SNR), but also lowers the chance you're hit by spray-and-pray in case there's a zero day in sshd (or any other daemon really).
True, but I hardly open any ssh to the wide world. I would only allow it inside a closed network anyways. HTTP on the other hand _needs_ to be exposed on 80 or 443 (not technically, but in practice)
The context of the conversation is that the address becomes publicly visible so you get hit with port scanners and script kiddies looking for vulns. Moving off standard ports does help but many of those are also going to look at ports like 2222 or 8022 and treat them as ssh.
It's not hard to just send something like `nmap -sV -p- <ADDRESS>` (or better, use like rustscan.) and you'll discover those ports and the services.
On the other hand, just install something like knocked and you don't have to do much. Knocking is not a difficult thing to set up.
Which is something that makes a notable difference. It’s telling the bots the OP listed are trying Vite endpoints, they’re targeting folks doing short term local web development. Removing obscurity and indicating relative likelihood of still being online is a big shift.
Yes. Yes, of course they do. Check for example https://crt.sh with your domain name to see the glorious public history of everything the certificates tell about your domain.
I don't see why people don't just run their own CAs more for private stuff.
If exposed for others I think the wildcard cert is also what I did, but most tutorials have you issuing certs via ACME for internal or local-only things which doesn't even need to happen.
I personally run my own CA and even setup an ACME server and internal DNS. Nobody knows what I am doing there.
It was common to set up your own CA at one point, especially when DNS management was more manual, However it presented a huge attack surface and was challenging to manage.
A compromised private CA can lead to widespread breaches, affecting various systems and applications that rely on its certificates.
The CAB forum working groups being explicitly prohibited from working on private networks (at least historically) and market incentives also produced a situation where you can't really reduce the blast radius.
ECS1 attacks on AD CS is probably the best publicly documented case for further research.
The happy path is often manageable, but still complex, bland any mistake will result in huge risks.
For me, the value proposition isn’t there. I can get a wildcard domain signed from let’s encrypt and it works out of the box on every device, and you don’t have to deal with the fact that some/many appps will ignore your OS certificate rules.
Tailscale warns you about how enabling it will issue an HTTPS certificate which will be in a public ledger. But I wasn't expecting it to be this quick.