Comment by abdusco | Hacker News Reader

Comment by abdusco | Hacker News Reader

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.

    127.0.0.1 - - [10/Aug/2025 00:11:34] "GET /@vite/env HTTP/1.1" 404 -
    127.0.0.1 - - [10/Aug/2025 00:11:34] code 404, message File not found
    127.0.0.1 - - [10/Aug/2025 00:11:34] "GET /actuator/env HTTP/1.1" 404 -
    127.0.0.1 - - [10/Aug/2025 00:11:34] code 404, message File not found
    127.0.0.1 - - [10/Aug/2025 00:11:34] "GET /server HTTP/1.1" 404 -
    127.0.0.1 - - [10/Aug/2025 00:11:35] code 404, message File not found
    127.0.0.1 - - [10/Aug/2025 00:11:35] "GET /.vscode/sftp.json HTTP/1.1" 404 -
    127.0.0.1 - - [10/Aug/2025 00:11:35] code 404, message File not found
    127.0.0.1 - - [10/Aug/2025 00:11:39] "GET /s/7333e2433323e20343e2538313/_/;/META-INF/maven/com.atlassian.jira/jira-webapp-dist/pom.properties HTTP/1.1" 404 -

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.

Appreciate this super valid consideration.

If services are being exposed for friends and family, using cloudflare tunnels might be a trade off between security or convenience.

If the goal is to ensure security of a home lab online, the less of it that’s discoverable by automated bots, etc, the better.

Yeah, I have mixed feelings about CT (certificate transparency) for this reason. Folks are just consuming the firehose and scanning.

And in this case, if the thing you're funnel'ing is on your residential connection, it basically amounts to you summoning a DDoS.

One (obvious?) tip I'd offer is to put your stuff on high non-standard ports if you can. It'll reduce the amount of connections you get dramatically.

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.

When you care about this, if you're managing your own certificates, you can issue wildcard certificates.

Hmm, yeah, that's a great suggestion, thanks!

Also serve the default website (via IP) from a basically empty self-signed certificate that doesn't give away any domain names or owner details.

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.

Even without CT, services on standard ports will quickly be discovered on IPv4.

> On a computer with a gigabit connection, ZMap can scan the entire public IPv4 address space on a single port in under 45 minutes.

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.

Wait, so bots watch for new records added to this HTTPS cert public ledger, then immediately start attacking?

To me that sounds like enabling HTTPS is actually a risk here…

The server was already exposed. All this does is remove obscurity

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.

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.

> relying _only_ on obscurity

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

As per another comment, we can scan a single port on every public IPv4 address in less than an hour.

Trying every 256bit number gets into a "slightly" larger problem.

> 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.

Except we are more on a chess table where we can just trivially probe each cell, unlike the vast volume of the ocean.

A game of battleship is indeed a good analogy!

Just because its a finite space that may eventually be discovered is a poor reason to announce where things are!

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]

[1]: https://github.com/robertdavidgraham/masscan

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.

Well, this is a bad example, considering public/private key pairs exist,

and work for identity validation,

as long as you don't farm it out to a cheap, know-nothing vendor.

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

ironically I would double down even harder then;

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.

https://en.wikipedia.org/wiki/Texas_sharpshooter_fallacy

In my original comment I said (I thought) quite clearly that obscurity as your only defence is a terrible idea.

But painting a target on your back is not exactly justified just because hiding yourself isn’t a good defence in of itself.

Obscurity couldn't be anyone's last/best defense, unless it was their only defense, was my point.

In any case, I think we agree.

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)

> IME, moving ssh off the standard port reduces bot scanning traffic by >99%.

Depends on the site I expect. My low value domains get NO ssh attempts on my random ports. The high value ones get a few each week.

You could also always add port knocking or something like that.

If you're going to that level, just put it behind a VPN.

Tailscale is a VPN...

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.

> Tailscale is a VPN...

And if you use it as a VPN and don't turn on the funnel feature, your service won't be exposed.

> 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.

Neither is wireguard.

lol your solution to a problem caused by a feature is "don't use that feature?" LGTM

Presumably wireguard was already being used?

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.

Reply on news.ycombinator.com