- 3 Posts
- 240 Comments
2·6 days agoTBH, it sounds like you have nothing to worry about then! Open ports aren’t really an issue in-and-on itself, they are problematic because the software listening on them might be vulnerable, and the (standard-) ports can provide knowledge about the nature pf the application, making it easier to target specific software with an exploit.
Since a bot has no way of finding out what services you are running, they could only attack caddy - which I’d put down as a negligible danger.
My ISP blocks incoming data to common ports unless you get a business account.
Oof, sorry, that sucks. I think you could still go the route I described though: For your domain
example.comand example servicemyservice, listen on port:12345and drop everything that isn’t requestingmyservice.example.com:12345. Then forward the matching requests to your service’s actual port, e.g.23456, which is closed to the internet.Edit: and just to clarify, for service
otherservice, you do not need to open a second port; stick with the one, but in addition tomyservice.example.com:12345, also accept requests forotherservice.example.com:12345, but proxy that to the (again, closed-to-the-internet) port:34567.The advantage here is that bots cannot guess from your ports what software you are running, and since caddy (or any of the mature reverse proxies) can be expected to be reasonably secure, I would not worry about bots being able to exploit the reverse proxy’s port. Bots also no longer have a direct line of communication to your services. In short, the routine of “let’s scan ports; ah, port x is open indicating use of service y; try automated exploit z” gets prevented.
I am scratching my head here: why open up ports at all? It it just to avoid having to pay for a domain? The usual way to go about this is to only proxy 443 traffic to the intended host/vm/port based on the (sub) domain, and just drop everything else, including requests on 443 that do not match your subdomains.
Granted, there are some services actually requiring open ports, but the majority don’t (and you mention a webserver, where we’re definitely back to: why open anything beyond 443?).
Client side, under advanced:
1·9 days agoLink?
That’s a setting
InfCloud. Works well with Radicale, and does contacts, too.
It’s not pretty, but works very well for the 5/100 times I want to check through a browser instead of Calendar app / Thunderbird.
Yes. Using simple-nixos-mailserver as the foundation.
Really great experience, and have had no deliverability issues.
13·23 days agoI honestly don’t get the hostility, wtf.
If you prefer something other than Jellyfin, good for you.
Sorry, but the person above made a blanket statement that Jellyfin sucks for music streaming.
Alas, it does not; example: me, guffaw
Have zero problems with Jellyfin as the Server, Symfonium as the client on mobile / music assistant for streaming to sonos at home
281·27 days agoHow does it feel to have the objectively best sense of humor?
Out of curiosity, where on this curve lies “20k lines of Nix config”? (Asking for a friend 👀)
3·1 month agoPiefuckers
No problem. If you do decide to give NixOS a try, feel free to ask about anything should things be unclear :)
A substantial amount of open source devs will probably just give up working on their projects if they can no longer be installed by most users.
That will also affect Graphene users.
Graphene will also only work until Google one day says “You know what… No!” and stops allowing it on their (new) hardware. I don’t think that’s far in the future.