Earlier quoted context omitted.
Maybe I'm just a security nut, but I would probably also relegate ssh to a non-default port, allow key-only authentication, narrow ciphers, close all other ports (except 80, 443, and 53). Also fail2ban, sysctl tweaks (networking, disable coredumps), and a whole bunch of other things I have in a script. I've seen way too many people get their boxes trashed to leave an internet-accessible one exposed and unsecured.
What are your thoughts on sharing your script? I have a few VPS and would love some new tools / proper setup. I have been learning as I go, learned a few day 1 things not to do, but would like to learn more about networking/coredumps. Cheers!
Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains
161–170 of 171 posts
Re: Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains
#162Earlier quoted context omitted.
What are your thoughts on sharing your script? I have a few VPS and would love some new tools / proper setup. I have been learning as I go, learned a few day 1 things not to do, but would like to learn more about networking/coredumps. Cheers!
I'd have to clean it up first. I wrote it for a competition, and it does its job well; I may clean it up and improve it soon. Right now, it's a mess of a monolithic script.
Re: Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains
#163Earlier quoted context omitted.
> Yearly maintenance I'd say continuous maintenance with response to specific issues. Also debian updates don't restart services which rely on updated shared libraries, which means you need to restart your nginx after openssl updates. Also restarts when kernel is updated. Also... There's really more to it than just an annual upgrade. You're likely not going to be affected if you ignore this, but why risk it?
Ok, I forgot to add 'reboot' to yearly maintenance :). And change the ssh port or consider a private key. But if its just for a personal static website, I wouldn't get overly concerned about being hacked. Assuming you have backed up your page, its another handful of simple commands to rebuild the whole thing anyway. They are also quite fun for other uses, like setting up a squid proxy, messing with an email server or…
Re: Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains
#164Earlier quoted context omitted.
> you can literally just CNAME www.yoursite.com to yoursite.gitlab.io After so many years I still can't really understand how easily people hand over almost complete control over their site to someone else, just because everyone else does. It's like handing over your e-mail account passwords when LinkedIn started. Yes, CloudFlare, Google and others are helping you, but there is a price to pay that might not be immedi…
It seems pretty different from a password because you're not giving control of your domain: if they broke their contract, you could take it back at any time. That's the other odd part about this complaint: you're trusting a company like GitLab not to break their terms of service, which is a potential factor to consider but also one where they'd have severe negative outcomes to their business if they went rogue. Since…
You are giving them everything they'd need to obtain a DV certificate for your domain, though. You can stop them from using it at any time just by changing the DNS records, but you'd need to wait at least two years (825 days for maximum TLS certificate duration) before you could be certain any certificates they had been issued before that point had expired.
Re: Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains
#165Earlier quoted context omitted.
Ok, I forgot to add 'reboot' to yearly maintenance :). And change the ssh port or consider a private key. But if its just for a personal static website, I wouldn't get overly concerned about being hacked. Assuming you have backed up your page, its another handful of simple commands to rebuild the whole thing anyway. They are also quite fun for other uses, like setting up a squid proxy, messing with an email server or…
It's not about rebuilding if your website is defaced. It's the possibility of someone (for example) adding a client side exploit / throttled miner to your existing website. Without more monitoring, you won't know it happened, and neither will most of your visitors.
Re: Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains
#166Earlier quoted context omitted.
It's not about rebuilding if your website is defaced. It's the possibility of someone (for example) adding a client side exploit / throttled miner to your existing website. Without more monitoring, you won't know it happened, and neither will most of your visitors.
Has this sort of thing ever happened to you?
Adding extra servers like own cloud storage, email, IRC, etc. just expands your risk to more services (unless you internally separate them into namespaces/VMs, but then we're really far away from a "simple static hosting" territory)
Re: Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains
#167Earlier quoted context omitted.
Has this sort of thing ever happened to you?
Yes. I can't remember the details of entry since it was decades ago, but the end result was JavaScript snippets targeting browsers appended to the end of index page. Adding extra servers like own cloud storage, email, IRC, etc. just expands your risk to more services (unless you internally separate them into namespaces/VMs, but then we're really far away from a "simple static hosting" territory)
Re: Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains
#168Earlier quoted context omitted.
Yes. I can't remember the details of entry since it was decades ago, but the end result was JavaScript snippets targeting browsers appended to the end of index page. Adding extra servers like own cloud storage, email, IRC, etc. just expands your risk to more services (unless you internally separate them into namespaces/VMs, but then we're really far away from a "simple static hosting" territory)
Lucky for me I dont use javascript. But that was decades ago right? Well.... relax! I think you are letting these fears get in the way of actually enjoying something quite fun. Perhaps the NSA has some lovely nginx exploits, but the script kiddies that trawl the web these days are laughable. (knock on wood).
You're right that there's fewer wormable issues these days. But the question is: does your usual approach to security allow you to stay safe when (not if) the next one happens. And feel free to continue in not-super-secure way for personal, fun things. Just keep in mind that there's more to the story and the more moving parts, the more you need to work to keep things reasonably secure.
Re: Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains
#169Earlier quoted context omitted.
The usual roadblock in this process is getting ports exposed to the internet. In the best case this can just be done on your router configuration. In the unfortunately common case the ISP blocks you from doing this and the only solution is to change ISP.
I've heard of ISPs blocking ports, but not in Europe. I just forward ports 80 and 443 to the server (and pinhole the IPv6 ports) and it's done. The upstream bandwidth is about 60Mb/s, which is fine for almost everything.
Re: Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains
#170Earlier quoted context omitted.
I've heard of ISPs blocking ports, but not in Europe. I just forward ports 80 and 443 to the server (and pinhole the IPv6 ports) and it's done. The upstream bandwidth is about 60Mb/s, which is fine for almost everything.
How can I do such thing? I'm in Europe as well. Do you have any guide to get me started?