2

Assuming for a self-hosted webserver:

  1. the webserver only hosts a static html website
  2. iptables is used to reject every IP except a few known ones
  3. only Port 443 is forwarded and the website requires SSL via client certificates

What kind of dangers remain? (Disregarding security holes in a patch)

schroeder
  • 125,553
  • 55
  • 289
  • 326
Nesuma
  • 51
  • 4
  • What do you mean by "disregarding security holes in a patch". Does that mean any source code you modified on the server, or are you saying the entire webserver and possibly the OS is out of scope? – Steve Sether Jul 26 '18 at 17:14
  • 1
    So port 443 is the only open port, i.e. no plain HTTP, no remote access via SSH or similar, no FTP access, no remote console - i.e. a server located at a location nobody except you has access to (for example at home) and physical access is needed to make any changes to the system? And, are you asking only about attacks which could compromise the server or also attacks which might impact availability (like denial of service attacks)? – Steffen Ullrich Jul 26 '18 at 17:31
  • @SteveSether "disregarding security holes" because I know that no system will be secure ever and you apart from waiting instead of updating instantanious I don't know a way to avoid new security holes. And that doesn't seem to be that viable. – Nesuma Jul 26 '18 at 17:52
  • @SteffenUllrich Yes, in the router everything else is closed, on the webserver SSH is opened, but only usable with the SSH keys I have on my second computer. Yes to the second part too, a DoS wouldn't be a problem, nothing important will run on this server. – Nesuma Jul 26 '18 at 17:56
  • 2
    @Nesuma: sounds like a setup with pleasently low attack surface for me then. Just in case the attacker somehow manages to break in anyway (even web servers sometimes have bugs) you might run the server itself within some restricted environment (chroot, docker, selinux...) and you should also only have the tools on the system which are essential to run the server, i.e. no compiler or similar. If you use Linux then Alpine Linux is a good basis for this, i.e. you start minimal and then add only the things needed instead of trying to strip down an existing system. – Steffen Ullrich Jul 26 '18 at 18:52
  • You duplicated your other question? https://security.stackexchange.com/questions/190118/why-exactly-are-self-hosted-websites-deemed-that-dangerous – schroeder Jul 26 '18 at 19:30

2 Answers2

4

Sounds like you've done a good job doing taking care of the usual suspects.

How good is your web development skills? In my work experience, misconfigured web servers are the most common threat vector for a breach. Having it be only static is a good move. Have you disabled all the default pages? Is the webserver up to date? Have you run any vulnerability scans against it (at least run ZAP, it's free). Opening up an inbound port into your network with a server on it is, let's say riskier, as you now have a footprint on the internet for scanners to find. Granted, your home router is also getting scanned and attacked on the regular.

If this is on your own home network, and someone breaches it, you are in a really bad spot. Have you considered hosting it on AWS or etc? That at least segments it away from your home systems with critical information on them. I am not saying don't do this, as some might, but I highly suggest network segmentation for it, though, away from the rest of your home network.

schroeder
  • 125,553
  • 55
  • 289
  • 326
bashCypher
  • 1,879
  • 12
  • 21
  • 1
    I'm still a beginner but for every step I take I try to read through every information I can find before I implement something. Vulnerability scans are definitely something I will try out. I know that external hosting is the better solution most of the time, but as long as I just use this as a personal project I want to do it locally. Right now I'm reading about the benefits of multiple routers / physically separate networks etc. Still a long road to...Thanks for your answer – Nesuma Jul 26 '18 at 18:02
  • 1
    Keep at it and nice work! That's why I refused to tell you "don't do that." Check your home router, it might let you create a subnet for the webserver so you can segment it without buying a new switch. Not many do, but worth a look as I know some can! – bashCypher Jul 26 '18 at 18:07
1

There are still some dangers. By static HTML page, do you mean just HTML (and maybe CSS), without javascript or any server-side languages?

Are there any cookies on the website? By the sounds of it there is not. If there is no PHP and it is just HTML pages, there are really no dangers with regards to web exploitation (SQLi, XSS, LFI, RFI, XXE, RCE, etc). When it comes to security the actual web server, it's important to make sure to close all ports except the ones which are needed.

That covers website hardening (you can't get any harder than just HTML), and also web server hardening. It is also important to harden your web server software (Apache, nginx, Lighttpd). This will prevent any potential vulnerabilities with the web server from allowing someone to root your boxes in the future.

Realistically speaking, it sounds like this is a very private website which won't be attracting much attention anyways. There are always potentials for attacks, be smart. Also, you should probably consider using a service such as CloudFlare to prevent a DDoS attack and also to help hide your server's IP.

schroeder
  • 125,553
  • 55
  • 289
  • 326
Cillian Collins
  • 232
  • 1
  • 4
  • 1
    The question says the 443 is the only open port. And it's not important to use a non-default ssh port, it can be _convenient_ for reducing auth attempts and auth log sizes, but it's security through obscurity and generally not effective. Using a port above 1024 reduces security in some cases as well. – AndrolGenhald Jul 26 '18 at 19:55
  • 1
    Security through obscurity is a legitimate way to reduce the number of attacks. It may not reduce the attack surface but it would still be an effective means of securing SSH. Either way, you are right. I got a little carried away and forgot that he mentioned port 443 was the only port being forwarded. – Cillian Collins Jul 26 '18 at 20:02
  • Actually reading the comments under the OP now, he mentioned that the SSH port is open? – Cillian Collins Jul 26 '18 at 20:05
  • No, it does not _secure_ SSH, it _obscures_ it, you still have to use a strong password or asymmetric key. Obscurity can be useful, but it is not the same as security. – AndrolGenhald Jul 26 '18 at 20:05
  • Sounds to me like he has SSH open on a LAN, but a separate firewall forwarding 443 to the server and dropping all other incoming connections. – AndrolGenhald Jul 26 '18 at 20:06
  • Hmm you may be correct. Remove it from my answer anyway, thanks for that. As for security through obscurity, I have always considered this a valid means of protecting a server/website. I know it is a debatable topic. Could you explain why one might prefer to not obscure things, other than convenience? – Cillian Collins Jul 26 '18 at 20:11
  • r.e. obscurity, it's been talked about extensively several times, I think [this](https://security.stackexchange.com/q/2430) is the most relevant question. It can be useful if you know what you're doing, but it shouldn't be relied upon for security, and it can be bad if you don't know what you're doing (e.g. use a port above 1024). – AndrolGenhald Jul 26 '18 at 20:26