• 2 Posts
  • 214 Comments
Joined 1 year ago
cake
Cake day: April 27th, 2024

help-circle

  • TBH, 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.com and example service myservice, listen on port :12345 and drop everything that isn’t requesting myservice.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 to myservice.example.com:12345, also accept requests for otherservice.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?).














  • Yeah… I heard that too, about half a year after I got really into nix.

    To be honest, I try to keep away from community drama as much as possible, so I am not entirely up to date here. I think (and I might be wrong, if someone reading this knows better, correct me!) there’s three main points of contention:

    • Queer, PoC, and other “minority” users experienced harassment on (semi-)official channels (Github, Discord, Forums): That fucking sucks. I’m queer myself and lucky enough to not have experienced any of that in my time with Nix, but if I had not decided on Nix yet and learned about this before getting invested, it might have given me enough pause to not put any time into this. In all honesty however, that’s sadly a problem with many, many OSS projects.
    • Governance and Funding: I do not know much about the governance, afaik there was a bit of drama about the inventor of Nix acting like a (benevolent?) dictator for life, but those issues should have been resolved with a new governance model. The really big, inciting incident of a lot of community drama with Nix through was a bit over a year ago, when the committee in question decided to let Anduril fund a NixCon, against the explicit and loud protests of the community. That sucked. Hard. While obviously all kind of shit companies use all sorts of great OSS projects, inviting Anduril to sponsor your official conference is… not really understandable.
    • Conflicts of Interest: the aforementioned inventor of Nix owns a company heavily invested in the nix ecosystem. A bit reminiscent of the way that, say, Google holds Chromium by the balls, though to a much less severe extent. Miraculously, features that are “extremely unstable” in nix (but wanted by the community for a long time) suddenly get released in closed source to enterprise customers… However, the open source project is separate from, and not beholden to the whims of, said company.

    My position on all three points is this: They are not great; but a) they do not threaten the ecosystem, which is mature and independent of this drama, and not reliant on one or a couple of central, potentially problematic, people; and b) there are community projects that actively and effectively do distance themselves from all of these points (namely: Lix) and which are drop-in replacements for the core nix language and compiler, meaning if the upstream project actively did something to really piss you of, you could move with very little work to something independent of Nix.

    I hope this will not become necessary, because Nix is genuinely magic. Once you get the hang of it, nothing on your computer is particularly difficult anymore. You also get the best-in-class package management (and it’s easy! Once you have configured your own system to your liking, you already know everything you need to package your own software and contribute to nixpkgs!), being “bleeding edge” yet at the same time incredibly stable (seriously, I have switched all of my servers and VMs to Nix and I have not had one single incident once, including after updating machines after forgetting about them for 1.5+ years).

    Anyways. Sorry for the wall of text lol.


  • As someone else has said: NixOS. You said in a comment that you use Arch because of the AUR. Good news, nixpkgs is larger and fresher than the AUR, without needing to tap into any kind of third-party/unofficial repo.

    The unstable branch is essentially a rolling release (and very stable despite its name). I am happily gaming on it with Steam. During installation, you can just choose to not install a desktop. (However, due to how nix works, it’s trivial to rip out the entire DE at any point, should you so choose.)

    But it is a learning curve for sure. Steep, but not very long.