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