 |
 |
On Thu, Jun 10, 2021 at 11:36:13PM +0300, Sergio Letuche wrote: > We plan to use a linux server and lamp software to keep persons info that > we must protect. > Only 4 people in our library will have access to this server via a web > based app via a lan. > > Which flavour of linux server you would suggest to use? > The best way to be sure our data is safe would be to keep it without any > internet connection just to allow it to be reachable from within the local > network. > How you suggest we should proceed with having updates to the server > software but also be sure noone outside our premises could "see" our server? First, I'd recommend OpenBSD over Linux. This starts you off with a more secure operating system that will run on the same hardware, and it positions you to use "pf", OpenBSD's built-in firewall, which is the best available. This probably means climbing the learning curve from Linux to OpenBSD, but they're not that dissimilar (unsurprising given that Linux is a Unix clone) and it's worth it. Second, whatever OS you use, make sure that every service you don't need is turned off. Check this by scanning with nmap, and re-check it at intervals to make sure that something didn't get turned on that's not supposed to be on. Third, again regardless of OS, configure the onboard firewall default-deny in BOTH directions. This is a point that I (among others) have been jumping up and down yelling about for ~20 years and yet it still doesn't get done... which is a significant part of the reason that security breaches happen and why they lead to dataloss incidents. Then only enable inbound and outbound connections for the services you absolutely need, and only enable them for specific sources and destinations. For example, if only four people are supposed to have access to this and are only supposed to have access to it from your LAN, and are only supposed to access it via HTTPS, then hardcode their IP addresses into the firewall ruleset and only allow incoming connections to port 443 from those. (Yes, this means that if their addresses change, you have to change the firewall ruleset. This is a feature, not a bug.) Fourth, log everything and pay attention to the logs. (Also something I've been jumping up and down about.) Make copies of the logs elsewhere and backup/retain/archive them. If you see things that don't make sense, that's a good time to make coffee and investigate. Fifth, OS updates are tricky because they depend on how that particular OS handles them. In the ideal case, you would download updates to removable media on a system that can reach the Internet; unplug the media from that system, plug it into this system, and apply the updates. But that's not always possible, so one alternative is to maintain a local mirror of the OS inside your network perimeter and point this 4-person system at that mirror. Most OS distributions have a how-to for maintaining your own mirror and most of the time it's fairly straightforward: allocate this much disk space, run these commands, install this cron job so that a check for updates is done every 24 hours, and so on. The resources needed to run a mirror are minimal: provided you have enough disk space, any old disused system will probably suffice. Doing all this means that your server will be invisible to the outside world: it won't reach out to a server for OS updates, it won't make external DNS queries, and so on. It won't do these things because it can't: that's part of the job of the default-deny firewall rules I mentioned above. This isn't a guarantee: there are no guarantees. But it does raise the bar for attackers quite a bit. ---rsk