 |
 |
We use pfSense which is based on FreeBSD, and it does a stellar job for us. The browser-based user interface makes configuring it fairly easy, but yes, there is a learning curve. This reminded me of one of the best firewalls one could have. A security expert in Austin told me about it. Take a Linux box, configure the firewall rules and everything you need for networking. Then edit the shutdown script so that all processes are halted except for things like iptables and ipchains, basically whatever it needs to route traffic. Then shut down the server. All OS processes would be stopped except networking. In such a case, there's no OS to hack one's way into. I've haven't tried it, but it sounds very intriguing. John Lolis Coordinator of Computer Systems 100 Martine Avenue White Plains, NY 10601 tel: 1.914.422.1497 fax: 1.914.422.1452 https://whiteplainslibrary.org/ *When you think about it, *all* security is ultimately security by ignorance.* On Wed, 23 Jun 2021 at 11:23, Rich Kulawiec <[log in to unmask]> wrote: > 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 >