To what degree do you think it would be more secure (from hacking and data theft, etc.) to have what amounts to a "write-only" data backup server? I imagine it would remove all the code for port listeners, except leave one port open that only receives messages in a legal format at predefined backup times.

Would this, in practice, make the data on the data server harder to steal or corrupt via an attack over the network? Or are there too many hacking techniques that wouldn't be affected by port listening restrictions?

A hacker might learn the legal message format by hacking a message sending computer, but what he could accomplish would theoretically be limited by what message contents the data server was willing to process.

I think the bottom line is, would the data server be materially more secure? And, is there already a method available that essentially accomplishes the same thing?

Welcome to LQIf a server were configured to only pull data from another server for backup purposes, there'd be no need to have any daemons listening and all inbound ports could be blocked. Obviously, one would still need to have outbound port(s) open, at least during the backup process, to effect the backup.

I think the method would be as you describe:

• Disable (or don't even install) apache, email, sshd, etc.
• Reject all INBOUND connections.

Of course, one would have to be at the console of the server if sshd is not running.

You'd also need to consider how to use the server for recovery, which might involve having to allow incoming connections.

1 members found this post helpful.

What exactly are you trying to accomplish? Unreadable data?

Read-Only would secure the data from tampering, but theoretically yes, to make data write-only would too. But how could that be practically implemented? If you only write data and not sync data, I think the better option is unmount - mount and immutable flags. If you just dump data there, then immutable should be good enough. Mounting before use and unmounting after use would practically make it non-write, non-read.

What kind of disk/system is it? And what is its purpose exactly?

@scasey, I never thought of the backup server logging into a computer and pulling data. I like that idea. One of the things that needs to be protected against is if a hacker gained administrator privileges on one of the computers that will be backed up. He could, for example, install his own software in place of any system software that runs when the backup server logs in or is legitimately copying data.

The design would need to make being at the console of the server unnecessary. It would need to be an automated process of backing up many computers frequently. (Writing new software for any necessary function that doesn't already exist is acceptable.)

For restoration of the data, a secure method would be ideal—but in the worst case, walking an SSD to the computer that needs restoration would be tolerable. It would be rare that a user computer got hacked in the first place, anyway, and would be treated as a departmental breech.

@zeebra, I am trying to further my understanding of how to harden security for a whole department of computers—essentially to make it close to impossible for a hacker or someone inside the organization to examine, alter, corrupt, or copy the data on the (physically secured) backup server. The goal is to have good copies of all the user data in a worst case hacker/trojan invasion scenario.

Pulling data is how I backup my production server. I use rsnapshot, which uses rsync, and connect from my backup server to my production server on daily, weekly, and monthly cycles. I'm doing that over ssh using keys, so there's nothing running on the production box to be picked up.

Yes, there could be something a hacker put on the production box that would then get backed up, but the backed up data isn't ever run on the backup server, it just sits there. Besides, I typically don't back up "system software" -- only configuration files. A catastrophic failure would require re-installing the OS. Restoring a web page a customer accidentally deleted is pretty simple.

1 members found this post helpful.

I didn't mean execution of data that was retrieved from the production server, but rather the corruption of the programs on the production server (starting with a daemon) that make connecting to the production server possible.

With rsync, that's either rsync in daemon mode or sshd, for doing the backup. Yes, if sshd has been hacked, you'd definitely have a problem (doh).

I use sshd on the server, the "work" of copying is being done by rsync on the client/backup server.